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

[Vladimir Kladov]

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

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

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

[Advertiser]

[boo_boo]

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

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

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

[boo_boo]

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

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

[GriV]

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

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

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

[boo_boo]

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

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

[Vladimir Kladov]

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

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

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

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

[GriV]

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

Всё таки есть разница, может ты не очень внимательно прочитал, скорей всего сам регистра 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]

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

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

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

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

[Vladimir Kladov]

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

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

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

[boo_boo]

уже есть: я выкладываю свой 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] для подтверждения/опровержения этого дела?