команда BIT n,(HL)

[Wlodek]

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

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

[Vladimir Kladov]

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

[Titus]

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

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

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

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

[boo_boo]

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

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

[Titus]

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

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

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

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

[Vladimir Kladov]

Отлично, 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) эмулировать?

[Advertiser]

[boo_boo]

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

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

[Vladimir Kladov]

думай. Но учти, что в большом тесте, кторый у 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]

Вот точно какие команды выполняются в биг-тесте:
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]

Вот точно какие команды выполняются в биг-тесте

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