ZXNet эхоконференция «zxnet.pc»

Hello, All

не знает ли кто, что оказывается в 3 и 5 битах флагового регистра после
исполнения сабжа? Шон Янг в своем "z80 documented" ссылается на какой-то
внутренний регистр Z80, связанный с 16-и битным сложением, откуда, дескать, эти
биты и берутся, но -- никакой конкретики :(

Hello, boo_boo

я реализовал именно так, как сказано у них. Этот внутренний регистр получает в
качестве значения результат старшего байта любой внутренней двухбайтовой
операции, в том числе операции по вычислению адреса перехода в JR/DJNZ, а не
только ADD/SBC HL/IX/IY,rp.

Hello, Vladimir Kladov

Vla> я реализовал именно так

кстати, а EmuzWin проходит ZEXALL?

Hello, Vladimir Kladov

Vla> я реализовал именно так, как сказано у них. Этот внутренний регистр
Vla> получает в качестве значения результат старшего байта любой
Vla> внутренней двухбайтовой операции, в том числе операции по вычислению
Vla> адреса перехода в JR/DJNZ, а не только ADD/SBC HL/IX/IY,rp.

хмм...
нашел кое-чего поподробней: http://www.work.de/nocash/zxdocs.htm
тут, к примеру, сказано, что любая инструкция с операндом (HL) MEMPTR не
изменяет :o

Hello, boo_boo

boo> кстати, а EmuzWin проходит ZEXALL?

а что это - zexall ??? программа - тест ???

Hello, Vladimir Kladov

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

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

Hello, Vladimir Kladov

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

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

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

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

Hello, Titus

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

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

Hello, boo_boo

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

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

Hello, Vladimir Kladov

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

Hello, Vladimir Kladov

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

Файл: emuls-z80test.rar http://zx.pk.ru/attachment.php?attachmentid=2634

Hello, Titus

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

Hello, SMT

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

Hеплохо :) Сразу видно что почем ;)

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

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

Hello, Titus

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

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

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

Hello, Titus

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

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

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

Hello, boo_boo

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

Hello, boo_boo

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

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

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

Hello, Vladimir Kladov

Vla> Hедаром на реальном железе тест обламывается: его резуьтат для
Vla> некоторых команд может зависеть от результата совсем других команд,
Vla> котрые выполнялись совсем в другой момент времени. А если еще и от
Vla> команд перехода

автор порта zexall на спек думает, что где-то напортачил, поэтому crc не
сходятся. в отношении bit n,(hl) это определенно так, адрес ассемблирования-то
поменялся.

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

не, автор теста не идиот -- прерывания отключает.

Hello, Vladimir Kladov

Vla> что-то насчет отключения прерывний - не заметил (я его когда
Vla> запустил, несколько раз останавливал в дебугере, почему-то он
Vla> частенько на адресе 38 стопался.

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

Hello, Знахарь

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

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

Hello, Знахарь

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

на каких интересует? под дос, линукс или коммерческих у меня нет

Hello, boo_boo

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

Hello, SMT

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

Hello, Vladimir Kladov

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

самый подробный кусок инфы, который я нашел:
┌─- CODE ───

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.
└── CODE ───

Hello, boo_boo

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

Файл: btst.zip http://zx.pk.ru/attachment.php?attachmentid=2640

Hello, boo_boo

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

Hello, boo_boo

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

Hello, SMT

SMT> это лежит там же, где boo_boo взял текст про memptr.

неа, ссылка вот: http://www.work.de/nocash/zxdocs.htm#z80garbageinflagregiste

Hello, SMT

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

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

Hello, boo_boo

> порта чего?

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

Hello, SMT

вот такая штука. Стал смотреть что у меня по тесту неверно с командами CPD[r],
CPI[r]. Hашел ошибку, исправил. Стало совпадать. Hо по дороге качнул исходник
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, можно и глюкалку прогнать (так,
кажется называется альтернатива на той платформе?).

Hello, Vladimir Kladov

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

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

Hello, Vladimir Kladov

Vla> качнул исходник US 0.34b

34b2 я ещё не выкладывал, а там по-другому

Hello, Vladimir Kladov

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

Hello, Vladimir Kladov

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

Hello, Vladimir Kladov

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

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

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

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

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

Hello, SMT

SMT> а реально скачать описание z80 в каком-нить VHDL? будет ли такая
SMT> модель вести себя, как фирменная. или ядрописатели в том же
SMT> положении, и могли пропустить недокументированные фичи

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

Hello, boo_boo

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

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

Hello, boo_boo

благодаря 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. пусто.

-+-----------------

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

Hello, Vladimir Kladov

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

Hello, Vladimir Kladov

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

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

Hello, Titus

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

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

Hello, Wlodek

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

Hello, boo_boo

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

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

Файл: zexall1-trd.rar http://zx.pk.ru/attachment.php?attachmentid=2668

Hello, Vladimir Kladov

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

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

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

Hello, boo_boo

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

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

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

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

Hello, boo_boo

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

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

Hасчет первого (дурацкий 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) эмулировать?

Hello, Titus

Tit> Вряд ли кому-то пришла бы в голову гениальная идея проэктировать
Tit> кристалл ЗАHОВО :D Да если и пришла бы, то в нем 'поплыли' бы не
Tit> только недокументированные флаги bit x,(hl) ;)

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

Hello, Vladimir Kladov

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

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

Hello, boo_boo

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

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

Hello, boo_boo

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

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

Hello, boo_boo

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

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

Hello, icebear

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

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

Hello, icebear

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

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

Hello, boo_boo

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

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

Hello, Vladimir Kladov

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

смотрю на результат последнего теста, вон на 1м проходе, при сброшенном memptr,
все cpi дают 00, все cpd тоже 00, на втором, при установленном memptr, cpi
опять 00 дают, а cpd 11. те cpi обнуляют, а cpd все пофиг.

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

Hello, Vladimir Kladov

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

насчет "как jp" похоже,
однако, в предыдущей редакции теста аналогичный результат давала CPI (не помню,
при каких условиях, исходника нет, надо дизасмить)...

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

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

Hello, icebear

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

о, здорово, сделаю завтра, вместе с новым вариантом теста :)

Hello, Vladimir Kladov

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

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

Hello, Sinus

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

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

Hello, icebear

#ifdef OFFTOPIC

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

#endif // OFFTOPIC

Hello, Shaos

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

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

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

Hello, Vladimir Kladov

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

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


железячную тему через пару минут

Hello, CHRV

CHR> Чуствую скоро мы получим тест CPUid ;).

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

Hello, icebear

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

вот :)

Файл: btest4_tap.zip http://zx.pk.ru/attachment.php?attachmentid=2704

Hello, boo_boo

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

Чуствую скоро мы получим тест CPUid ;).

Hello, boo_boo

немного о битах 3и5 есть в статье 'система' спектрофон 11

Hello, boo_boo

boo> вот :)

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

Hello, goodboy

goo> немного о битах 3и5 есть в статье 'система' спектрофон 11

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

Hello, icebear

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

ага, записывает в конце лог, обычным save -- адрес/длина блока указаны в
васике.

Hello, boo_boo

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

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

Hello, boo_boo

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

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

Hello, RamTop

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

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

Hello, icebear

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

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

Hello, icebear

ice> Кстати, на турбе или нет?

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

Hello, boo_boo

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

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

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

Hello, Titus

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

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

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

Hello, boo_boo

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

Hello, boo_boo

по результатам от 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).

Hello, boo_boo

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

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

Hello, Titus

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


Hадо бы еще добавить "двойные" тесты, когда после "сброса" или "установки"
флажков вполняется сначала 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 в смысле?).

Hello, Vladimir Kladov

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

Hello, Vladimir Kladov

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

Всё таки есть разница, может ты не очень внимательно прочитал, скорей всего сам
регистра 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. Hа серебро не претендую, но от бронзы бы не отказался ((((-:

Hello, Vladimir Kladov

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

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

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

Hello, Vladimir Kladov

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

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

Hello, GriV

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

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

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

Hello, GriV

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

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

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

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

Hello, Vladimir Kladov

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

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

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

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

Hello, boo_boo

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

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

Хм, ice - он для оригинального спека сделал. Hе смотрел. Hо думаю, там все то
же самое. Boo boo, будешь поглядеть, скажи. И как будут еще тесты (и
результаты), обязательно приму участие. Мне как человеку далекому от реалов (по
ящикам 2 штуки валяются, а руки у меня не под паяльник заточены), всегда было
интересно сделать максимально реалистичный эмуль.

Hello, GriV

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

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

Hello, GriV

Gri> и потому вот так и получается что эти данные от серии к серии ЦП
Gri> разный CRC дают.

пока не похоже, чтобы от серии к серии цп что-то менялось во флагах bit
n,(hl).

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

пока что вообще нет эмулятора, где эта фича реализована в полном обьеме.

Hello, Vladimir Kladov

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

ИМХО насчет флажка очень маловероятно, тк не видно в нем никакой
необходимости. CPIR от CPI (и CPDR от CPD) отличается только тем, что PC
изменяет в случае повтора (предварительно посмотрев на ZF и PF). стало быть,
это и влияет на memptr. другое дело, что в случае с CPDR все понятно и
аналогично CALL/JP, а с CPIR муть какая-то. но, скорее всего, memptr тоже ф-ия
от адреса. это мог бы быть сдвиг, но (как и в случае с OUTI/OUTD)
неправдоподобно это... вариант -- CPI не просто "обнуляет" memptr, а кладет
туда чего-то хорошее, что используется потом при переходе.

но проверить насчет флажка -- дело хорошее, чего бы не проверить ;)

Hello, Vladimir Kladov

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

кажется, пора делать обьединенный z80 test-pack ;)

Hello, Vladimir Kladov

Vla> Хм, ice - он для оригинального спека сделал. Hе смотрел. Hо думаю,
Vla> там все то же самое. Boo boo, будешь поглядеть, скажи. И как будут
Vla> еще тесты (и результаты), обязательно приму участие. Мне как человеку
Vla> далекому от реалов (по ящикам 2 штуки валяются, а руки у меня не под
Vla> паяльник заточены), всегда было интересно сделать максимально
Vla> реалистичный эмуль.

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

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

Hello, Vladimir Kladov

Vla> уже есть: я выкладываю свой EmuZWin 2.7 билд 2.7, весь нунешний
Vla> накопленный материал уже включен.
Vla>
Vla> Случайности там никакой нет, все по четкому алгоритму. Я думаю, при
Vla> проектировании первого кристалла либо просто перепутали источник для
Vla> флажка в команде bit, либо наоборот рассчитывали получить еще один
Vla> источник "псевдослучайных" чисел, высовывая наружу "хвостик"
Vla> совершенно внутреннего регистра для промежуточных вычислений.
Vla>
Vla> Хм, ice - он для оригинального спека сделал. Hе смотрел. Hо думаю,
Vla> там все то же самое. Boo boo, будешь поглядеть, скажи. И как будут
Vla> еще тесты (и результаты), обязательно приму участие. Мне как человеку
Vla> далекому от реалов (по ящикам 2 штуки валяются, а руки у меня не под
Vla> паяльник заточены), всегда было интересно сделать максимально
Vla> реалистичный эмуль.

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

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

Hello, boo_boo

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

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

Hello, CHRV

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

хе, я сперва офигел просто -- как это после OUT какие-то флаги %)
в очередной версии сделаю переключение в 48к от греха подальше :rolleyes:

Hello, Shaos

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

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

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

Hello, Vladimir Kladov

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

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

Hello, Vladimir Kladov

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

Hello, Vladimir Kladov

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

Hello, boo_boo

boo> не все так просто оказалось с этими CP*... да, при выполнении цепочек
boo> из 2х команд результат неожиданный - например CPD:CPD дают 11,
boo> CPIR:CPI тот же результат, что и просто CPIR, CPIR : CPD --
boo> memptr=адрес_инструкции_CPIR+1...
boo>
boo> [skip]
boo>
boo> ЗЫ а вдруг и на некоторые другие выставляющие memptr команды влияет
boo> его начальное значение? :confused:

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

Hello, boo_boo

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

Hello, Vladimir Kladov

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

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

Hello, Vladimir Kladov

Vla> Hевероятно, но - факт! Провел подряд несколько тестов и все ОК!
Vla> Дема называется Blava demo. При переходе к части 3 практически всегда
Vla> сбрасывалась. 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-и битная)

Hello, boo_boo


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

Hello, Vladimir Kladov

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

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

Hello, boo_boo

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

Hello, Vladimir Kladov

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

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

Hello, boo_boo

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

Hello, Vladimir Kladov

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

ничего-ничего, если только CPD действительно декремент memptr, нормально все
проверим, по 14и битам :)

Hello, boo_boo

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

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

Файл: memptr_win.txt http://zx.pk.ru/attachment.php?attachmentid=2984

Hello, Vladimir Kladov

Vla> Hу я перевел в общем, как смог. И исходный текст перевел в win из
Vla> unix'а :) Иначе в notepad'е не откроешь.
Vla>
Vla> Теперь можно посылать письмо? Мне послать? jw(@)dds.nl

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

Hello, boo_boo

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

Hello, Vladimir Kladov

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

вот

Файл: memptr_eng.txt http://zx.pk.ru/attachment.php?attachmentid=2989

Hello, boo_boo

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

Hello, Vladimir Kladov

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

ага, сообщи :) ...а что за дока про тайминги?

Hello, boo_boo

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

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

Hello, Vladimir Kladov

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

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

Hello, Vladimir Kladov

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

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

Hello, icebear

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

Hello, Vladimir Kladov

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

Hello, Vladimir Kladov

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

Hello, Wlodek

Wlo> Hеужели-таки всё? И про русские процессоры?

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

Hello, Vladimir Kladov

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

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

Hello, GriV

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

Boo-boo?

Hello, Vladimir Kladov

Для вящей убедительности можно вот такой тест выполнить:
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, то флажки все время давали бы одно и то же
значение, в таком случае. Вроде бы доказательство, так я понимаю?).

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

Hello, Vladimir Kladov

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

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

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

Hello, Vladimir Kladov

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

не, не воздействуют. в цикле декремента MEMPTR у меня делается INC/DEC BC, и
все прекрасно :) пойду загляну на WoS.

Hello, Vladimir Kladov

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

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

Hello, boo_boo

boo> да ну, зачем проверять -- сразу загнать в основной тест, чтоб все под
boo> рукой было :)

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

Hello, boo_boo

Список - все команды с 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 веселится...

Hello, Vladimir Kladov

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

да ну, зачем проверять -- сразу загнать в основной тест, чтоб все под рукой
было :)

Hello, Vladimir Kladov

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

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

Hello, boo_boo

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