команда BIT n,(HL) [Архив] - Speccy

Vladimir Kladov

19.02.2006, 13:57

Нет, не проходит, и слава всевышнему. Ни один эмулятор и ни одно реальное железо его не проходит. Хотите самый надежный тест? Включайте поддержку RZX-файлов, качайте готовые RZX-записи, делайте свои RZX-записи в других эмуляторах и гоняйте до опупения. Вот когда будут работать 99% таких записей (которые идут по крайней мере еще на 2х эмуляторах - есть записи "неправильные", которые идут только на том эмуляторе, на котором и были записаны), вот тогда можете смело считать, что у вас все в порядке и делается практически 100% точно для целей эмуляции.

Полностью добиться 100%-ной точности реально, если есть под рукой железо, но неинтересно, кроме спортивных целей. Вот есть такая фишка, ULA называется. Чтобы учесть задержки и не сильно затормозить, большинство эмуляторов работают по таблицам, и берут во внимание только то, в каком банке начинается команда. А если 4-х байтная команда к примеру начинается в медленном банке, а продолжается в быстром банке ОЗУ, то такты посчитаются неправильно. Это касается и спектаклятора, и рил спека (у себя-то я правильно сделал, но чтобы это показать, надо специально демку городить мультиколорную, а мне влом).

boo_boo

19.02.2006, 14:38

ну я не по буковкам ОК смотрю, а по результатам: сравниваю свои с теми, которые на реале выходят... все совпадает, а bit этот нет.. ладно, фиг бы с ним -- по ходу извращений "добился" один раз того, что ПЗУ глючило, а тест нормально все показывал.. хе-хе :rolleyes:

Titus

19.02.2006, 15:40

Полностью добиться 100%-ной точности реально, если есть под рукой железо, но неинтересно, кроме спортивных целей.

По мне - эмулятор не является полноценным эмулятором, если он не эмулит комп на 100% ;)

Vladimir Kladov

19.02.2006, 16:46

Titus

19.02.2006, 17:00

в таком случае полноценных эмуляторов - не существут. Достаточно на сайте http://www.mdfs.net/Software/Z80/Exerciser/Spectrum/ посмотреть и убедиться, что и на реальном железе этот тест дает неверные результаты, хе-хе.

А есть ведь еще различия между чипами Z80 от разных производителей...

Если на реальном железе дает неверные, то под чего же он написан? ;)

А что касается разных чипов Z80, то это весма сомнительно. В свое время было очень много споров на эту тему, и в результате так никто и не смог предоставить чип, отличающийся от 'оригинала'. Помнится даже MacBuster (бывший SAV-Soft) накупил кучищу процов от разных производителей дабы найти различия, и, естественно, ничего не нашел.

p.s.: Естественно, имеется ввиду Z80, а не различные его 'продолжения'

Vladimir Kladov

19.02.2006, 21:59

различия есть, а вот в чем они, нам никто не расскажет. Однако Джон Нидл в своем Спектакуляторе сделал опцию выбора версии кристалла, и от этого по разному работает по крайней мере 1 мультиколорная демка. Есть выбор чипа врде бы и RS.

SMT

19.02.2006, 22:33

забавный тест. только я у себя так и не смог проэмулировать сабжевую команду. правда, погонял тест на разных эмулях, вот

boo_boo

20.02.2006, 02:36

Если на реальном железе дает неверные, то под чего же он написан? ;)черт разберет. к слову, сам автор yaze (и теста, соотв) нахально делает F=A&28h. и все-то у него "сходится". я забил на эти тестовые "ОК" и просто сравниваю CRC для своего ядра с CRC, которые выходят на реале.

насчет "эмуляции на 100%": очевидно, никто так и не разобрался толком, что это за "внутренний регистр", и какие опкоды как на него влияют -- судя по результатам, которые SMT запостил...
мораль: если не хочешь, чтобы прога шла под эмуляторами, достаточно заксорить ее флаговым регистром после bit n,(hl) ;)

Titus

20.02.2006, 02:38

забавный тест. только я у себя так и не смог проэмулировать сабжевую команду. правда, погонял тест на разных эмулях, вот
Неплохо :) Сразу видно что почем ;)

различия есть, а вот в чем они, нам никто не расскажет. Однако Джон Нидл в своем Спектакуляторе сделал опцию выбора версии кристалла, и от этого по разному работает по крайней мере 1 мультиколорная демка. Есть выбор чипа врде бы и RS.
Пока никто этих 'различных' кристаллов не видел, нет смысла говорить о том, что они где-то там есть. Самое важное во всем этом то, что ни на одном, хоть более менее серийно выпускаемом ZX клоне, еще не было замечено Z80 с кристаллом отличающимся от оригинала. Если же кто встречал, то пожалуйста - в студию! ;)

Vladimir Kladov

20.02.2006, 16:38

я бы не стал доверять результатам так уж. И как раз из-за наличия того самого внутреннего регистра. И что еще может там повлиять на результат. Недаром на реальном железе тест обламывается: его резуьтат для некоторых команд может зависеть от результата совсем других команд, котрые выполнялись совсем в другой момент времени. А если еще и от команд перехода (внутренний регистр), по получается - как и чем саму прогу скомпилировал, то и получил.

Что если прогнать тест на реалке 1 раз, а потом в другой раз, и сравнить результат? А если на 2х разных реалках?

А я еще сдается мне, что этот тест работает в разрешенных прерываниях, т.е. все время вмешивается (когда заблагорассудится) int38, и опять портит этот внтуренний регистр. Нет, так тесты не делаются.

boo_boo

20.02.2006, 17:17

Недаром на реальном железе тест обламывается: его резуьтат для некоторых команд может зависеть от результата совсем других команд, котрые выполнялись совсем в другой момент времени. А если еще и от команд переходаавтор порта zexall на спек думает, что где-то напортачил, поэтому crc не сходятся. в отношении bit n,(hl) это определенно так, адрес ассемблирования-то поменялся.

А я еще сдается мне, что этот тест работает в разрешенных прерываниях, т.е. все время вмешивается (когда заблагорассудится) int38не, автор теста не идиот -- прерывания отключает.

Vladimir Kladov

20.02.2006, 19:05

что-то насчет отключения прерывний - не заметил (я его когда запустил, несколько раз останавливал в дебугере, почему-то он частенько на адресе 38 стопался. Наде еще глянуть). А по-хорошему, в тесте на bit надо бы уже перед каждой командой делать типа ADD HL,DE (и поместить туда нули).

Знахарь

20.02.2006, 19:32

Ну! Ну! так что дальше-то ? Идиот автор теста или нет ?

У кого есть реал - запускали, как предлагалось, тест несколько раз ?

SMT, какие результаты прогона на других эмуляторах ?

boo_boo

20.02.2006, 19:39

что-то насчет отключения прерывний - не заметил (я его когда запустил, несколько раз останавливал в дебугере, почему-то он частенько на адресе 38 стопался. а он непосредственно перед инициализацией регистров и исполнением тестовой инструкции отключает прерывания. впрочем, в случае с сабжем это не особо спасает -- между call nz, test (который инициализирует "эзотерический регистр" адресом перехода) и di может проскочить прерывание.

SMT

20.02.2006, 20:42

SMT, какие результаты прогона на других эмуляторах ?на каких интересует? под дос, линукс или коммерческих у меня нет

Знахарь

20.02.2006, 21:00

Ну... На unrealе не эмулится - так, а на каком эмулится ? И что это значит ?

SMT

20.02.2006, 21:04

Ну... На unrealе не эмулится - так, а на каком эмулится ? И что это значит ?
вопрос не понял, особенно последний. чтобы понять, что это значит, прочти сопроводительную доку и тексты от чела, который портировал это в спектрум. понятно, что если адрес компиляции поменялся, флаги, пришедшие из адресных регистров - тоже

Vladimir Kladov

20.02.2006, 21:14

Хм. А киким образом call nz инициализирует скрытый регистр? я так понял, этот регистр получает значение после внутренних сложений, для call и jp сложение вроде бы и не при чем.

boo_boo

20.02.2006, 21:50

Хм. А киким образом call nz инициализирует скрытый регистр? я так понял, этот регистр получает значение после внутренних сложений, для call и jp сложение вроде бы и не при чем.
самый подробный кусок инфы, который я нашел:

Internal MEMPTR Register
This is an internal Z80 register, modified by some instructions, and usually completely hidden to the user, except that Bit 11 and Bit 13 can be read out at a later time by BIT N,(HL) instructions.
The following list specifies the resulting content of the MEMPTR register caused by the respective instructions.

Content Instruction
A*100h LD (xx),A ;xx=BC,DE,nn
xx+1 LD A,(xx) ;xx=BC,DE,nn
nn+1 LD (nn),rr; LD rr,(nn) ;rr=BC,DE,HL,IX,IY
rr EX (SP),rr ;rr=HL,IX,IY (MEMPTR=new value of rr)
rr+1 ADD/ADC/SBC rr,xx ;rr=HL,IX,IY (MEMPTR=old value of rr+1)
HL+1 RLD and RRD
dest JP nn; CALL nn; JR nn ;dest=nn
dest JP f,nn; CALL f,nn ;regardless of condition true/false
dest RET; RETI; RETN ;dest=value read from (sp)
dest RET f; JR f,nn; DJNZ nn ;only if condition=true
00XX RST n
adr+1 IN A,(n) ;adr=A*100h+n, memptr=A*100h+n+1
bc+1 IN r,(BC); OUT (BC),r ;adr=bc
ii+d All instructions with operand (ii+d)

Also the following might or might not affect MEMPTR, not tested yet:

OUT (N),A and block commands LDXX, CPXX, INXX, OUTXX
and probably interrupts in IM 0, 1, 2

All other commands do not affect the MEMPTR register - this includes all instructions with operand (HL), all PUSH and POP instructions, not executed conditionals JR f,d, DJNZ d, RET f (ie. with with condition=false), and the JP HL/IX/IY jump instructions.

boo_boo

21.02.2006, 05:37

сляпал на коленке некий тестик для bit (hl)...
плз, у кого реал под рукой, запустите там это дело, и запостите scr с образовавшимся на экране беспределом.
бум сравнивать ;)

Vladimir Kladov

21.02.2006, 20:25

очень интересная инфа, бо-бо. Кстати, SMT, у тебя первая колонка - это ты сам реал гонял? (И когда только успел, разве только на турбе...)

SMT

21.02.2006, 21:16

это автор порта на спектрум гонял. это лежит там же, где boo_boo взял текст про memptr. и ссылка была где-то тут. так что пролистай тему вверх и всё увидишь

Vladimir Kladov

22.02.2006, 11:55

SMT, порта чего? эта что ли: http://www.work.de/nocash/zxdocs.htm
вверх... это у вас верх, а у меня вниз (настройки у меня такие: ну, оригинал я, все не так делаю как остальные :) ).

Понятно насчет первой колонки. Предлагаю (повторно) еще кому-нибудь погонять на реале. Желательно 2 раза и/или на 2х реалах. Если есть турбо, можно на турбе (разница, хотя, может быть какая-то, из-за того же int). Очень хочется еще раз убедиться.

SMT

22.02.2006, 13:01

порта чего?я понял, портировали из cp/m - в исходниках упоминается bdos, а старый адрес компиляции - #0100

Vladimir Kladov

24.02.2006, 16:50

вот такая штука. Стал смотреть что у меня по тесту неверно с командами CPD[r], CPI[r]. Нашел ошибку, исправил. Стало совпадать. Но по дороге качнул исходник US 0.34b, и посмотрел, так же он делает как я с этими командами. Оказалось, что совсем не так. У SMT в коде для CP к примеру:
void __fastcall ope_A9(Z80 *cpu) { // cpd
cpu->t += 8;
unsigned char cf = cpu->f & CF;
cp8(cpu, rm(cpu->hl--));
cpu->f = (cpu->f & ~(CF|PV)) | cf;
if (--cpu->bc16) cpu->f |= PV;
}
флажки XF и YF строятся на основании результата сранения A-(HL). А у меня по Янгу: YF=bit1 of n, XF=bit3 of n, где n=A-(HL)-HF. Результат "всеобъемлющего" теста тем не менее совпадает в обоих случаях. Какой же это тогда "всеобъемлющий" тест?

Разбирясь с тем, как выполняет Spectaculator команду bit 0,b (первую же в этом тесте, я наткнулся вот на какую штуку. [...вырезано: LD SP,(addr) нет в списке влиящих на memptr, еще надо найти, какая же команда установила memptr перед попаданием на 9C09h, мда] Факт, однако: тест zexall по команде bit n,(HL) Spectaculator проходит, т.е. его контрольная сумма совпадает с результатами колонки Z80(real) для этой команды (замечу: у единственного из всех эмуляторов. Правда, у него есть другие ошибки, но на прошлой неделе это впрямь был самый точный среди всех :) ).

Сейчас пытаюсь "прогнать" еще и Spin. Ага, есть результаты. Вот обновленная табличка (http://bonanzas.rinet.ru/zx/emuls-z80test.zip).
(Я свой EmuZWin пока не обновляю, хочу еще посмотреть чего-нибудь, и надо для случая fast CPIR/CPDR код поправить).

Кстати, у кого под рукой линукс, не займетесь пополнением инфы для тамошних эмуляторов? Лично меня особо интересует Fuse, можно и глюкалку прогнать (так, кажется называется альтернатива на той платформе?).

boo_boo

24.02.2006, 17:15

Кстати, у кого под рукой линукс, не займетесь пополнением инфы для тамошних эмуляторов? Лично меня особо интересует Fuse, можно и глюкалку прогнать (так, кажется называется альтернатива на той платформе?). с глюкалкой связываться смысла нет -- там 5 и 3 биты F ВООБЩЕ не эмулируются. Fuse лучше, ~80% пунктов теста проходит. Мое ядро (libz80ex) проходит все, кроме bit n,<b,c,d,e,h,l,(hl),a> (из-за bit n,(hl), который фиг знает как эмулировать, и ни одна редиска _мой_ тест на реале прогнать не сподобилась :mad: )

SMT

24.02.2006, 18:29

качнул исходник US 0.34b
34b2 я ещё не выкладывал, а там по-другому

Vladimir Kladov

24.02.2006, 20:26

Ха! Чтобы тест bit n,(hl) прошел и совпал с колонкой Z80(real), надо сделать ручкой Янгу, и напросто занулить XF и YF после этой команды...

Или у Янга на руках был не тот процессор, либо одно из двух. Но именно так работает Spectaculator. Причем видимо не зависимо от того какой процессор выбран. Мда вот. А ведь даже в некоторых форматов снапшотов сохраняется теперь значение этого регистра, с комментарием, что дескать влияет на флажки в результате команды именно bit n,(hl)

А с bit n,(ix+n) фишка вот какая. Здесь Янг может быть и прав. Но я пробовал сделать пару финтов. Например, занулить их. И тест все равно проходит! (Я, конечно, понимаю, там может быть IX всегда показывает сам на такой адрес, что ((IX+1)/256)&28h=0. Но тогда грош цена такому тесту!).

В общем, народ. Если не найдутся реальщики готовые сотрудничать, чтобы подтвердить или наоборот развеять слухи о MemPtr-регистре, то ничего мы тут не добьемся. На данный момент результаты показывают: само существование этого регистра, возможно, результат работы с конкретным (горелым? левым?) Z80. Или тот тест прогонялся не на настоящем фирменном Z80, а на какой-нибудь под(д)елке (из Китая?). Даже на команды CPDr, CPIr он тоже похоже не влияет. Какие еще команды якобы берут из него флажки? (Сейчас выяснится, что слухи о memptr не более чем миф, вроде ракслы в спековской элите... ;) )

Пойду пока смотреть где у меня сдвиги не так пашут.

Vladimir Kladov

24.02.2006, 21:14

Может, реальщики нас просто не видят, потому что в раздел "Эмуляторы" не заглядывают? Запостить надо в раздел железо просьбу заглянуть сюда. А то как в современной многоэтажке живем, как выглядят сосдеи по площадке и чем дышат - не знаем...

SMT

24.02.2006, 21:36

boo_boo

24.02.2006, 21:49

а реально скачать описание z80 в каком-нить VHDL? будет ли такая модель вести себя, как фирменная. или ядрописатели в том же положении, и могли пропустить недокументированные фичи
скачать реально, с opencores -- t80/tv80... только Zilog исходниками z80 с народом не делилась, сталбыть авторы этих ядер тоже работали по описаниям.

boo_boo

25.02.2006, 05:15

благодаря Wlodek'у (тут (http://zx.pk.ru/showthread.php?t=2586) ) мой недотест bit 0, (hl) принес свои плоды. очень странные плоды...

в каждой клетке на картинке -- 3 и 5 биты F после очистки флагов, выполнения определенной команды, и последующего bit 0,(hl)

(далее звездочка обозначает этот (http://work.de/nocash/zxdocs.htm#z80garbageinflagregister) докУмент)

клетки 1-3: LD A,(FFXX) -- флаги установлены. похоже, и впрямь в memptr идет адрес (или адрес+1, как говорят в *?), надо проверять подробней.

4-6: LD (FFXX),A для A=0,FF,AA -- пусто. (то есть * врет). или эта команда вообще ни на что не влияет, или просто обнуляет memptr (кстати, именно LD (addr),A при A=0 я делаю при очистке флагов, надеясь, что она, как говорится в *, сделает MEMPTR=A*0x100, то есть обнулит его нафиг. похоже, тем или иным образом он таки обнуляется О__о)

7-12: ld (FFFE),rp для BC,SP,DE,HL,IX,IY -- установлены, опять похоже, что в memptr идет адрес или адрес+1.

13-18: ld rp,(FFFE) для тех же регистров -- установлены, видимо, снова адрес.

19: ex (SP),IX при SP=BFE6, (SP)=IX=FFFE -- включено, черт разберет, или адрес, или (SP)

20: ADD HL,BC при HL=FF00,BC=1 -- включено.
21: ADD HL,BC при HL=FFFF,BC=1 -- выключено. видимо, для ADD HL,BC в memptr попадает результат операции.

22-23: аналогично для ADC, результат тот же.

24-25: аналогично для SBC, тот же результат! ого, откуда взяться нулям в 3 и 5 битах после вычитания 1 из FFFF?

26 -- rld для HL=FFFE, биты включены
27 -- rld для HL=FFFF, выключены

28, 29 -- то же для rrd

30,31,32: JP, JR, CALL C3XX -- выключено, но это мало о чем не говорит, так как адрес я выбрал дурацкий -__-

33,34: JP z,FFFF и CALL Z,FFFF при сброшенном Z. включено. и впрямь для JP и CALL memptr меняется, даже если условие не выполнено.

35,36: in A,(F0) и in A,(FF) при A=0. выключено.

37: in A,(C) при BC=FFF0. включено.
38: in A,(C) при BC=FFFF. выключено. похоже, что memptr=bc+1 как в *

39-40: OUT (FF),A при A=FE и A=FF. выключено.

41: OUT (C),A при BC=FFF0. включено
42: OUT (C),A при BC=FFFF. выключено. ситуация, аналогичная in A,(C)

43-62: ldi,ldd,ldir,lddr,cpi,cpd,cpir,cpdr в нескольких вариантах. пусто.

63-70: ini,ind -- пусто.

71-78: outi,outd -- пусто.

79-86: inir,indr -- пусто.

87-94: otir,otdr -- пусто.

95: IM2, EI, HALT при I=FC -- установлен __только__ 5 бит!

96: чушь, хотел проверить JP IX, но забыл сделать JP %)

97: inc (hl) -- пусто

98: rlc (ix+1) при ix=FFFE. установлено.

99,100: RLC (HL) для HL=40xx и FFFF. пусто.

-------------------

вывод: то что написано в *, не то наполовину лажа, не то проверялось на другом кристалле. у янга не написано практически ничего, но что есть, совпадает...
вообщем, никто ничего не знает. чтобы разобраться, надо гонять МНОГО тестов, на реале, желательно на нескольких реалах О__о

Titus

25.02.2006, 05:49

то что написано в *, не то наполовину лажа, не то проверялось на другом кристалле. у янга не написано практически ничего, но что есть, совпадает...
вообщем, никто ничего не знает. чтобы разобраться, надо гонять МНОГО тестов, на реале, желательно на нескольких реалах О__о

Ну что же никак не равеется этот миф о наличие у населения РАЗНЫХ кристаллов. Может быть (да и то, глубого гепотетически) и был какой-то другой кристалл, но никаких документальных подтверждений тому не было, и в спектрумах такого кристалла замечено не было тоже! :|

Vladimir Kladov

25.02.2006, 07:51

Vladimir Kladov

25.02.2006, 09:57

А еще, чтобы понять, как эти тесты коррелируют с zexall, надо на том же компе (у Wlodek'а) прогнать сам zexall. Если он согдасится, конечно, ждать 11 часов (с турбой можно быстрее, если есть, но все равно 6,5 часов, и все это время регулярно подходить, и списывать с экрана результаты, и нажимать Enter, когда пора скролл делать). Вот я сделал в виде TRD, если удобнее так на реал загонять. (Миль пардон, я перекомпилировал с некоторыми исправлениями в своем ZXAsm, но надеюсь все совпадает: по крайней мере результаты прогона эмуляторах вроде бы те же, что и .z80).

Первый раз получился тест, который на пентагоне доходит до первого запроса на скролл и на нач то больше не реагирует. Я добавил EI в двух местах, перед вызовом 10h (pr-char), и еще раз прогнал весь тест. Должно пойти на реале. Очень хочется увидеть результаты живого прогона... Кто-нибудь, АУ! Wladek! особенно у тебя.

SMT

25.02.2006, 10:57

а смысл прогонять ВСЕ тесты? я, когда отлаживал us, запускал выборочно. самый длинный тест - это арифметико-логические команды с аккумулятором, он сложностей не вызывает ни у одного эмулятора. думаю, тест bit n,(hl) займёт несколько минут на реале

Wlodek

25.02.2006, 12:42

А еще, чтобы понять, как эти тесты коррелируют с zexall, надо на том же компе (у Wlodek'а) прогнать сам zexall.
и все это время регулярно подходить, и списывать с экрана результаты, и нажимать Enter, когда пора скролл делать
АУ! Wladek! особенно у тебя.

Скачал, запускаю. Но гарантировать, что в течение 11 часов смогу регулярно контролировать его состояние, боюсь :) . Вот если можно было бы просто на ночь оставить...

Vladimir Kladov

25.02.2006, 14:04

смысл в том, чтобы составить корреляцию с тем прогоном, что сделал автор. Оно можно сделать отдельный тест и для bit n,(hl), не проблема, я для того и адаптировал к своему ассемблеру, чтобы иметь возможность пропускать только нужные тесты. Но, по моему мнению, тут глубже собака зарыта. Надо хотя бы по разу на _нескольких_ реалах прогнать, чтобы разницу обнаружить, если она (не дай бо) есть.

Titus

25.02.2006, 17:21

на самом деле "разный" кристалл можно было запросто получить после пробоя его паяльником с плохим заземлением. Это же запросто: все (почти) работает, но иногда ведет себя странно. Раз работает, люди считают, что он "такой же". А глюки относятся на недосып или случайность.

Кроме того, однозначно известоно, что кристалл выпускался разными производителями, а не только самим Zilog'ом. Они что же, получали полную техническую документацию? Почему же тогда одни кристаллы могут только на 3.5-4МГц работать, другие на 12МГц, а иные гонятся аж до 20МГц. И все они - идентичны? Что-то сомневаюсь.

При так называемом 'пробое паяльником' в 99.99% помрет либо весь кристалл, либо какие-либо из вентилей ввода-вывода...

А что касается разных производителей, то естественно, что они не раводили кристалл самостоятельно, а брали уже готовый шаблон, либо просто корпусировали кристалл полученный от Zilog. Вряд ли кому-то пришла бы в голову гениальная идея проэктировать кристалл ЗАНОВО :D Да если и пришла бы, то в нем 'поплыли' бы не только недокументированные флаги bit x,(hl) ;)

boo_boo

25.02.2006, 17:28

Вряд ли кому-то пришла бы в голову гениальная идея проэктировать кристалл ЗАНОВО :D Да если и пришла бы, то в нем 'поплыли' бы не только недокументированные флаги bit x,(hl) ;) кой-кому пришла такая идея -- см t80, r800, советский аналог... а у тебя какие гипотезы насчет несовпадения эмуляции bit (hl) для 2х испытанных процов?

Titus

25.02.2006, 17:39

кой-кому пришла такая идея -- см t80, r800, советский аналог... а у тебя какие гипотезы насчет несовпадения эмуляции bit (hl) для 2х испытанных процов?

Как-то мне приходилось тестировать недокументированные флаги T80 - оказалось один к одному. Думаю внутри стоял кристалл от Zilog. Хотя некоторые склоняются к мнению, что он был просто сточен, переснят и воспроизведен заново ;)

Кстати говоря, возможно в Turbo процах, выпускаемых Zilog позднее что-то и отличалось, если они трогали топологию кристалла.

Да, а что касается недокументированных флагов, то еще 10 лет назад я думал, что знаю их все ;)

Vladimir Kladov

25.02.2006, 19:45

Отлично, 100%. Черт с ним с DAA, он все равно от XF, YF не зависит, да и не мог он не совпасть, если все прочее совпало до цифирки. А ведь тот человек (который адаптировал тест для спектрума) наверное гонял на фирменном спектруме, а не на пентагоне, так я понял?

Самое замечательное, что тест этот пройден и дал абсолютно тот же результат на том же компе, на котором проделан не менее замечательный тест от боо-боо. Т.е. можно гарантированно насчет команды bit n,(hl) сказать, что тест этой команды в этом большом тесте сходится совсем не потому, что на ее флажки не влияет искомый memptr (потому что он не может не влиять, и это доказывает малый тест от боо боо). Вывод: либо CRC в большом тесте строится по дурацкому алгоритму, и разные результаты могут спокойно давать один и тот же CRC с большой вероятностью, либо в большом тесте каким-то макаром все время оказывалось в memptr такое значение, что XF и YF все время занулялись.

Насчет первого (дурацкий CRC) - это надо проверить (сейчас буду смотреть, есть тест bit n,(ix+1), так вот он и вызывает у меня подозрение. Если ix бывает в этом тесте очень разный, тогда непонятно, почему элементарное зануление флажков XF, YF приводит к той же CRC. Если IX одинаковый, то автор теста (или тот кто его адпатировал) и вправду идиот (или просто не знал ничего про memptr).

А вот насчет зануления (п.2 моего рассуждения абзацем выше) флажков перед выполнением bit n,(hl). Я выяснил, что ближайшая команда, которая могла (и должна была в любом случае) повлиять на изменение memptr перед вызовом теста, это call nz,9BEFh по адресу 99FEh. Если верить источнику *, то в memptr попадает 9Bh&28h = 08h, т.е. как минимум XF=1, YF=0. Все, что по дороге, вроде бы memptr трогать не должно, согласно *.

А теперь очень интересная картина вырисовывается. Из всех эмуляторов выигрывает (тьфу, проходит) тест bit n,(hl) только спектакулятор, который начхал на мемптр по крайней мере для bit n,(hl) и всегда пишет в флажки YF и XF нули. И как же тогда быть прикажете?

Боо-боо, я хочу услышать: ты придумал, как правильно bit n,(hl) эмулировать?

boo_boo

25.02.2006, 20:04

Боо-боо, я хочу услышать: ты придумал, как правильно bit n,(hl) эмулировать? (btw, boo_boo читается бу-бу ;) ) думаю, но данных не хватает :(
особенно мутно с прерываниями и ld(nnnn),a у которого результаты разошлись на разных компах. сейчас дописываю тест поподробней/пообъемней, по результатам бут видно :o

Vladimir Kladov

26.02.2006, 14:24

думай. Но учти, что в большом тесте, кторый у Wlodek'а тот же результат показал, последняя команда перед bit n,(hl) это call nz, про который я сказал. Можешь посмотреть, дальше есть еще ld (xxxx),sp, ld sp,(xxxx), pish, pop, di. Если только ld sp,(xxxx) и ld (xxxx),sp вопреки * влияют на memptr, тогда понятно где собака зарыта. И тогда большой тест просто ничего не может сказатью И тогда понятно что бсолютно точно проходит тест эмулятор который просто зануляет XF и YF в bit n,(hl). (Spectaculator).

Так что я бы еще раз проверил что ld sp() и ld ()sp влияют или не влияют, да и push/pop тоже попроверял бы. (А DI не может случайно сбросить memptr, вот смеху-то было бы).

Vladimir Kladov

26.02.2006, 14:46

Вот точно какие команды выполняются в биг-тесте:
ORG 99FEh
CALL NZ, 9BEFh

ORG 9BEFH
PUSH AF
PUSH BC
PUSH DE
PUSH HL
PUSH IY
DI
LD (9C56H),SP
LD SP,8005H
POP IY
POP IX
POP HL
POP DE
POP BC
POP AF
LD SP,(8011H)
;а вот здесь выполняется bit n,(hl), после чего: nop nop и далее
ORG 9C0DH
LD (9C54H),SP
LD SP,9C54H
PUSH AF

дальше флажки уже сохранены какие есть т.е. после bit n(hl) они уже не менялись и даже этот кусок не нужен. Соответственно под подозрение попадают все PUSH/POP и LD (),SP с LD SP,().

boo_boo

26.02.2006, 16:21

Вот точно какие команды выполняются в биг-тесте ясный пень, LD SP,(8011H) нулями все забил. по моему тесту (последнему), LD SP,(nnnn) на memptr влияет -- сует в него адрес. так что на "большой тест" предлагаю забить, все с ним ясно...

SMT

26.02.2006, 17:37

сделаю, как написано в доке плюс ld sp,() / ld (),sp - чем sp хуже bc/de/hl? тогда большой тест пройдёт ;-)

boo_boo

26.02.2006, 17:50

сделаю, как написано в доке плюс ld sp,() / ld (),sp - чем sp хуже bc/de/hl? тогда большой тест пройдёт ;-)хе-хе :) а как насчет чтобы этот (http://zx.pk.ru/showthread.php?p=40139#post40139) (последний в треде) тест совпал с реалом? ;)

Vladimir Kladov

26.02.2006, 21:12

у меня уже прошел, осталось мелочи: объясни, boo-boo (коль те так больше нравится): что в btest2 такое тесты cpd/cpdr/cpi/cpdr и как для них правильно загружать адрес в memptr (или не адрес, а значение? из A? или из (HL)?). И пожалуйста, чуть подробнее насчет EI HALT в IM2 - откуда в регистр попадать должно? (Хоть бы исходники положил что ли, по дизассемблерному коду лазить не смешно).

boo_boo

27.02.2006, 00:24

благодаря Wlodek'у и CHRV мы теперь имеем над чем подумать ;)

в тестировании принимали участие:
Z0840008,Т34ВМ1,КР1858ВМ3,Z084C0010,КР185 8ВМ1 от CHRV,
пентагон Wlodek'a с неизвестным кристаллом (однако, не являющимся одним из вышеперечисленных)

у родных Z084C00010, Z0840008 все одинаково.
остальные кристаллы отличаются или по memptr, или по другим флагам.

итак, memptr, внутренний регистр z80, из старшего байта которого берутся 3 и 5 биты F при выполнении опкода bit n,(hl). судя по результатам теста вырисовывается такая картина (тут плюсиками помечены пункты, совпадающие с nocash-докой, минусом -- несовпадающие или отсутствующие, загогулиной -- ни то, ни се.):

+ LD A,(addr)
memptr=addr+1

~ LD (addr),A
для Z0840008, Z084C00010, КР1858ВМ3: memptr=A*0x100
на пентагоне Wlodek'a, Т34ВМ1, КР1858ВМ1: memptr=0

~ LD (addr), rp; LD rp,(addr)
memptr=addr+1

+ EX (SP),rp
memptr=rp

+ ADD/ADC/SBC rp,rp2
memptr=rp+1

+ RLD/RRD
memptr=HL+1

+ JP/JR/CALL/DJNZ/RET/RETI/?RST? addr (при переходе)
memptr=addr

+ JP/CALL при отрицательном условии
memptr=addr

+ IN A,(port)
memptr=полный_адрес_порта(A*0x100+ port) + 1

- OUT (port),A
для Z0840008, Z084C00010, КР1858ВМ3: memptr=полный_адрес_порта(A*0x100+ port)
для пентагона Wlodek'a, Т34ВМ1, КР1858ВМ1: memptr=0

+ IN A(C)
memptr=BC+1

+ OUT (C),A
memptr=BC+1

- CPI/CPD/CPIR/CPDR
самое непонятное... иногда меняет memptr, неясно, по какому принципу.
[в этом тесте все cpi обнуляют memptr, cpd оставляют как есть, все cpir изменяют непонятно как (первые два обнуляют, остальные, которые при BC=5 выставляют 3й бит), первые два cpdr оставляют как есть, последующие три (BC=5) выставляют 3й бит]

- INI/INIR/OTI/OTIR/IND/INDR/OUTD/OTDR
или просто memptr=0, или что-то похитрее, ведется следствие...

- прерывания:
как при обычном переходе. то есть memptr=адрес обработчика прерывания

+ любая инструкция с (IX/IY+d)
memptr=IX/IY+d

за остальными инструкциями ничего подозрительного не замечено.

пристегиваю архив с результатами теста и самим тестом (сорс для sjasmplus, сляпано быстро и на коленке, звиняюсь ,)

Wlodek

27.02.2006, 03:22

в тестировании принимали участие:
пентагон Wlodek'a с неизвестным кристаллом

По-моему, на нём написано "Z80A GoldStar". Уточнить вряд ли удастся, потому что на него давно наклеен радиатор.

icebear

27.02.2006, 12:44

скачать реально, с opencores -- t80/tv80... только Zilog исходниками z80 с народом не делилась, сталбыть авторы этих ядер тоже работали по описаниям.

"Исходников" Z80 быть не может. Кстати, обсуждалось недавно (месяца два назад) в comp.arch.fpga , "ссылку" я давал уже здесь.

icebear

27.02.2006, 12:46

пристегиваю архив с результатами теста и самим тестом (сорс для sjasmplus, сляпано быстро и на коленке, звиняюсь ,)

Если дашь тест в формате TAP или TZX то протестю на оригинальном ZX Spectrum+. Если надо, могу посмотреть чем камень в нём стоит.

Vladimir Kladov

27.02.2006, 18:27

или в CPI/CPD попадает не тот регистр. Варианты: A, DE+1 (а вдруг), BC-1 (тогда откель 1 взялась), (HL) - смотрел?, A-(HL). Для CPIR/CPDR (а может и CPI/CPD - почему бы и) может еще PC (адрес самой команды CPIR/CPDR), причем еще смотреть надо какой байт, старший или младший. Думаю, стоит именно вот эти варианты рассматривать, для них тщательный тест делать, остальные версии вряд ли иммет смысл сейчас муссировать.

(Хм, а что если MemPtr - не один, и в нескольких таких регистрах за 1 такт выполняется несколько инкрементов нескольких регистров, а попасть в xy в команде bit может из какого-нибудь, и не всегда одного и того же)

Vladimir Kladov

27.02.2006, 19:26

С CPI/CPD/CPIR/CDPR ясно:
первые 2 не влияют, вторые влияют, если команда выполняется более чем 1 раз, действие такое же как для JP на начало команды после каждого исполнения.
Boo-boo, подтверждай. Я пока 3-й тест гляну.

(Хотя конечно, почему же в LD<i,d>[r] по-другому. Хотя, с логикой тут вообще связки может и не быть. Как пришлось, так и сделали).

boo_boo

27.02.2006, 20:43

С CPI/CPD/CPIR/CDPR ясно:
первые 2 не влияют, вторые влияют, если команда выполняется более чем 1 раз, действие такое же как для JP на начало команды после каждого исполнения.
Boo-boo, подтверждай.
насчет "как jp" похоже,
однако, в предыдущей редакции теста аналогичный результат давала CPI (не помню, при каких условиях, исходника нет, надо дизасмить)...

уточняю гипотезу -- CPI и CPIR обнуляют memptr при BC=1, и инициализируют его своим адресом (?или адресом +1?) в остальных случаях. CPD и CPDR не трогают memptr при BC=1 и инициализируют его адресом в остальных случаях.

завтра выкачу очередной вариант теста -- проверим CP*, заодно прочие блочные команды при аналогичных условиях (а вдруг?), ну и еще кой-чего до кучи.

boo_boo

27.02.2006, 20:48

Если дашь тест в формате TAP или TZX то протестю на оригинальном ZX Spectrum+. Если надо, могу посмотреть чем камень в нём стоит.о, здорово, сделаю завтра, вместе с новым вариантом теста :)

Vladimir Kladov

27.02.2006, 21:18

Если смотреть на тест 3, то ничего CPI/CPD не обнуляют. Если конечно правильно понял, что во втором проходе @set@ означает что до теста memptr установлен, и проверка идет в том числе на то, что команда вообще его "сбрасывает".

Я кстати замучился смотреть на тест 3. Сравнивать неудобно. Ты бы память инициализировал как-ниудь перед тестом, что ли. А то повторно тест запускать становится неинтересно, + и - вообще перестают совпадать. Различаются по + и - даже железные тесты. Сравнивалка тектовых файлов просто все считает насовпавшим (когдя я свои резултаты хочу сравнить), и приходится долго смотреть глазьями. Жуть!

boo_boo

27.02.2006, 21:39

Если смотреть на тест 3, то ничего CPI/CPD не обнуляют. Если конечно правильно понял, что во втором проходе @set@ означает что до теста memptr установлен, и проверка идет в том числе на то, что команда вообще его "сбрасывает".
смотрю на результат последнего теста, вон на 1м проходе, при сброшенном memptr, все cpi дают 00, все cpd тоже 00, на втором, при установленном memptr, cpi опять 00 дают, а cpd 11. те cpi обнуляют, а cpd все пофиг.

память инициализировать? O__o.... ок, сделаю :rolleyes:

icebear

28.02.2006, 13:27

Сравнивалка тектовых файлов просто все считает насовпавшим (когдя я свои резултаты хочу сравнить), и приходится долго смотреть глазьями. Жуть!

советую утилитку CompareIt! показывает именно несоотвествия построчно, выделяя их цветом. удобнее.

Sinus

28.02.2006, 14:17

#ifdef OFFTOPIC

diff поможет отцам русской демократии?
или если под вындофсь, то тотал командер тож неплохо сравнивает

#endif // OFFTOPIC

Shaos

28.02.2006, 14:46

diff поможет отцам русской демократии?
или если под вындофсь, то тотал командер тож неплохо сравнивает

Под вынь мелкомягкие злобные оффтопики еще имеют WinDiff - красиво всё раскрашивает, показывая что куда перенесено и т.д.

Vladimir Kladov

28.02.2006, 21:07

утилит много (я предпочитаю WinMerge), но фишка в том, что они все натыкаются на строки с разными +/-, хоть бы там и были одинаковые 0/1 в флажках. Неудобно. Так что проинициализируй. Плиз.

(оно конечно утилитку написать - 10 минут максимум, чтобы во всех файлах заменила все + на - в первой колонке, но ведь интересно и на эти флаги глянуть). А, кстати, в комментах по CPI / CDP мало информации (опять в дебугер лезть). Ну, я размечтался. Значит CPI говоришь, обнуляет. Просто обнуляет, или все-таки из откуда-то еще берет? В следующем тесте будет разборка?

Кстати, мне кажется, уже можно оставить те команды, которые уже прояснились, и заняться только CPxx, INxx, OTxx (или хотя бы в начало их поставить, чтобы легче отладчиком смотреть) Или что-то еще не стыкуется?

boo_boo

28.02.2006, 23:35

все натыкаются на строки с разными +/-, хоть бы там и были одинаковые 0/1 в флажках. Неудобно. Так что проинициализируй. Плиз. не нужно инициализировать :) незачем вообще выводить биты кроме 5 и 3 -- это же флаги после bit (hl), с которыми ясно все, а от предыдущей команды только C остается. если тебя С интересует, могу оставить плюсики, а перед bit (hl) выставлять hl, а то этот hl скачет где ни попадя, неудивительно, что флаги всегда разные :rolleyes:

...добавил подробные тесты для блочных команд.... выложу очередной тест в железячную тему через пару минут

boo_boo

01.03.2006, 00:26

Если дашь тест в формате TAP или TZX то протестю на оригинальном ZX Spectrum+. Если надо, могу посмотреть чем камень в нём стоит.
вот :)

CHRV

01.03.2006, 00:26

...добавил подробные тесты для блочных команд.... выложу очередной тест в железячную тему через пару минут
Чуствую скоро мы получим тест CPUid ;).

boo_boo

01.03.2006, 00:48

Чуствую скоро мы получим тест CPUid ;).о, как раз недавно думал об этом -- добавить для верности к к/сумме состояние флагов _перед_ bit (hl), еще тест DAA, и в результате недурственный CPUid получится :rolleyes:

boo_boo

01.03.2006, 13:41

немного о битах 3и5 есть в статье 'система' спектрофон 11это все (причем, больше и подробнее) есть и у янга. с 3 и 5 битами F давно все понятно для всех инструкций... кроме bit n,(hl) :rolleyes:

icebear

01.03.2006, 13:59

вот :)

ОК, сделаю. Этот тест сохраняет какие-либо результаты? Мне придётся их как-то обратно в TAP загонять, а как это сделать, я ещё не знаю. Посему сразу результата не будет, но я постараюсь как можно быстрее, мне самому интересно :)

boo_boo

01.03.2006, 14:06

ОК, сделаю. Этот тест сохраняет какие-либо результаты? Мне придётся их как-то обратно в TAP загонять, а как это сделать, я ещё не знаю. Посему сразу результата не будет, но я постараюсь как можно быстрее, мне самому интересно :)ага, записывает в конце лог, обычным save -- адрес/длина блока указаны в васике.

RamTop

02.03.2006, 13:43

Ребят, вам не нужен Z80H для теста? Дома лежит, сейчас маркировку посмотреть не могу. Правда реала у меня не осталось.

boo_boo

02.03.2006, 17:35

Ребят, вам не нужен Z80H для теста? Дома лежит, сейчас маркировку посмотреть не могу. Правда реала у меня не осталось. неплохо б! :) ...народ, у кого реал есть? может дык?

icebear

02.03.2006, 17:38

неплохо б! :) ...народ, у кого реал есть? может дык?

Кстати, могу на Спринтере проверить, который Sp97. Но всё упирается во время :(

boo_boo

02.03.2006, 18:03

Кстати, могу на Спринтере проверить, который Sp97. Но всё упирается во время :( z84 там? интересно... так на спринтере вроде trd читаются/пишутся, от силы пару минут все займет?

icebear

02.03.2006, 18:07

z84 там? интересно... так на спринтере вроде trd читаются/пишутся, от силы пару минут все займет?

Z84C15. Спринтер рабочий, протестировать быстро получиться. Кстати, на турбе или нет? Возьму последнюю версию теста (5), из которой я уже сделал WAV, что бы загрузить в ZX Spectrum+ :) Вчера не получилось :(

boo_boo

02.03.2006, 18:37

Кстати, на турбе или нет? по идее, без разницы. прогони так и так, глянь сумму -- одинаковая?

boo_boo

03.03.2006, 00:46

дополнение по результатам от CHRV (http://zx.pk.ru/showthread.php?p=40720#post40720) :

- LDIR/LDDR
не влияет на memptr при BC=1 (те при однократном исполнении)
при BC<>1 memptr=адрес инструкции+1

- CPI
memptr=0 (?)

- CPIR
при BC=1 или A=(HL) как CPI,
в остальных случаях -- непонятно... (для этого теста в обоих битах 1, может, memptr=HL?)

- CPDR
при BC=1 или A=(HL) не влияет (как и CPD)
в остальных случаях memptr=адрес инструкции

- INI
memptr=BC+1

- IND
memptr=BC

INIR/INDR
memptr=0 (?)

OUTI/OUTD
memptr=f(BC), что за f - неясно. первое, что приходит в голову, и с чем совпадает результат: memptr=BC >> 2, но как-то это дико О__о

OTIR/OTDR
memptr=0 (?)

к слову, любопытно, каким образом проектировались клоны? к примеру, сомневаюсь, что КР1858ВМ3 делался по лицензии ZiLOG, но memptr там есть, и ведет он себя так же, как на фирменных процах (хотя по другим вещам, вроде DAA, этот кристалл отличается от Z80).

Titus

03.03.2006, 01:25

к слову, любопытно, каким образом проектировались клоны? к примеру, сомневаюсь, что КР1858ВМ3 делался по лицензии ZiLOG, но memptr там есть, и ведет он себя так же, как на фирменных процах (хотя по другим вещам, вроде DAA, этот кристалл отличается от Z80).

В доках описывающих буржуйские/российские аналоги - ВМ3 - единственный процессор, про который уаказано, что он не точная копия, а лишь 'функциональный аналог Z80' :o

А чем он по DAA отличается?

boo_boo

03.03.2006, 01:53

В доках описывающих буржуйские/российские аналоги - ВМ3 - единственный процессор, про который уаказано, что он не точная копия, а лишь 'функциональный аналог Z80' :o

А чем он по DAA отличается?странно, зачем разработчики "функционального аналога" точно симитировали недокументированную и никому непонятную фишку (собсно bit(hl)), оставив за бортом вещи поважнее.

по DAA - вообще бред какой-то, не только недокументированные флаги, даже S и H не пойми как себя ведут.

boo_boo

03.03.2006, 03:00

кстати, глянул на vhdl-сорцы t80 (http://www.opencores.org/cvsweb.shtml/t80/), чего-то там мутится с 5 и 3 битами F для bit (HL) и bit (i+d). вот только не пойму, что -- чтоб понять, надо с vhdl разбираться :o

Titus

03.03.2006, 04:37

странно, зачем разработчики "функционального аналога" точно симитировали недокументированную и никому непонятную фишку (собсно bit(hl)), оставив за бортом вещи поважнее.

по DAA - вообще бред какой-то, не только недокументированные флаги, даже S и H не пойми как себя ведут.

Пока что мое имхо такое - либо внутри вм3 стоит опять же буржуйский кристал каккой-либо модификации Z80, либо при стачивании кристала, с последующим воспроизведением его заново, наши умельцы чего-то изменили/потеряли/недосмотрели ;)

Vladimir Kladov

03.03.2006, 15:50

в виде TR-DOS. Есля я ничего не напутал, то при запуске спросит имя (введите буковку этого хватит), и запишет на диск 4 файла общим размером 128К - AF после DAA для каждого из 65536 вариантов исходных AF. Т.е. первые 2 байта - это F, A после DAA когда на входе была AF=0000, вторые 2 байта F, A, когда было AF=0001 и т.д.

Прада, TR-DOS диск махонький получился...
А, вот, одну строчку в басике забыл. Теперь добавил. Можете попробовать на нестандартном прогнать. Сравним с оригинальным Z80.

Vladimir Kladov

03.03.2006, 19:25

Насчет разницы между CPI/CPIR CPD/CPDR мне это как-то очень подозрительно. Откуда это вдруг процессору известно, что предыдущая выполнявшаяся команда тоже была CPIR или CPDR, а не другая какая-нибудь. (В том смысле, что он ведь их по одной выполняет) Или он держит где-то у себя такой флажок. Или как получается, что он сбрасывает только для CPIR которая только 1 раз отрабатывает, но берет из HL (допустим) в других случаях. Ведь он при повторном исполнении если бы не знал что перед этим тоже была CPIR опять бы его сбросил. С командой CPDR все понятней если CPD ничего не трогает.

Надо бы еще добавить "двойные" тесты, когда после "сброса" или "установки" флажков вполняется сначала CPI, а потом опять CPI или CPIR. Вообще, нужно смотреть все комбинации:

CPI : CPI
CPI : CPD
CPI : CPIR (BC=1)
CPI : CPIR (BC=2)
CPI : CPDR (BC=1)
CPI : CPDR (BC=2)
CPD : CPI
CPD : CPD
CPD : CPIR (BC=1)
CPD : CPIR (BC=2)
CPD : CPDR (BC=1)
CPD : CPDR (BC=2)
CPIR (BC=1) : CPI
CPIR (BC=1) : CPD
CPIR (BC=1) : CPIR (BC=1)
CPIR (BC=1) : CPIR (BC=2)
CPIR (BC=1) : CPDR (BC=1)
CPIR (BC=1) : CPDR (BC=2)
CPIR (BC=2) : CPI
CPIR (BC=2) : CPD
CPIR (BC=2) : CPIR (BC=1)
CPIR (BC=2) : CPIR (BC=2)
CPIR (BC=2) : CPDR (BC=1)
CPIR (BC=2) : CPDR (BC=2)
CPDR (BC=1) : CPI
CPDR (BC=1) : CPD
CPDR (BC=1) : CPIR (BC=1)
CPDR (BC=1) : CPIR (BC=2)
CPDR (BC=1) : CPDR (BC=1)
CPDR (BC=1) : CPDR (BC=2)
CPDR (BC=2) : CPI
CPDR (BC=2) : CPD
CPDR (BC=2) : CPIR (BC=1)
CPDR (BC=2) : CPIR (BC=2)
CPDR (BC=2) : CPDR (BC=1)
CPDR (BC=2) : CPDR (BC=2)

Разумеется HL должен показывать куда-нибудь туда, где A <> (HL) при всех сравнениях (можно вроде бы уже считать, что этот случай эквивалентен последнему выполнению). Из таких тестов можно:
1) получить подтверждение, что такая память у процессора о предыдущей команде есть;
2) узнать, различает ли он 2 команды CPIR : CPIR, CPI : CPI и т.д. или считает их продолжением цепочки. Кстати, можно бы еще для интереса сразу воткнуть что-нибудь нейтральное между и посмотреть еще такие тройные тесты:
CPI : NOP : CPI
CPIR (BC=1) : NOP : CPIR (BC=1)
CPIR (BC=2) : NOP : CPIR (BC=1)
CPIR (BC=2) : NOP : CPIR (BC=2)
3) учитывает ли этот гипотетический флажок две разные команды LDIR действительно по разным адресам как одну длинную команду LDIR.

INI/IND/OUTI/OUTD вместе с R уже не так интересны. А вот CPI/CPIR не очень устраивает. Заодно надо бы подергать HL в разные места памяти, пусть покажет, действительно ли из HL берутся флажки (из HL+1 в смысле?).

Vladimir Kladov

03.03.2006, 22:07

опаньки. Наверное такой флажое для процессора - это PF. Т.е. он смотрит на PF, а не на какой-то там еще флажок, предполагая, что PF = 0 - признак "начала" последовательности, и тогда и сбрасывает в CPIR memptr. А после cpIR в котором BC <> 0, PF=1, и тогда он не сбрасывает. Но PF может быть = 1 не только после CPIR. Надо еще в этом направлении тесты расширить: флаги до команды тоже пробовать и сбрасывать, и устанавливать. По крайней мере это надо повторить и для CPD / CPDR и для LDI / LDD / LDIR / LDDR. Теплее? :)

Vladimir Kladov

04.03.2006, 11:43

опаньки, опаньки. Мой предыдущий пост - лажа. PF совершенно не при чем. Флажок в ЦПУ есть какоц-то. Я попробовал использовать в качестве флажка адрес предыдущей выполнявшейся команды, если он тот же, то выполняется та же команда, и сброс не делается, т.е. остается результат от предпоследнего выполнения CPIR (установка).

Теперь насчет того откуда установка. Если брать HL или HL-1 (т.е. после и до выполнения команды), то пара результатов не сходится. Сошлось когда я просто стал впихивать FF в memptr. Результат странный. Сейчас еще попробую что-нибудь.

Увы. Попробовал все, что пришло в голову: A-(HL), A-(HL)-F, A - ничего не подходит. Только чистый FF. Надо смотреть с разными HL и выяснять, что может влиять еще на memptr в CPIR. Раз HL не подходит.

Двойные (и тройные) тесты все еще интересуют. Хочется выяснить, достаточно ли анализировать адрес предыдущей команды, или надо запоминать именно саму команду (код операции), чтобы задействовать как флажок "продолжения" для CPIR. Для прочих команд это менее актуально.

GriV

04.03.2006, 12:59

Ребята (бу-бу и Владимир Кладов)
Есть такая просьба - может быть сделать чётко структурированный документ (файл-текст) с описанием регистра и влиянием на него команд?

Если честно там чуть повыше было описание (от Vladimir Kladov), только оно сильно сокращённое.

Vladimir Kladov

04.03.2006, 13:24

куда же подробнее-то? Boo-boo все написал, что на момент известно, и даже больше. Вот только с влиянием регистра HL на результат CPIR видимо все-таки промах. Сейчас у меня 5-й проходит, бьюсь, чтобы и в Fast-режиме проходил тоже.

Все работает - в нынешних пределах. Надо бы добавить выбор ЦПУ. Как их именовать, пока не знаю, но не перечислять же все маркировки. Есть идея (насчет "медали" :wink: ).

Хотелось бы, чтобы на "аналоге", который отличается по DAA, все-таки прогнали тест, что я предложил. (А там больше ничего не отличается? zexall-тест что дает, тоже интересено).

boo_boo

04.03.2006, 15:51

boo_boo

04.03.2006, 15:53

Хотелось бы, чтобы на "аналоге", который отличается по DAA, все-таки прогнали тест, что я предложил. (А там больше ничего не отличается? zexall-тест что дает, тоже интересено).кажется, пора делать обьединенный z80 test-pack ;)

GriV

04.03.2006, 15:56

Каксательно учёта типа модификации - тут уже вытащили для оригинального спекк+ компутера тест, так что я так понимаю на него и надо ориентироваться. Ну и как вариант предусмотреть смену камня - ну чтобы были такие же результаты как и для указанных CHRV процов проще говоря использовать таблицу для работы с этими командами.

Возможный вариант различной работы команд и влияния на регистр memptr и как следствие на регистр флагов - может быть дело вот в чём. Регистр фактически есть набор триггеров которые собираются на подложке проца в едином цикле. Перед установлением нового значения обычно всегда используется сброс регистра и соответственно сброс триггеров (асинхронные RS-триггеры и основанные на них асинхронные регистры). Мысль же следующая: может быть в разных типах процессоров отличается (может быть наносекунды) время прихода сигнала сброса на регистр memptr? Т.е. в одних случаях оно приходит до того как его значение частично перешло в регистр флагов а в других -после этого. Или - может оно варьируется? Т.е. даже для одного камня может быть то "0" то пресловутое "high_byte and 28"? И если запустить программу в цикле проверять такие вот спорные (на разном железе) моменты, то можно получить (на одном камне) разные результаты? И ещё одно предположение в том же ключе - время прихода сигнала сброса отличается для разных ревизий процессоров по разному, потому скорей всего серия процессоров будет показывать одинаковые результаты, другая же серия этих же процессоров будет показывать другие результаты на этих же примерах?

И сразу вопрос такого плана - какое отличие для существующих программ (кроме тестовых) даёт учёт регистра memptr в эмуляторах? Можно ли как нибудь использовать этот регистр в процессе написания программ? Каким видится (кроме тестового) использование этого знания о регистре memptr?

boo_boo

04.03.2006, 16:26

И сразу вопрос такого плана - какое отличие для существующих программ (кроме тестовых) даёт учёт регистра memptr в эмуляторах? Можно ли как нибудь использовать этот регистр в процессе написания программ? Каким видится (кроме тестового) использование этого знания о регистре memptr?насчет отличия -- неизвестно толком :) может быть, те несколько программ, которые не работают на том или ином эмуляторе, возьмут вдруг, и заработают, делалось же где-то LD A,hibyte:[опкод_выставляющий_недокум ентированные флаги]:PUSH AF : POP IX : JP IX.
использовать можно для защиты -- заксорить по нему, и эмуляторы в ауте.
для распознавания марки процессора совместно с другими тестами на недокументированные флаги и опкоды...
ну и, чего греха таить, у этих исследований есть побочный продукт -- я несколько малозаметных глюков в ядре эмуляции Z80 выловил, не удивлюсь, если не я один ;)

Vladimir Kladov

04.03.2006, 16:39

что еще за тест? "тут уже" это где, почему не знаю?
тут уже вытащили для оригинального спекк+ компутера тест
Если про zexall, то он как раз не особенно что-то помогает, даже если и видит какую-то разницу (а разницу по комнде bit n,(hl) и вовсе не видит и не сможет увидеть - кривой он). Если он видит разницу по команде, то дальше на эту команду надо отдельный тест делать, уже свой, и его и гонять.

Насчет времени установки, микросекундой позже, микросекундой раньше - по барабану. Значение memptr установленное в одной команде, используется в последующих (причем только в bit n,(hl)), так что ни микросекунды, ни тем более наносекунды нас не интересуют. Сброс может и есть, и может даже установка есть (вроде как в CPIR). Мы в любом случае можем только находиться в состоянии "гипотеза близка к истине, потому что нет опровергающего результата тестирования" - принимаем ее за истину. Стоит появиться хотя бы одному опровергающему результату - тест приходится расширять и гипотезу модифицировать.

Применение вижу только одно: можно заксоривать часть кода или данных флажками после команды bit n,(hl), выполненной после разных команд, влияющих на memptr, и в итоге получить прогу, которая не будет работать на старых эмуляторах или на несовместимых клонах чипа. Мне пока что неизвестно ни одной демки или проги на спеке, которая бы не работала из-за команды bit n,(hl), точнее, из-за флажков, которые не совпадают с железными.

Так что, проделанную работу можно считать отличным спортивным достижением (хотя и не самым абсолютным - есть еще шанс добиться еще более точных результатов), но как и спорт вообще - толку от этого не слишком много.

GriV

04.03.2006, 18:52

Насчет времени установки, микросекундой позже, микросекундой раньше - по барабану

Всё таки есть разница, может ты не очень внимательно прочитал, скорей всего сам регистра memptr переносится в регистр флагов ... как бы сказать ... случайно что ли, т.е. вообще то авторами Z80 не предполагалось что такое будет и потому вот так и получается что эти данные от серии к серии ЦП разный CRC дают.

А насчёт тестов я так понял, что можно только проверять эмуль это или нет (или может это совсем ущербный вариант Z80), причём чем старей эмуль так я понял тем меньше вероятность что этот регистр там зарелижен (((-:

И ещё, спортивное достижение или нет, но работа проделана хорошая ((((-:

P.S. Сорри, чуток пропустил вопрос про спекк+ - вот оно, я посмотрел - к сожалению CRC уникальнные http://zx.pk.ru/showpost.php?p=40776&postcount=50

P.P.S. Прелагаю выдать золотую медаль Бу-Бу и Владимиру Кладову за беспримерную стахановскую работу по установлению истинного лица глюка по имени memptr ((((-:

P.P.P.S. На серебро не претендую, но от бронзы бы не отказался ((((-:

boo_boo

04.03.2006, 19:05

и потому вот так и получается что эти данные от серии к серии ЦП разный CRC дают. пока не похоже, чтобы от серии к серии цп что-то менялось во флагах bit n,(hl).

А насчёт тестов я так понял, что можно только проверять эмуль это или нет (или может это совсем ущербный вариант Z80), причём чем старей эмуль так я понял тем меньше вероятность что этот регистр там зарелижен (((-: пока что вообще нет эмулятора, где эта фича реализована в полном обьеме.

Vladimir Kladov

04.03.2006, 20:28

boo_boo

04.03.2006, 22:23

уже есть: я выкладываю свой EmuZWin 2.7 билд 2.7, весь нунешний накопленный материал уже включен.

Случайности там никакой нет, все по четкому алгоритму. Я думаю, при проектировании первого кристалла либо просто перепутали источник для флажка в команде bit, либо наоборот рассчитывали получить еще один источник "псевдослучайных" чисел, высовывая наружу "хвостик" совершенно внутреннего регистра для промежуточных вычислений.

Хм, ice - он для оригинального спека сделал. Не смотрел. Но думаю, там все то же самое. Boo boo, будешь поглядеть, скажи. И как будут еще тесты (и результаты), обязательно приму участие. Мне как человеку далекому от реалов (по ящикам 2 штуки валяются, а руки у меня не под паяльник заточены), всегда было интересно сделать максимально реалистичный эмуль. результат от icebear полностью совпадает с результатами для обоих родных процов CHRV, что неудивительно (а сумма не сходится из-за OUT(0000),0 -- очевидно CHRV тест в 128 режиме прогонял, и 0000 дешифровалось аналогично 7FFd, врубилось ПЗУ0 и что-то в ходе этого беспредела испортилось %)

Vladimir Kladov, я сейчас 6ю версию теста делаю, давай ты, как автор "флажковой теории", выберешь из той кучи несколько наиболее показательных тестов CPI/CPD[R] для подтверждения/опровержения этого дела?

boo_boo

04.03.2006, 22:24

Хм, ice - он для оригинального спека сделал. Не смотрел. Но думаю, там все то же самое. Boo boo, будешь поглядеть, скажи. И как будут еще тесты (и результаты), обязательно приму участие. Мне как человеку далекому от реалов (по ящикам 2 штуки валяются, а руки у меня не под паяльник заточены), всегда было интересно сделать максимально реалистичный эмуль. результат от icebear полностью совпадает с результатами для обоих родных процов CHRV (а сумма не сходится из-за OUT(0000),0 -- очевидно CHRV тест в 128 режиме прогонял, и 0000 дешифровалось аналогично 7FFd, врубилось ПЗУ0 и что-то в ходе этого беспредела испортилось %)

Vladimir Kladov, я сейчас 6ю версию теста делаю, давай ты, как автор "флажковой теории", выберешь из той кучи несколько наиболее показательных тестов CPI/CPD[R] для подтверждения/опровержения этого дела?

CHRV

04.03.2006, 23:34

результат от icebear полностью совпадает с результатами для обоих родных процов CHRV (а сумма не сходится из-за OUT(0000),0 -- очевидно CHRV тест в 128 режиме прогонял, и 0000 дешифровалось аналогично 7FFd, врубилось ПЗУ0 и что-то в ходе этого беспредела испортилось %)

ДА подтверждаю режим был 128.

boo_boo

05.03.2006, 01:14

ДА подтверждаю режим был 128. хе, я сперва офигел просто -- как это после OUT какие-то флаги %)
в очередной версии сделаю переключение в 48к от греха подальше :rolleyes:

Vladimir Kladov

05.03.2006, 09:25

а я на контрольную сумму и не смотрел никогда. Потому что машины могут быть разные и никто не знает насколько. Раз уж у нас есть в тесте Out, outd, otdr, а иногда неожиданно разными могут быть и результаты in (из того же порта FF).

Я просто называю это дело "флажком", физически это может быть что угодно, регистр адреса предыдущей команды, регистр какой-нибуль суммы, или правда флажок. Нам-то какая разница, если оно действует как флажок. Я пока остановился на регистре предыдущей команды, потому что в эмуляторе так проще, если считать, что каждая команда CPIR выполняется как отдельная команды.

Загоняй все предложенные тесты. Мне кажется будет показательней. Даже если ничего не изменит, лишнее подтверждение тоже не лишнее. И HL подвИгай обязательно. Мне приходило в голову что влиять может вообще DE наприсер, который по логике вообще не при чем. Тоже можно подвигать, а вдруг и он тут при чем.

GriV

05.03.2006, 09:43

всё таки насчёт контрольной суммы несколько не ясно мне - я так понял из-за чего она может отличаться (сработал дешифратор), а для всех остальных что ли команд всё идентично???

Тогда непонятно вот что - у Влодека было 5 (!) тестов - и что - каждый раз дешифратор срабатывал по разному - и какждый тест получался изза этого разный CRC? И потом, на спекк+ у медведя тоже получился другой CRC (отличный от всех остальных)?

Если дело только в том, что (всё-таки) срабатывает дешифратор адреса и из-за этого колбасится проц, тогда исключить такую команду или перед проверкой отключать дешифратор (уходить в глубокий 48К) - в любом случае надо новую версию теста чтобы учесть все эти нюансы, я же пока у себя пятую версию теста погоняю, как шестая будет и её прогоню.

Vladimir Kladov

05.03.2006, 10:05

да сдалась тебе эта контрольная сумма, Грив. Нам значения флажков нужны, а не просто КС. КС совпадает только когда уже весь тест проходит, а для этого еще потрудиться надо.

boo_boo

05.03.2006, 12:33

а я на контрольную сумму и не смотрел никогда. Потому что машины могут быть разные и никто не знает насколько. Раз уж у нас есть в тесте Out, outd, otdr, а иногда неожиданно разными могут быть и результаты in (из того же порта FF). в 5м тесте я F после IN* суммирую по маске -- как раз, чтобы не смотря на такие вещи сразу понятно было, что за процессор.

Загоняй все предложенные тесты. Мне кажется будет показательней. Даже если ничего не изменит, лишнее подтверждение тоже не лишнее. И HL подвИгай обязательно. Мне приходило в голову что влиять может вообще DE наприсер, который по логике вообще не при чем. Тоже можно подвигать, а вдруг и он тут при чем.
сделаю, пожалуй, отдельный большой тест для CPI*, по разным адресам.

boo_boo

05.03.2006, 12:45

Тогда непонятно вот что - у Влодека было 5 (!) тестов - и что - каждый раз дешифратор срабатывал по разному - и какждый тест получался изза этого разный CRC? И потом, на спекк+ у медведя тоже получился другой CRC (отличный от всех остальных)?до 5 версии сумма делалась вообще абы как, включая INы и тп. а в 5й, если вычесть недоразумение с OUT(0), сумма для спек+ icebear'a совпадает с суммами Z0804*, а сумма Wlodek'а с сумами для *ВМ1.
а вообще, надо бы нормальную CRC делать, а то простое суммирование может показать только что результаты различаются, а подтвердить, что сходятся -- нет.. :rolleyes:

Wlodek

05.03.2006, 14:08

Результаты теста DAA от Wlodek-а.
Компьютер: Pentagon 128.
Режим: Бейсик-128.

Titus

05.03.2006, 14:14

а вообще, надо бы нормальную CRC делать, а то простое суммирование может показать только что результаты различаются, а подтвердить, что сходятся -- нет.. :rolleyes:

Хи-хи. Хорошее определение. Хотя по-хорошему, CRC ничем не лучше ADD в плане относительности точности, просто лишает последовательность периодичной корреляции :v2_cool:

Vladimir Kladov

05.03.2006, 16:44

Посмотрел рультаты DAA, почесал репу, прогнал еще через Spectaculator и Unreal. Все 4 теста попарно различаются друг от друга. Причем EmuZWin-Unreal, EmuZWin-Wlodek, Unreal-Wlodek только для исходных AF=0000, 4000, 8000, C000. Соответственно, гораздо поболее разницы (и примерно для тех же исходных значений) у всех трех - от Spectaculator'а. Вот вам и ZexAll: все 3 эмуля и комп Влодека проходят через тот тест вроде бы на ура...

Мне чтобы прояснить картину надо еще 1 результат: на машине, у которой есть отличие от Влодековской по тесту Boo-boo (той, что я пометил как "Original Z80"). Плииз!

(Хотел сюда положить результат, но чего-то плохо жмется, 600К получается. Лучше в исходном виде пусть будет здесь. Я вам лучше экзешничек на 10К положу: на него надо бросить 1 из 4х хобета-файлов, которые получились, файлы само собой должны быть все 4 и лежать рядом - а то прога сломается, на коленке сделана. Создает текстовой файл там же рядом, его и смотреть и с другими сравнивать).

Приписка: видимо, DAA какие-то флажки не трогает, вот и отличаются первые строки в блоках. (Видите, я еще не безнадежен). Но тогда если у Влодека стандартный камень по DAA, то какой же нестандартный? И почему Спектакулятор тоже походит тест DAA в ZEXALL, у нас различия с ним побольше будут. В общем ждем прояснения. Может CHRV выберет время, там тест меньше минуты занимает, дольше диски гонять с ИБМ и обратно.

Приписка2: хотя если он не трогает какие-то флаги, то опять же, они должны были в 0 оставаться... Тьфу! Котороче тесты еще будут, будет яснее.

Приписка 3: с причиной разобрался, исправленная версия просмотрщика результатов показывает EmuZWin=Unreal=Wlodek <> Spectaculator. Жду результов от CHRV!

Shaos

05.03.2006, 17:42

Z84C15. Спринтер рабочий, протестировать быстро получиться. Кстати, на турбе или нет? Возьму последнюю версию теста (5), из которой я уже сделал WAV, что бы загрузить в ZX Spectrum+ :) Вчера не получилось :(

А вот в доке по ZX-Spectrum+ написано что там стоит Z80 с маркировкой NEC D780C-1 - это тот же Z80 или клон или лицензировання точная копия?

SMT

05.03.2006, 18:30

Хотя по-хорошему, CRC ничем не лучше ADD в плане относительности точностину как же.. обязана обнаруживать одиночные и n-кратные ошибки, а также m сбоев подряд. n,m - зависят от длины CRC, для 32 чисел не помню

icebear

06.03.2006, 12:28

А вот в доке по ZX-Spectrum+ написано что там стоит Z80 с маркировкой NEC D780C-1 - это тот же Z80 или клон или лицензировання точная копия?

Это надо спросить у NEC :) Что касается лицензионного производства, то я знаю только о японцах (благодаря им появился HD64180, а потому уже Z180) и SG. Вроде Goldstar делал ещё копии. Насколько точно они все повторяли оригинал я без понятия - я даже представления не имею, каким образом делаются подобные копии.

Свой ZX Spectrum+ я пока ещё не раскручивал, надо посмотреть будет. Спринтер сегодня попытаюсь проверить, кстати ты или CHRV тоже могли бы это сделать.

boo_boo

07.03.2006, 00:41

не все так просто оказалось с этими CP*... да, при выполнении цепочек из 2х команд результат неожиданный - например CPD:CPD дают 11, CPIR:CPI тот же результат, что и просто CPIR, CPIR : CPD -- memptr=адрес_инструкции_CPIR+1...

при этом не похоже, чтобы на memptr влияли регистры, только адрес инструкции и предыдущая(ие?) инструкции.

вижу два варианта -- либо memptr после CP* зависит от предыдущего значения memptr, либо в деле действительно замешан еще один внутренний регистр.
выяснить просто -- надо посмотреть на поведение этих инструкций после инициализации memptr разными значениями.

пристегиваю результаты в виде текст. файлов, только для Z0840008 (для остальных камней все то же самое)

ЗЫ а вдруг и на некоторые другие выставляющие memptr команды влияет его начальное значение? :confused:

Vladimir Kladov

18.03.2006, 12:56

не все так просто оказалось с этими CP*... да, при выполнении цепочек из 2х команд результат неожиданный - например CPD:CPD дают 11, CPIR:CPI тот же результат, что и просто CPIR, CPIR : CPD -- memptr=адрес_инструкции_CPIR+1...

[skip]

ЗЫ а вдруг и на некоторые другие выставляющие memptr команды влияет его начальное значение? :confused:
А что, может написать письмишко г-ну jw, который мэйнтейнирует z80-documented, чтобы он включил добытую инфу в следующей версии документа (раз уж он обновляется)? Что, boo-boo, скажешь?

boo_boo

18.03.2006, 14:25

А что, может написать письмишко г-ну jw, который мэйнтейнирует z80-documented, чтобы он включил добытую инфу в следующей версии документа (раз уж он обновляется)? Что, boo-boo, скажешь? правильная мысль :) ...неплохо бы довести разбирательство с memptr до логического конца, и тогда уж написать, но CP* меня, сказать по-правде, напугали, уже не очень верится в логический конец :rolleyes:
думаю еще один тест забацать -- для выяснения, что там с outi, и влияет ли хитро установленный memptr на CP*, и отписать, что есть.

Vladimir Kladov

18.03.2006, 15:02

Давай, а то я думал, что уже на этом остановимся. На z80.info есть занятные вещи, логическая внутрення структура, есть даже power-point-презентация для 4х инструкций, что у него внутри происходит. Но пока мало что проясняет. Как и фото процесса с увеличением в 100 раз 8-]

Vladimir Kladov

18.03.2006, 19:34

Вот кстати здесь (http://www.z80.info/z80architektur.htm) на функциональной схеме искомый регистр кажется проглядывается как "Temporary Inder Register". Интересно, все надписи на схеме по-немецки, а эта - на английском.

Vladimir Kladov

18.03.2006, 19:40

И кстати, нашел на Z80.info документ, в котором расписано по циклам сколько чего делается при выполнении инструции. Интереснее всего, что в режиме IM0 прерывание делается за 12 тактов, против 13 в IM1 и 19 в IM2. (Это если "подставляется" RST 38, а в спектруме, похоже, на шине именно FF, так что будет именно 12 тактов и аналогично RST 38. Я к тому, что нигде этой инфы нет, и 1 такт иногда может оказаться решающим. Есть у меня одна демка... надо будет попробовать.

Vladimir Kladov

18.03.2006, 20:21

Невероятно, но - факт! Провел подряд несколько тестов и все ОК!

Дема называется Blava demo. При переходе к части 3 практически всегда сбрасывалась. 1-го такта не хватало!

boo_boo

19.03.2006, 00:19

Невероятно, но - факт! Провел подряд несколько тестов и все ОК!
Дема называется Blava demo. При переходе к части 3 практически всегда сбрасывалась. 1-го такта не хватало! может, его еще из-за чего-то не хватало? очень странно -- в официальном мануале говорится, что при запросе вектора прерывания добавляется 2 wait-a (что отражено на диаграмме), в z80undocumented прямо сказано, что IM0 с RST -- 13 тактов... при этом согласно доке с расписанными циклами, для CALL -- 2 wait'a, а для RST, выходит, 1? CPU ж не знает, что к нему придет, откуда такая дискриминация? ИМХО больше похоже на опечатку в документе с расписанными циклами, иначе вообще непонятно, что к чему O__o

кстати, у меня в z80ex -- 13 тактов на im0-rst, и blava работает стабильно (в zemu)...

насчет temporary index register -- занятно.. похоже, кто-то что-то знает, но молчит :rolleyes:
кстати, вот еще любопытная дока: http://www.funet.fi/pub/msx/mirrors/msx2.com/zaks/z80prg02.htm
там упоминаются некие внутренние регистры w и z, используемые для работы с 16-битными значениями (тк шина данных 8-и битная)

Vladimir Kladov

19.03.2006, 07:26

может, его еще из-за чего-то не хватало? очень странно -- в официальном мануале говорится, что при запросе вектора прерывания добавляется 2 wait-a (что отражено на диаграмме), в z80undocumented прямо сказано, что IM0 с RST -- 13 тактов... при этом согласно доке с расписанными циклами, для CALL -- 2 wait'a, а для RST, выходит, 1? CPU ж не знает, что к нему придет, откуда такая дискриминация? ИМХО больше похоже на опечатку в документе с расписанными циклами, иначе вообще непонятно, что к чему O__o
надеюсь выглядеть будет разборчиво, вставляю:
INTERRUPTS
----------

NMI _ OCF(5)* SWH(3) SWL(3) *Op Code Ignored
SP-1 ---> SP-1 --->

MODE 0 - INTA(6) ODL(3) ODH(4) SWH(3) SWL(3)
(CALL INSERTED) SP-1 ---> SP-1 --->

- INTA(6) SWH(3) SWL(3)
(RST INSERTED)
SP-1 ---> SP-1 --->

MODE 1 INTA(7) SWH(3) SWL(3)
(RST 38H
INTERNAL)
SP-1 ---> SP-1 --->

MODE 2 - INTA(7) SWH(3) SWL(3) MRL(3) MRH(3)
(VECTOR
SUPPLIED)
SP-1 ---> SP-1 --->

кстати, у меня в z80ex -- 13 тактов на im0-rst, и blava работает стабильно (в zemu)...

В Пентагоне - нет проблем. Там ведь нет тормозов в памяти, тактов в кадре хватает с большим избытком. Но она сделана для фирменного 128-го, а там есть contented memory. Вот такой вопрос: с чего начинается работа этой демы после "якобы загрузки"? Т.е. надпись Press Any Key просто мигает на черном фоне и все? А должно мигать - на фоне мультиколорного располосования всего экрана, типа как в overscan.

насчет temporary index register -- занятно.. похоже, кто-то что-то знает, но молчит :rolleyes:
кстати, вот еще любопытная дока: http://www.funet.fi/pub/msx/mirrors/msx2.com/zaks/z80prg02.htm
там упоминаются некие внутренние регистры w и z, используемые для работы с 16-битными значениями (тк шина данных 8-и битная)
Может и они. Sharp - вот кто знает, но молчит.

Titus

19.03.2006, 07:51

Sharp - вот кто знает, но молчит.

С чего вы взяли? Я, например, уверен, что они производили по готовому шаблону, не вдаваясь в детали, и, тем более не разводя схему заново.

SMT

19.03.2006, 08:07

а в RS эта дема идёт? там по тактам im0 и im1 не различаются, кроме возможных тормозов за счёт contented портов

Vladimir Kladov

19.03.2006, 09:02

Мне тут попалась страничка: Sharp сделал z80 на стеклянной пластине. Вроде как скорость движения электронов в такой пластине в 600 раз больше чем в обычном полупроводнике. Инфа за 2002 год. Может и утка. Думаю, чтобы сделать такое, простопо шаблону вряд ли достаточно работать.

В RS не помню, а в Spectaculator'е точно сбрасывалась. И в Spin'е. Щас RS гляну. Так, в RS вообще не пашет, уже после первого скрина на второй с замком не выходит. (Считая скрин Press Any Key нулевым). То ли не может ленту догрузить, то ли еще. А кто сказал, что RS - самый точный? 8-]

boo_boo

19.03.2006, 16:12

честно говоря, фирменному руководству + куче других руководств доверия больше, чем перепечатке из какой-то книги... однако, и весь мир может ошибаться..

MODE 0 - INTA(6) ODL(3) ODH(4) SWH(3) SWL(3)
(CALL INSERTED) SP-1 ---> SP-1 --->

- INTA(6) SWH(3) SWL(3)
(RST INSERTED)

это намек на то, что M1-цикл при IM0 сжирает 6 тактов для любой инструкции? то есть 4 не считая wait'ов? странно...
ИМХО стоит на реале проверить...

Vladimir Kladov

19.03.2006, 22:10

Почему для любой. В Спектруме возможна только инструкция RST38. Эта область за экраном всегда, на шине всегда FF. Т.е. для нас - для любой инструкции RST38.

boo_boo

19.03.2006, 22:21

Почему для любой. В Спектруме возможна только инструкция RST38. Эта область за экраном всегда, на шине всегда FF. Т.е. для нас - для любой инструкции RST38. я имею в виду -- в этой доке при IM0 цикл M1 одинаковой длины для RST и для CALL, почему? крайне это подозрительно и похоже на опечатку. то есть, всякое бывает, но ИМХО то, что какая-то демка заработала, еще ничего не доказывает, проверять надо на реале.

boo_boo

20.03.2006, 22:54

Vladimir Kladov, похоже, мы раздули из мухи слона :)
поглядел я на результаты моего последнего теста от Wlodek'a...
сдается мне, с CP* все просто, как апельсин! а именно:

CPD: memptr=memptr-1
CPI: memptr=memptr+1

CPIR: memptr=адрес_инструкции+2 или как CPI если BC=1 или A=(HL)
или, возможно, нечто типа memptr=(адрес_инструкции+1)+(кол ичество_изменений_PC)

CPDR: memptr=адрес_инструкции или как CPD если BC=1 или A=(HL)

очень похоже!!!! только CPIR надо проверить (при адресах типа F7FD, F7FC, F7F1 и разных BC)

а такие странные результаты для пар были оттого, что 1) первая команда пары тоже меняет BC 2) в предыдущих тестах при "сброшенном" memptr он был на самом деле 0x0001 :rolleyes:

boo_boo

21.03.2006, 14:18

если я прав, то у нас есть: неизвестное число, у которого мы можем узнать 10й и 12й биты, и операции инкремента и декремента этого числа. вопрос: как с помощью всего этого узнать о числе побольше?

Vladimir Kladov

21.03.2006, 16:29

Вообще-то есть немного больше: мы же знаем, откуда оно устанавливается. Вот только хранить теперь придется не 1 только старший байт, а уже оба.

Логика становится более понятной, регистр действительно 1 как и указано на схемах (принципиальных). Все просто замечательно!

boo_boo

21.03.2006, 17:54

итак, зная два бита (из BIT n,(HL)) и отслеживая заем при вычитании (командой CPD), можно запросто найти 4 возможных значения memptr, одно из которых - верное. пример на C:

unsigned short mask=0x2800; /*известные нам биты*/
digit=значение_memptr_которое_мы_ угадываем;

for(m=0; 1 ;m++)
{
if(!(digit & mask))
{
digit--;

if((digit & mask) == mask)
{
printf("одно из возможных значений memptr=%04X\n", (int)m);
}
}
else digit--;

if(m==0xFFFF) break;

}

иначе говоря, нам известны 14 бит.

А ТЕПЕРЬ
задачка для вундеркиндов: есть ли способ отсеять лишние варианты (найти оставшиеся биты)? :rolleyes:

Vladimir Kladov

21.03.2006, 19:32

Я чего не понял?
1+1=10
11+1=100
111+1=1000
1....11+1=11...11
Положить число (FFFFh & not 800h) и прибавить 1 или число (FFFFh & not 2000h) и прибавить 1? Или в чем вопрос?

boo_boo

21.03.2006, 21:22

Я чего не понял?
1+1=10
11+1=100
111+1=1000
1....11+1=11...11
Положить число (FFFFh & not 800h) и прибавить 1 или число (FFFFh & not 2000h) и прибавить 1? Или в чем вопрос? с помощью битовых "окошек" (BIT (HL)) и декремента (CPD) можно однозначно узнать 14 младших бит memptr в общем случае. это уже здорово. вопрос -- можно ли выяснить, что в двух старших битах? там никаких "окошек" нет, поэтому определить из какого бита был заем, и, таким образом, включен он или выключен, так просто не выходит...

подозреваю, невозможно это узнать -- тк мы этих старших бит не видим, их все равно, что нет.

Vladimir Kladov

22.03.2006, 16:07

опять непонятно: если они ни на что не влияют, то зачем про них что-то узнавать?

boo_boo

22.03.2006, 18:42

опять непонятно: если они ни на что не влияют, то зачем про них что-то узнавать?
по большому счету незачем. хотя утверждать на 100%, что не влияют, нельзя.... ладно, 2 бита мелочь, и так будет видно, что к чему. если вся эта затея прокатит (под эмулятором уже работает, а вот что будет на реале?), не удивлюсь, если окажется, что после тех команд, которые "обнуляют" мемптр, в младшем байте остается какая-то муть :rolleyes:

Vladimir Kladov

22.03.2006, 19:54

это дегко проверяется CPDR (кажется). 0-1=11111...11111. Если после обнудения memptr=memptr-1 дает оба бита установленные, то младший обнуляется.

boo_boo

22.03.2006, 20:00

это дегко проверяется CPDR (кажется). 0-1=11111...11111. Если после обнудения memptr=memptr-1 дает оба бита установленные, то младший обнуляется. ничего-ничего, если только CPD действительно декремент memptr, нормально все проверим, по 14и битам :)

boo_boo

29.03.2006, 02:14

итак, поэма о memptr -- читаем!
на этой бодрой ноте дело о BIT n,(HL) предлагаю считать закрытым :rolleyes:
спасибо огромное всем участникам исследований :)

ЗЫ. надо бы еще на английский перевести -- поделиться с буржуями ;) может, возьмется кто-нибудь? могу и я, но позориться неохота -- выйдет в стилистике "ай хаве зе вери гуд фемили"...

Vladimir Kladov

29.03.2006, 20:06

надо бы еще на английский перевести -- поделиться с буржуями ;) может, возьмется кто-нибудь? могу и я, но позориться неохота -- выйдет в стилистике "ай хаве зе вери гуд фемили"...
Ну я перевел в общем, как смог. И исходный текст перевел в win из unix'а :) Иначе в notepad'е не откроешь.

исправляю опечатку в OUTI про before. Остальные сверять сейчас не могу. Ждем выкладывания окончательного варианта, после чего стираю окончательно.

П.С. Все, убираю. Напоминаю: русский оригинал тоже не мешало бы отформатировать с концами строк как в винде, #10#13, иначе в обычном блокноте ничего не видно, хотя и кодировка win1251.

boo_boo

29.03.2006, 21:19

Ну я перевел в общем, как смог. И исходный текст перевел в win из unix'а :) Иначе в notepad'е не откроешь.

Теперь можно посылать письмо? Мне послать? jw(@)dds.nl о, здорово! исправил пару опечаток (before вместо after для одного из outi, еще какая-то мелочь), отослал. :)
заодно написал ему о баге с XF и YF в описании bit n,reg

Vladimir Kladov

29.03.2006, 22:13

выложи и здесь, я свой с опечатками уберу тогда.

boo_boo

29.03.2006, 22:23

выложи и здесь, я свой с опечатками уберу тогда. вот

Vladimir Kladov

30.03.2006, 20:18

Я еще подумал: пока он там новую версию книги "издаст"... Может и на WoS сообщить в раздел emuls? Там по крайней мере тусуются авторы Spectaculator'а, Spin'а и Fuse. Надо отдать им должное: про тайминги они всю доку выложили, потратив на это и свое время и усилия, и "ломали" их с неменьшим старанием.

boo_boo

30.03.2006, 20:51

Vladimir Kladov

31.03.2006, 18:46

я имею в виду подробно расписанную картину того как происходят задержки на contended памяти для фирменных моделей. Это информация тоже была недокументирована и получалась путем экспериментов. Что-то знали и использовали демо-мейкеры для получения своих мультиколорных эффектов, но чаще - просто замеряли время для каждой конкретной демы. Совсем другое дело - предоставить подробное описание того, что происходит на каждом машинном цикле каждой команлы процессора, в зависимости от того, происходит в этом цикле обращение к contended памяти или портам или нет. Только так можно троить эмулятор, который будет корректно воспроизводить вс мультиколоры фирменных моделей, с настоящим ULA.

Я сообщу. Не знаю только как пришпилить им текст. Никогда не видел, чтобы там что-то пришпиливали. Попробую на этот тред ссылку дать в наш форум.

GriV

01.04.2006, 17:52

Круто! Помнится ещё давным давно книгу "Написать игру на ассемблере" читал "...а флаги обозначенный номерами .. потому они обычно не используются..." (-; во так они не используются - по этим флагам определили наличие неведомого memptr (-:

Кстати, сразу вопрос - тут была ссылка на глобальные тесты Z80 - ZEXALL - получается что тест "не знает" про эти особенности - и на нормальных эмуляторах и нормальном железе даёт неверный результат?

boo_boo

01.04.2006, 19:27

Кстати, сразу вопрос - тут была ссылка на глобальные тесты Z80 - ZEXALL - получается что тест "не знает" про эти особенности - и на нормальных эмуляторах и нормальном железе даёт неверный результат? не то, чтобы неверный, но memptr-овские штучки в себя не включающий. собственно, там перед каждой тестируемой инструкцией имеет место быть LD SP,(адрес), причем 11 и 13 биты в этом адресе 0-ые, так что эмуляторы, в которых 3 и 5 флаги просто не устанавливаются, проходят тест на ура :rolleyes:

boo_boo

02.04.2006, 01:22

письмо пришло от Мартина Корта, автора nocash-евской доки и эмуляторов, кроме спасибов и прочего, с указаниями на пару неточностей/неясностей в тексте. посему -- пофикшенная версия.

Vladimir Kladov

02.04.2006, 18:22

Boo-boo, ответь плиз в WoS'е:Филип Кендал спрашивает разрешения на публикацию в ФАКах этой информации.

(У них как раз дизайн поменялся форума, стал на этот похож).

boo_boo

02.04.2006, 18:53

Boo-boo, ответь плиз в WoS'е:Филип Кендал спрашивает разрешения на публикацию в ФАКах этой информации.

(У них как раз дизайн поменялся форума, стал на этот похож). ок, зарегестрюсь там заодно, давно собирался ;)

Vladimir Kladov

03.04.2006, 21:26

ок, зарегестрюсь там заодно, давно собирался ;)
мне не хватает уже ни русского ни английского языка, чтобы выразить свое возмущение. Оказывается некто Фрейзер уже 2 года назад это ВСЕ ЗНАЛ и поместил инфу (или якобы пометил) внутрь архива со своим кросс-асмом - см. сюда: http://www.worldofspectrum.org/forums/showpost.php?p=126176&postcount=17
Я просто фигею - какое умное место он для этого придумал. Нет чтобы просто добавить инфу туда где бы ее нашли другие люди. Кстати, не мешает проверить что там есть. Что-то я не нашел этот кросс-ассемблер. А, нашел: ftp://ftp.worldofspectrum.org/pub/sinclair/tools/pc/TheE-Z80Way.zip
Почитаем. Где тут самый злой диззи. :mad:

+Пока что ничего интересного. То же самое можно было найти и в других доках. Хотя вполне может быть, что найденная мною на WoS версия устарела ибо лежит там уже 4 года без движения. Что ж, подождем когда автор укажет точное местоположение обновленного архива. А то я что-то в гугле искал - нашел только линк на WoS.

Wlodek

04.04.2006, 02:39

мне не хватает уже ни русского ни английского языка, чтобы выразить свое возмущение. Оказывается некто Фрейзер уже 2 года назад это ВСЕ ЗНАЛ

Неужели-таки всё? И про русские процессоры?
Наверно, мы здесь всё же проделали бОльшую работу.
Так что тебе спасибо - заслуженное, я думаю.

icebear

04.04.2006, 11:53

мне не хватает уже ни русского ни английского языка, чтобы выразить свое возмущение. Оказывается некто Фрейзер уже 2 года назад это ВСЕ ЗНАЛ и поместил инфу (или якобы пометил) внутрь архива со своим кросс-асмом - см. сюда:

В comp.sys.sinclair его некто Dunny уже обломал :) Г-н Fraser Ross исследовал поведение команд из группы 16-ти битных арифметических операций. Возмутился он по поводу того, что его не указали в кредитах текста, написаным boo_boo, делая уклон на то, что вы с boo_boo содрали часть инфы из им указаного документа. На что и попал под раздачу от Dunny. Так что всё нормально.

Vladimir Kladov

04.04.2006, 16:31

Лично я этого документа пока он об этом не написал, и в глаза не видел. Boo-boo его тоже не упоминал. Кроме того, толку от его документа: то, что он наисал, и так было известно для 16-разрядного сложения-вычитания, по крайней мере из Шона Янга, задолго до его скрытого в дебрях его асма документа.

Vladimir Kladov

04.04.2006, 21:07

GriV

05.04.2006, 13:37

Ребята! Не обращайте внимания! Всегда найдётся какой нибудь.... человек.. который скажет "у меня содрали" и будет бумажками при этом размахивать доказывающими его причастность. Вы проделали отличную работу - и это все кто хоть чуть чуть следил за этим тредом, могут подтвердить. Может быть кто-то там и сделал что-то похожее, только он 1) не поделился 2) теперь хочет примазаться к чужому успеху (ненужное из 1 и 2 зачеркнуть), так что знайте вы - молодцы. :v2_tong2:

boo_boo

05.04.2006, 16:05

Неужели-таки всё? И про русские процессоры? ну да, только для *ВМ1 отличия по memptr. хотя если есть еще какие-нибудь русские процессоры, можно их тоже протестить ;)

boo_boo

05.04.2006, 16:41

Boo-boo, напомни: ведь INC rp / DEC rp не воздействуют на MEMPTR? А то Фрейзер опять возникает. Или сам туда ответь, а то уже спать пора, полночь наступила (все-таки +6 по гринвичу). не, не воздействуют. в цикле декремента MEMPTR у меня делается INC/DEC BC, и все прекрасно :) пойду загляну на WoS.

Vladimir Kladov

05.04.2006, 18:20

Я сейчас сидел и выяснял историю вопроса с INC/DEC rp. Для того, чтобы определить, не забыты ли были случайно эти инструкции. (Вопрос задал Фрейзер, он считает, что они делают то же что и ADD/SBC для rp). Я так понял, что на самом первом тесте за ними не было замечено ничего подозрительно, и больше в тестах они не участвовали. А зря. Очень не мешало бы воткнуть их (в начало) последнего теста, да и вообще сделать на его основе самый финальный тест, который показал бы непричастность любых подозрительных команд. Ведь даже если какая-то инструкция не устанавливает совсем новое значение в MEMPTR, она может все-таки его изменять. Например, почему бы inc rp не выполнить M++, а dec rp аналогично cpd: M--. В тест обязательно надо включить ВСЕ инструкции с rp, даже невинные LD rp,word. Пусть покажут, что они и в самом деле не при чем.

Boo-boo?

Vladimir Kladov

05.04.2006, 18:25

ну, вот, мой толькошний пост уже опоздал. Хорошо, а то я на код не особо смотрел, просто в списке отдельно этой команды не узрил.

Да, если бы влияло, то по крайней мере в одном случае тест (наверное) зациклился бы - или показал, чтов Memptr 0, или еще дал бы что-то странное.

Я кстати вечор положил тест для IM0 (http://zx.pk.ru/showpost.php?p=44285&postcount=75) - если кто желает прогнать милости прошу, только Пентагон.

Sinus

05.04.2006, 18:48

а почему заточка именно под пентагон?
порт #FF? времянка для мультиколоров?

просто есть вот кай... типа ни рыба ни мясо (не пентагон и не скорп).
может на нём?

Vladimir Kladov

05.04.2006, 19:18

Для вящей убедительности можно вот такой тест выполнить:
LD A,(0000) ; MemPtr=0
BIT 1,(HL) : PUSH AF
DEC HL
BIT 1,(HL) : PUSH AF
LD A,(FFFF) ; MemPtr = FFFF
BIT 1,(HL) : PUSH AF
INC HL
BIT 1,(HL) : PUSH AF

И еще я вот что подумал: а сама команда BIT n,(HL) точно на MemPtr не влияет? (Вдруг она в него HL или HL+1 грузит...) Последний тест доказывает непричастность этой команды, ведь так? (Так ведь в цикле надо проверять флажки, и если бы HL попадало в MemPtr, то флажки все время давали бы одно и то же значение, в таком случае. Вроде бы доказательство, так я понимаю?).

Что-то я какой-то подозрительный становлюсь...

boo_boo

05.04.2006, 20:35

Что-то я какой-то подозрительный становлюсь... DEC/INC и сам BIT (HL) ага, не влияют -- иначе тест бы сглючил. а вообще, можно влепить туда еще инструкций для перестраховки -- предлагаю составить список...

Vladimir Kladov

06.04.2006, 20:25

Список - все команды с rp хоть в каком-нибудь виде:
INC rp:DEC rp
LD r,(HL):LD (HL),r
ADD/ADC/SUB/SBC/AND/OR/XOR/CP A,(HL)
RES n,(HL):SET n,(HL)
... еще что-нибудь?

Их надо бы как минимум для начала проверить тестом, что я предложил: сброс Memptr, затем команда, затем установка MemPtr, затем команда. Это чтобы убедиться, что по крайней мере они не делают ++ или -- для MemPtr. А уже затем можно их для вящей убедительности и в основной цикл теста добавить.

П.С. смайлы отключил, опять ASM Z80 веселится...

boo_boo

06.04.2006, 20:38

Их надо бы как минимум для начала проверить тестом, что я предложил: сброс Memptr, затем команда, затем установка MemPtr, затем команда. Это чтобы убедиться, что по крайней мере они не делают ++ или -- для MemPtr. А уже затем можно их для вящей убедительности и в основной цикл теста добавить. да ну, зачем проверять -- сразу загнать в основной тест, чтоб все под рукой было :)

Vladimir Kladov

06.04.2006, 21:06

да ну, зачем проверять -- сразу загнать в основной тест, чтоб все под рукой было :)
Для убедительности. По крайней мере inc/dec rp. Вдруг они и вправду делают для memptr ++ или --, хотя бы для некоторых регистров. Кстати, INC/DEC INDEX (INDEX=IX/IY) - особо не мешало бы проверить обоими способами.

boo_boo

06.04.2006, 21:23

Для убедительности. По крайней мере inc/dec rp. Вдруг они и вправду делают для memptr ++ или --, хотя бы для некоторых регистров. Кстати, INC/DEC INDEX (INDEX=IX/IY) - особо не мешало бы проверить обоими способами. "второй способ", то есть через CPD, полностью заменяет первый. пусть они хоть что с мемптр-ом делают, мы это увидим. инструкция же исполняется перед циклом декремента CPD, а не в цикле, так что все ок.

boo_boo

07.04.2006, 00:01

вот что интересно, так это "обнуление" мемптр при IM0, о котором упоминал Luca из ramsoft. это бы протестировать, но тогда нужен девайс, который по INT выставляет что-либо безобидное для мемптр на шину, к примеру 0. но кто ж полезет с паяльником в свой спек ради такой фигни... или может, уже есть в природе подобные штуки?

хм... если я правильно понимаю, достаточно перекинуть D0 на землю -- и будет на шине CP вместо RST. может, сделает кто? или отдайте мне кто-нибудь на растерзание старый ненужный спек :rolleyes:

Vladimir Kladov

07.04.2006, 14:29

boo_boo

07.04.2006, 14:50

я бы дал, да далеко до Москвы (мне на прошлой неделе еще 2 принесли, не знают куда девать). Я так понял, случай IM0 нас могут интересовать только для FF на шине, иначе это уже не спектрум и даже не клон. просто хочется разобраться до конца с этим мемптром :) ...клон, или девайс к спеку, юзающий IM0, очень даже может существовать (возможность по прерыванию выполнить любую инструкцию чисто на уровне железа ИМХО не самая бесполезная), но я о таком не слыхал...