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 однако это ему совершенно не мешает запускать весь имеющийся софт без глюков.
ловко ты процессорные тесты выписал из софта :D а еще как минимум одна игрушка (https://spectrumcomputing.co.uk/entry/31198/) проглючить может :p

[ZEman]

cafedead, в большинстве случаев ???
назовите мне хоть какие-нибудь игры (198х - 199х годов) которые это используют.
кроме теста который вы сами написали.

[cafedead]

cafedead, в большинстве случаев ???
назовите мне хоть какие-нибудь игры (198х - 199х годов) которые это используют.
кроме теста который вы сами написали.
Да, именно в большинстве случаев, когда мы не знаем точное количество всех случаев. Я не знаю, потому что я не играл в такое количество игр, чтобы назвать вам хоть какие-нибудь игры, которые это используют. У меня было только то, что было на моих кассетах, как и у всех, я думаю. Более того, я понятия не имею, что там даже в этих играх было внутри. Думаю, вы тоже не читали все с точностью до команды, не так ли, чтобы утверждать, что там точно ничего такого никогда не было? Не нужно мне задавать подобные вопросы. Они странные. Есть вот конкретные открытые недокументированные особенности, и задача автора эмулятора их релизовать, вне зависимости от того, кто какие регистры/команды/особенности использует, или не использует. А то, что вы говорите - это не более, чем ваши домыслы, на основании которых вы оправдываете какое-то бездействие, или низкое качество программного продукта. Это странная позиция. Я такое не поддерживаю, и не вполне понимаю.

Вот я, к примеру, вообще не пользуюсь командами SET, RES, да и BIT, если бы она не возвращала мне MEMPTR во флагах (это единственное место в программе, где я использую данную команду), потому что не вижу в них никакого смысла и удобства. Допустим, я буду не один такой, и мы все не будем использовать эти команды. И авторы ПЗУ Спектрума не будут использовать эти команды. Вот, по вашей логике, значит можно было бы забить на эмуляцию этих команд. Ибо зачем они нужны, если их никто не использует?! Так, что ли? Ну отлично. Но тогда это будет не эмулятор процессора Z80, а что-то другое - детская поделка низкого качества. Вот вы "за" программные продукты такого качества? Или "против"? Лично меня такое качество не устраивает, потому что я не хочу условно нажать куда-то, куда никто не нажимал, и получить кирпич. Это вообще-то фундаментальный вопрос качества разработки ПО, не ограничивающийся разработкой конкретно эмуляторов, недокументированными командами, или регистрами. Фундамент. А вы оправдываете недоделанность программных продуктов какими-то своими домыслами.

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

[ZEman]

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

[ZXMAK]

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

[Lethargeek]

как уже сказали все игры и программы работают и ошибок не наблюдается
:v2_dizzy_facepalm:

- - - Добавлено - - -


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

[cafedead]

как уже сказали все игры и программы работают и ошибок не наблюдается.
Кто сказали? Опять очередной Вася на заборе написал? Где проведенная статистика? Приносите справку с подписями и печатями. Остальное не принимается. Поэтому да, ваши домыслы.

про то где это используется вы тоже ничего не знаете.
И не обязан знать. Потому что, как я разъяснил, это не относится совершенно к вопросу качества программного обеспечения. А реализация регистра, уши которого торчат - относится к вопросу качества ПО. Если бы его уши не торчали, можно было бы забить. Но они торчат, увы. И не я в этом виноват.

проще говоря вы пытаетесь протолкнуть бесполезное изменение.
Прежде всего, я ничего никуда не пытаюсь протолкнуть. Мне, честно говоря, дела нет до чьих-то там изменений. Наоборот. Не надо ничего изменять, я не против. Тогда я просто сделаю свой эмулятор, который будет объективно лучше тех, что представлены. И все на этом закончится. Кто от этого выиграет? В чем я больше заинтересован? Ну вы какие-то странные вещи пишете. Абсурдные.

Любой автор ПО может писать максимально убогий по качеству софт. Это его дело, его зона ответственности. На здоровье. Надеюсь только, что мне не придется пользоваться этими поделками. Но он может поступать и наоборот, стремиться делать качественные продукты. Если кто-то хочет сделать качественный эмулятор Спектрума, или любого другого компьютера на базе процессора Z80, а многие, если вообще не все авторы эмуляторов - это крайне дотошные до мелочей ребятки, и других я еще не видел, вот я ему для этого предоставляю инструмент. Вот на данный момент какие-то эмуляторы заваливают тесты вовсе не потому, что их авторы вас почитали, и поняли, что им не нужно это все делать, т.к. что-то там бессмысленное или бесполезное с ваших слов... А потому что у них не было нормального инструмента для тестирования, который подсветил бы им их недоработки, допущенные по невнимательности в каких-то мелочах, ибо регистр-то они реализовали. Вот я сделал такой инструмент, чтобы можно было выявить недостатки, и их исправить. Хотите - исправляйте, не хотите - не исправляйте. К слову, это было не так уж просто сделать, довольно интересная задачка с ограничениями, и это было ну просто ДОХЕРА работы. Потом на этой основе можно будет сделать полноценные тесты вообще всего, и это будет еще более чем ДОХЕРА работы. Делая тесты, подходя к своей работе ответственно, я не могу сказать, что ну вот эту команду или регистр я буду проверять, а вот эту - не буду, потому что нет смысла. Не могу себе позволить рассуждать вот как вы. Потому что вот таковы мои критерии качества. У вас они, очевидно, иные.

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

[goodboy]

"Один юноша пошёл учиться убивать драконов. Десять лет он учился убивать драконов и стал настоящим мастером своего дела.
Взял меч и пошёл в лес, но не встретил ни одного дракона. Он пошёл к своему учителю и задал вопрос:
— Ты научил меня убивать драконов, но теперь я не могу найти ни одного дракона. Что же мне теперь делать?
— Учи других убивать драконов. "

[cafedead]

"Один юноша пошёл учиться убивать драконов. Десять лет он учился убивать драконов и стал настоящим мастером своего дела.
Взял меч и пошёл в лес, но не встретил ни одного дракона. Он пошёл к своему учителю и задал вопрос:
— Ты научил меня убивать драконов, но теперь я не могу найти ни одного дракона. Что же мне теперь делать?
— Учи других убивать драконов. "
Эм... В детстве, в 13-летнем возрасте, я захотел уметь программировать на ассемблере на своем Спектруме, как тогдашние деды программировали. Ну я научился программировать и на ассемблере Z80, и на ассемблерах других процессоров, и еще много на каких языках, и научился делать это качественно. Теперь я могу применить свои компетенции в написании, например, тестов, чтобы помочь авторам эмуляторов отладить свои продукты. И это на достаточно отсталом ассемблере 8-битного процессора Z80 с завязанными руками из-за ограничений, связанных с порчей MEMPTR. В смысле, я не считаю, что за свои 30 уже лет научился чему-то бесполезному, вроде борьбы с мифическими несуществующими существами, или ветряными мельницами, как вы ранее написали. И если эти заработанные компетенции не очень востребованы в современном мире, то это скорее повод расстраиваться. Это ведь трагедия. Вы так не считаете? Вас это все веселит? В чем вы видите тут повод для шутки? Объясните, и мы вместе тут посмеемся. Ничего не имею против хорошей и уместной шутки.

На кой черт вы это все пишете? Вам что за дело? У вас какой-то личный интерес в том, чтобы кто-то не поддерживал MEMPTR в своем эмуляторе? Или в чем проблема? Объясните. Я не понимаю.

[Black Cat / Era CG]

Напишите хорошую игру!

[ZXMAK]

И если эти заработанные компетенции не очень востребованы в современном мире, то это скорее повод расстраиваться. Это ведь трагедия. Вы так не считаете? Вас это все веселит?

Как говорил Цицерон:
Nemo potest non beatissimus esse, qui est totus aptus ex sese, quique in se uno ponit omnia.
Самым счастливым может быть лишь тот, кто всецело зависит от себя и кто все полагает в себе одном.

Грубо говоря, жажда чужого одобрения и востребованности - это форма рабства. :)

Когда ты живёшь ради востребованности, ты в аду, где другие управляют твоим смыслом. Востребованность - это клеймо, не признание. Его ставят, пока ты свежий. Потом - в утиль. Ты думаешь, что тебя любят, пока тебя зовут. Но зовут не тебя - зовут функцию. Люди не видят человека, они видят инструмент, решение своей задачи. И как только нужда исчезает, исчезаешь и ты.

[Dexus]

Ну реально там какие-то костыльные решения, которые никуда не годятся.
Годятся. Эти костыли пилятся под тот набор уже существующих игр с даже нестандартными загрузчиками. Под крючкотворство новоделов (всяких извергских тестов) расчитывать нет смысла. Кто не хочет загрузиться под эмулем - тот не будет. Прошли те времена, когда нужно было эмулятор подстраивать под софт. Точнее, оно всегда было так, что подстраивать нужно только под классический софт, с какой-то датой отсечения. То что хацкеры ненавистники эмулей наг0внокодили позже - вообще плевать.

[SAM style]

На кой черт вы это все пишете?
Вот и у меня тот же вопрос. Надо бы кастануть модера, чтобы всю эту воду в отдельную тему унёс

[^m00h^]

Попробовали ещё один заход со сборкой xpeccy в haiku OS:

Gerasim Troeglazov:
собрал свежий, с Qt6 - проблема с клавиатурой осталась - хз где глюк, надо разбираться.
Если сделать однократное нажатие то норм - но если зажать и подержать, то клавиша залипает.

может вообще косяк в QPA у меня, надо ковырять - event отпускания клавиши где-то ТЕРЯЕТСЯ.

- - - Добавлено - - -

82275

[SAM style]

Если сделать однократное нажатие то норм - но если зажать и подержать, то клавиша залипает.
При задержании кнопки Qt помечает все повторные нажатия как автоповтор (isAutoRepeat). При этом последовательность в разных осях разная - в линуксе как нажал-(отжал)-(нажал)-(отжал)-(нажал)-...-отжал, но в макоси как нажал-(нажал)-(нажал)-(нажал)-...-отжал, в скобках автоповторные. Возможно, в хайке последний отжал тоже помечается как повторный, поэтому скипается эмулятором. Надо бы протестить - в начале EmulWin::keyPressEvent и keyReleaseEvent выводить, что за кнопка и не автоповтор ли. Тогда станет яснее.

[mastermind]

И если эти заработанные компетенции не очень востребованы в современном мире, то это скорее повод расстраиваться. Это ведь трагедия. Вы так не считаете? Вас это все веселит? В чем вы видите тут повод для шутки?
Рекомендую вам "Certainty by Construction" by Sandy Maguire, компетенции ваши востребованы, и, возможно, сфер где они востребованы гораздо больше чем вы думаете ;) https://leanpub.com/certainty-by-construction

[cafedead]

У меня была такая информация только в случае прерывания. Про обрывание блочных команд самозатиранием информации не было... Где почитать?
Вот тут (https://github.com/hoglet67/Z80Decoder/blob/master/src/em_z80.c) нашел, что почитать. Можете поглядеть, как автор того треда, где вы собственно и взяли инфу об этих блочных командах, реализовал это в своем эмуляторе. Вот со строки 2225 обработка блочных команд у него. Как видите, он прописал это все с флагами прямо в обработку опкодов блочных команд, а не в обработку прерывания. Т.е. под словом "прерывать" работу блочной команды он не имел в виду немаскируемое/маскируемое прерывание.

[ZXMAK]

Т.е. под словом "прерывать" работу блочной команды он не имел в виду немаскируемое/маскируемое прерывание.

так блочные инструкции нельзя прерыванием прервать.

[cafedead]

так блочные инструкции нельзя прерыванием прервать.
С чего бы? Блочную инструкцию можно прервать прерыванием. Под прерыванием блочной инструкции в данном контексте подразумевается преждевременное завершение ее повторяемости до достижения BC=0 для LDIR/LDDR/CPIR/CPDR и B=0 для INIR/INDR/OTIR/OTDR. Не путайте с невозможностью прерывания между префиксом #ED и опкодом блочной инструкции. Прерывания ведь могут быть пойманы на каждой итерации, и делай там, что хочешь. Вот так они и проводили свои изыскания, прерывая блочные инструкции маскируемым прерыванием, потом глядели на флаги и на MEMPTR в режиме IM 0, посылая в качестве опкода JP (HL).

[ZXMAK]

а, вы в этом плане, так для процессора это по сути две отдельные инструкции, хоть и расположены по одному адресу