я реализовал именно так, как сказано у них. Этот внутренний регистр получает в качестве значения результат старшего байта любой внутренней двухбайтовой операции, в том числе операции по вычислению адреса перехода в JR/DJNZ, а не только ADD/SBC HL/IX/IY,rp.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
хмм...Сообщение от Vladimir Kladov
нашел кое-чего поподробней: http://www.work.de/nocash/zxdocs.htm
тут, к примеру, сказано, что любая инструкция с операндом (HL) MEMPTR не изменяет
кстати, а EmuzWin проходит ZEXALL?
Нет, не проходит, и слава всевышнему. Ни один эмулятор и ни одно реальное железо его не проходит. Хотите самый надежный тест? Включайте поддержку RZX-файлов, качайте готовые RZX-записи, делайте свои RZX-записи в других эмуляторах и гоняйте до опупения. Вот когда будут работать 99% таких записей (которые идут по крайней мере еще на 2х эмуляторах - есть записи "неправильные", которые идут только на том эмуляторе, на котором и были записаны), вот тогда можете смело считать, что у вас все в порядке и делается практически 100% точно для целей эмуляции.
Полностью добиться 100%-ной точности реально, если есть под рукой железо, но неинтересно, кроме спортивных целей. Вот есть такая фишка, ULA называется. Чтобы учесть задержки и не сильно затормозить, большинство эмуляторов работают по таблицам, и берут во внимание только то, в каком банке начинается команда. А если 4-х байтная команда к примеру начинается в медленном банке, а продолжается в быстром банке ОЗУ, то такты посчитаются неправильно. Это касается и спектаклятора, и рил спека (у себя-то я правильно сделал, но чтобы это показать, надо специально демку городить мультиколорную, а мне влом).
ну я не по буковкам ОК смотрю, а по результатам: сравниваю свои с теми, которые на реале выходят... все совпадает, а bit этот нет.. ладно, фиг бы с ним -- по ходу извращений "добился" один раз того, что ПЗУ глючило, а тест нормально все показывал.. хе-хе
Отлично, 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) эмулировать?
(btw, boo_boo читается бу-бу) думаю, но данных не хватает
особенно мутно с прерываниями и ld(nnnn),a у которого результаты разошлись на разных компах. сейчас дописываю тест поподробней/пообъемней, по результатам бут видно
думай. Но учти, что в большом тесте, кторый у 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, вот смеху-то было бы).
Вот точно какие команды выполняются в биг-тесте:
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,().
По мне - эмулятор не является полноценным эмулятором, если он не эмулит комп на 100%
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
