Реверс-инжиниринг 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)

[Advertiser]

[Lethargeek]

* 2022 - [NMI rejection](https://spectrumcomputing.co.uk/foru...pic.php?t=7086)

авоткстате - как оно конкретно реализовано? то же самое касаемо и EI
можно ли сказать, что в z80 помимо iff1 и iff2 есть аналогичный флажок iff3 (iff4) ?
или там какой-то целый отдельный блок (или несколько), который издевается над iff1?

[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 в этом плане попроще, т.к. посовершеннее.

[org]

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

[Deadly]

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

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

[org]

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

Через меня вряд ли быстро получится, т.к. я планирую реверсить только блоки с кастомным дизайном (АЛУ предположительно CLA, а также блок регистров).
Остальным будет заниматься nukeykt
Купаемый в кислоте CMOS з80 - это от тошибы: https://siliconpr0n.org/map/toshiba/...mz_gf50x-1.25/ (Фотки сделаны Борисом onidev, но только металл, чего нам не достаточно).

У меня есть в процессе восстановления масок "другой" CMOS Z80, родной зилоговский (https://github.com/emu-russia/SEGAChips/tree/main/Z80), но пока им заниматься лень. С ним не очень гладко всё прошло, delayer получился очень "грязный".

[Deadly]

Через меня вряд ли быстро получится

ты как и титус только через форум, или можно связаться в ТГ ?