Реверс-инжиниринг Z80

[zebest]

про "специальный RESET" лет 10 как известно, даже в эмуле есть. В специальном.
Вот кратенько по годам, что-когда раскопали:

* 2006 - [MEMPTR](https://zxpress.ru/zxnet/zxnet.pc/5909)
* 2012 - [Q: Zilog](https://worldofspectrum.org/forums/discussion/41704)
* 2014 - [Special Reset](https://github.com/redcode/Z80/wiki/Z80-Special-Reset)
* 2018 - [Additional flag changes of the block instructions](https://github.com/hoglet67/Z80Decod...cumented-Flags)
* 2018 - [Q: NEC / ST](https://github.com/hoglet67/Z80Decod...cumented-Flags)
* 2021 - [`reti` and `retn` reject INT when IFF1 != IFF2](https://floooh.github.io/2021/12/17/...n-instructions)
* 2022 - [MEMPTR during the additionaal flag changes of `otir` and `otdr`](https://github.com/hoglet67/Z80Decoder/issues/2)
* 2022 - [NMI rejection](https://spectrumcomputing.co.uk/foru...pic.php?t=7086)
* 2023 - [MEMPTR during the additional flag changes of all I/O block instructions](https://spectrumcomputing.co.uk/foru...ic.php?t=10555)
* 2024 - [Unstable flag behavior of `ccf` / `scf`](https://github.com/hoglet67/Z80Decod...-SCF-Behaviour)

[Deadly]

Если в ноере такта присутствует точка (T1.1 или T1.2), это означает, что имеется в виду 1-й или 2-й полутакт.
Номер полутакта может быть больше 2 вследствие прохождения сигналом промежуточных триггеров. Например, T1.3 обозначает третий полутакт от начала такта T1. Не смотря на то, что по времени он может совпадать с T2.1, правильнее обозначать его именно T1.3, т.к. он инициирован тактом T1.

В первом цикле любой команды в такте Т1.1 активны сигналы READ_PCR и SEL_PC, по которым регистр PC читается из регистрового файла и записывается в регистр PCR.

В такте T1.2 регистр PCR записывается в регистр адреса REG_ADR, содержимое которого выставляется на шину адреса AB0..15.
В этом же такте инкрементированное значение PCR записывается в регистр PCR2.

По переднему фронту такта T1.3 (T2.1) устанавливаются сигналы MREQ и RD, выдавая внешней схеме запрос чтения памяти.
Также в такте T1.3 (T2.1) происходит запись регистра PCR2 обратно в регистр PC.

По переднему фронту такта T2.2 устанавливается сигнал DP_DL, по которому данные с DB0..7 через шину DLATCH0..7 записываются в регистр REG_DATA.

По переднему фронту такта Т2.3 (Т3.1) устанавливается сигнал LOAD_IR, по которому данные с шины DBUS0.7 записываются в регистр команды REG_COMMAND. При этом в течение такта T2.3 (T3.1) на шине DBUS0..7 удерживается ноль.
Также в этом такте активны сигналы READ_PCR и SEL_IR, по которым регистр IR читается из регистрового файла и записывается в регистр PCR.

По переднему фронту такта Т3.2 снимается сигнал DP_DL, прекращая запись внешних данных в регистр REG_DATA.
В такте Т3.2 на шине DBUS0..7 появляется значение регистра REG_DATA и остается там до следующего такта T2.2.
Так же в этом такте данные с шины DBUS0..7 продолжают записываться в регистр REG_COMMAND.
Фактически фронт T3.2 - это момент защелкивания данных с шины DB0..7 в регистре REG_COMMAND.
Таким образом, с момента выставления сигнала RD и до момента защелкивания данных в REG_COMMAND отводится чуть менее 1.5 тактов.
В этом же такте регистр PCR записывается в регистр адреса REG_ADR, содержимое которого выставляется на шину адреса AB0..15.
В этом же такте инкрементированное значение PCR (инкрементируются младшие 7 бит) записывается в регистр PCR2.
В этом же такте сбрасывается сигнал MREQ.

По переднему фронту такта T3.3 (T4.1) сбрасывается сигнал LOAD_IR, прекращая запись регистра REG_DATA в REG_COMMAND.
В этом же такте происходит запись регистра PCR2 обратно в регистр IR.
В этом же такте устанавливается сигнал MREQ,

По переднему фронту такта T4.3 (T5.1) сбрасывается сигнал MREQ.

Таким образом, длительность цикла чтения - 1.5 такта (и более, если активен WAIT), длительность цикла регенерации памяти - 1 такт.

почему то RFSH не указан

[Titus]

почему то RFSH не указан

Что значит почему? )
На диаграмме указан)

Все, что интересно, можно посмотреть по схеме. Я рисую графики смотря на схему) И вы так сможете, я верю в вас)

[Deadly]

Все, что интересно, можно посмотреть по схеме. Я рисую графики смотря на схему) И вы так сможете, я верю в вас)

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

[Titus]

назвался груздём, ....

Никуда я полезать не собираюсь)

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

не всегда понимаю твою логику, ты выложил диаграмму, мол смотрите, ок принимается.

Я выкладываю фрагменты диаграмм и описаний для привлечения внимания интересующихся лиц.
И для того, чтобы люди могли ознакомиться в ОБЩЕМ, как процессор работает.
А диаграммы работы всех команд я составлять не собираюсь)

[Deadly]

А диаграммы работы всех команд я составлять не собираюсь)

моё почтение...

[Advertiser]

[org]

Основная проблема подобных проектов - это то что автор зачем-то пытается "понять" как оно работает. Это является основным тормозом, в результате чего проект может длиться годами. Так и у нас было.
Но потом оказалось что достаточно получить netlist, а понимать вовсе не обязательно. Ведь полученные результаты рано или поздно захотят практического применения (программный эмулятор / HDL реализация), а если делать точно, то оно и будет работать как исходная схема и то что ты "понял" как оно работает никакой пользы не доставит. Главное понимать как в целом логика работает - основные приёмчики, подходы к реализации (регистры, счётчики, автоматы), а распутывать лапшу комбинаторно-последовательной логики это бессмысленно и беспощадно. Но не могу запретить автору продолжать, читаем с интересом.

[Titus]

Основная проблема подобных проектов - это то что автор зачем-то пытается "понять" как оно работает.

Я люблю понимать суть процессов)
Без точного понимания невозможно с материалом ничего сделать интересного. Только клонировать, да и там можно ошибиться, именно из-за того, что не понимаешь нюансов.
Кроме того, представьте себе программный эмулятор, эмулирующий на уровне вентилей? Это сверхизбыточность.
Также, понимание сути позволяет найти скрытые нюансы, ошибки, неизвестные подводные камни. Это все очень интересно.
Видимо, тут говорит мой дух хакера и оптимизатора)

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

Так и у нас было.

У нас - это у кого, и с каким проектом?

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

в результате чего проект может длиться годами.

Тут могу согласиться)

[org]

У нас - это у кого, и с каким проектом?

Наши приключения с фамиком:
https://github.com/emu-russia/breaks
https://github.com/emu-russia/breaknes

А вот пример чего можно добиться за месяц, без особого "понимания":
https://github.com/nukeykt/Nuked-MD
https://github.com/nukeykt/Nuked-MD-FPGA

Рекомендую таки сделать нетлист и проект сразу завершится. "Понимать" можно не вдумчиво вглядываясь в вентили, а анализируя вейвы при прогоне модели HDL в том же Icarus Verilog + GTKWave.

[Titus]

Рекомендую таки сделать нетлист и проект сразу завершится. "Понимать" можно не вдумчиво вглядываясь в вентили, а анализируя вейвы при прогоне модели HDL в том же Icarus Verilog + GTKWave.

Это будет опять же наблюдение за последствиями извне, не понимая причин.

Как, например, преобразовать схему в синхронную, избавиться от проходных буферов (обьединяющих две шины) не понимая всех нюансов работы?
Да и чтобы найти какую-то хитрую ошибку во флагах, нужно начинать изнутри, а не 'тупо' перебирать все комбинации, наблюдая за последствиями снаружи, вдруг чего попадется интересного.

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

Думаю, что K-MOS-овская версия Z80 в этом плане попроще, т.к. посовершеннее.