Xpeccy

[cafedead]

Но они не соответствуют pc или hl - это просто значение защелке установленное на одном из полуциклов.

Мы не знаем, что там чему соответствует, или не соответствует. PC что, всегда инкрементируется? Ну вы не отвечаете на вопросы. Я прекрасно понимаю, что такое ab и db в вашей таблице. Пояснения нужны были, когда вы мне показывали PC=#0004 при выборке #ED, когда инструкция находилась по адресу #0003. Вот там уместно было бы пояснить, а не писать, что мне там что-то наглядно видно должно быть. А сейчас про ab db мне уже не надо, благодарю.

[ZXMAK]

Вы уверены, что во время вычитывания опкода по адресу #0004 в PC #0005? Откуда эта уверенность?

ну как-бы потому, что значение pc прочитано непосредственно напрямую из внутреннего регистра Z80, в котором хранится значение pc.

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

валяйте - проверяйте, схема отреверсена, в теме Titus выкладывалсь. Там-же и обсуждалось где что лежит. Проверяется просто - запускаем на симуляторе тестовый код и сравниваем результаты с реальным процессором, если реверсе соединений транзисторов не накосячили, то все будет совпадать. Собственно так отреверсеный нетлист и проверяли. Неоднократно проверено и все работает.

Не пойму только о чем вы спорите? Вы не верите что нетлист восстановлен и работает?

[cafedead]

Проверяется просто - запускаем на симуляторе тестовый код и сравниваем результаты с реальным процессором,

И какой же тестовый код нужно написать, чтобы выяснить, что при выполнении LDIR, когда BC!=1 на последних машинных циклах у нас будет PC=#0005 как у вас в табличке, и что у нас именно два декремента? У нас об этом вроде как разговор. Ну т.е. никакой, а вы предлагаете полную нереалистичную глупость, не связанную с обсуждением. И это от автора эмулятора. Еще кто-то про троллинг мне имеет наглость написать. Забавно.

то все будет совпадать.

Что будет совпадать? #0005 в PC на каком-либо этапе зацикленного LDIR? Ну не доказуемо предложенным вами способом. Т.е. #0005 - это просто нарисованная циферка у вас в табличке, не более того.

Собственно так отреверсеный нетлист и проверяли. Неоднократно проверено и все работает.

Ну если так и проверяли, то про #0005 в PC, из которого вычитается двойка пока-что не убедили, уж извините.

Не пойму только о чем вы спорите? Вы не верите что нетлист восстановлен и работает?

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

[krt17]

Талант, про инопланетян на тв3 с такими бы умениями.

[ZXMAK]

И какой же тестовый код нужно написать, чтобы выяснить, что при выполнении LDIR, когда BC!=1 на последних машинных циклах у нас будет #0005 как у вас в табличке? У нас об этом вроде как разговор. Ну т.е. никакой

Симулятор был проверен на множестве тестов, включая те, которые традиционно применяются для верификации точности эмуляторов Z80 (например, zexall, zexdoc и другие). Однако здесь важно понимать ключевое различие между эмулятором и схемным симулятором.

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

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

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

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

Например, адресная шина AB получает значение не напрямую из регистра PC, а из промежуточной защёлки. При этом PC может инкрементироваться сразу после передачи значения в защёлку, так что в момент чтения из памяти на шине будет старое значение, соответствующее адресу текущей инструкции, тогда как сам регистр PC уже содержит адрес следующей. Это вполне типичное поведение для микропроцессоров, реализованных на логическом уровне, особенно в архитектурах, где производительность достигается через конвейерную архитектуру.

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

[goodboy]

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

[cafedead]

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

Ну, справедливости ради, не половину, а... ну из моих 8 из 97. Ну разные тесты можно объединять, разъединять, из-за чего цифры будут меняться. Но в целом, все не так уж страшно. Не исправлять недочеты тоже не вижу никакого смысла, там работы на один вечер. Максимум - два вечера. Просто из вредности, что ли?!

В плане качества написания кода мне анрил тоже больше всех пока-что нравится. Это несмотря на то, что анрил заваливает какие-то тесты, а Xpeccy, или тот же SpecEmu, например, все чистенько проходят.

Меня больше озаботило, как в эмуляторах реализуется авто старт/стоп ленты при кастомных загрузчиках. Это вообще жесть какая-то. Кто во что горазд. Заменил IN A,(#FE) на IN A,(C), и сразу какие-то эмуляторы начали тупить, выключают ленту, заменил #7F в старшем байте порта на #FF, потому что не нужен опрос пробела, логично вроде бы - другие начали тупить, убрал кусок ненужного кода из загрузчика, связанного с нажатием пробела, и в принципе подсократил, ускорив код - третьи начали тупить, выключают проигрывание. Ну реально там какие-то костыльные решения, которые никуда не годятся. Не косячит в этом пока-что как раз анрил, да. Ну я не смог его поймать на таком, по-крайней мере. Тут на эту тему была ветка, как этот функционал стоит реализовывать. Интересные идеи предлагались.

[ZEman]

cafedead, я всё понимаю, но для чего это ?
все игры и софт и так работают без ошибок.

[cafedead]

cafedead, я всё понимаю, но для чего это ?
все игры и софт и так работают без ошибок.

Что именно? Корректно эмулировать регистр MEMPTR? Ну чтобы исключить вероятность падения, или уменьшить ее. Задача любого эмулятора - максимально хорошо изобразить работу процессора. Мы ведь не знаем заранее, что нам подсунет автор кода. А ваш вопрос из разряда, зачем делать качественный продукт, если вот некачественный тоже что-то выполняет, может быть даже все, но это не точно. Странная довольно постановка вопроса. А для чего этого не делать? Тем более, если уже там все у всех почти сделано?! Чисто косметические недоработки. Когда просто ну забыли в обработку каких-то инструкций вставить нужный код. По невнимательности. Потому что нет нормальных тестов.

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

[Lethargeek]

тот-же Unreal проваливает половину тестов memptr однако это ему совершенно не мешает запускать весь имеющийся софт без глюков.

ловко ты процессорные тесты выписал из софта а еще как минимум одна игрушка проглючить может