железный debugger для z80 систем

[bigral]

помогите сочинить народную схему для subj

тема уже не новая, както пытался обсуждать ее тут http://www.nedopc.org/forum/viewtopic.php?f=68&t=19660

суть:
------------------------------------ скопировал старое сообщение оттуда-----------------------------------------------
Возник тут у меня затык с одной платой (игровой автомат на основе MSX2 для игры в zanac-ex) при сбросе шото там происходит внутрях msx2 bios и оно зацикливается вначале вывода заставки MSX, как я понимаю приходит сигнал прерывания и после него шото там ломается... если сигнал прерывания оторвать от процессора то заставка MSX таки "выезжает" до конца но потом зацикливается уже в самом конце... долго я пытался шото понять че там происходит, советовали мне сделать типо как POST карточку (порт подключенный к семисегментному индикатору) и править прошивку чтоб знать до какого места оно доходит нормально а где дело идет уже не так как надо... но все это кажется мне негодящимся для такой проблемы.

Чего задумал, подключить на шину Z80 самодельный компаратор сигналов с заданным pattern-ом и как токо на шине появляется нужное мне состояние выставлять ~wait_n. Ну и как-то ж потом надо считывать значения с шины значит и напрямую девайс должен уметь читать значения с шины. Ну и возможно в портах и памяти тоже надо уметь лазить, потому наверно еще надо как-то ~busreq_n задействовать. В общем думаю что UI для этой штуки должен обеспечивать сторонний комп (terminal?) а сама штука ввиду сложности скорее всего должна иметь MCU (отвечающий по serial наверно, или по USB что наверно излишество), по идее тут идеально ARDUINO подходит. Ну а вводить\выводить данные нужно будет наверно через i8255 + регистры? либо влепить сходу несколько штук i8255 (хотя там многие однонаправленные регистры будут, как минимум для stop-pattern-a, i8255 для таких будет overkill)

Может ктото решал уже подобную задачу? Ктото знает про "штуку" с кучей i/o и управлением с компа?
----------------------------------------------------------------------------------------------------------------------------

вот нарисовал в меру своего понимания схему, смотрите в attachment-e

схему сопряжения с управляющим компом не рисовал, думаю ее сочинить будет легко, по сути надо обеспечить запись\чтение регистров из 2-х i8255 (у каждой микрухи 4 регистра, т.е. всего нужно 8 адресов)

эти две i8255 висят на шине подопытного z80 компа, U1 может читать\писать значения с\на его шинны адреса и данных (при выполнении проги все порты включенны на ввод), U2 своими портами A и B может задать адрес точки останова (останов происходит по ~wait_n сигналу z80), эти порты всегда работают на выход (в связи с этим вначале думал влепить простые ИР23 но это усложнит схему и унификация програмного интерфейса которую дает применение i8255 тоже уйдет), порт С у U2 разделен на 2 части по 4bit-a, первая часть по идее может работать и на ввод и на вывод (PC0-PC3) устанавливая или читая ~rd_n ~wait_n ~mreq_n ~iorq_n, а вторая часть (PC4-PC7) должна работать только на вывод и устанавливать режимы работы, PC4 - для вкл\откл BREAKPOINT-a, PC5 - для CONTINUE, PC6 - для захвата шины z80 (по идее в этом режиме можно вместо самого z80 лезть в память и порты подопытного), PC7 - для генерации маскируемого прерывания (возможно тут на выходе потребуется влепить одновибратор чтоб укоротить ~int_n до нужного значения).

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

[Advertiser]

[dvarkin]

ИМХО, я бы сделал без 8255 — на одной DIP40 avr'ке типа ATmega16 (их много и на них можно поставить среду Arduino) + USB UART свисток, моё любимое сочетание.
Ещё момент — если доступ к памяти осуществляется через ULA, то иногда нужно точно имитировать поведение процессора, например, про Т34ВГ1 уже обсуждали в теме https://zx-pk.ru/threads/31140-chten...ati-omevm.html
В частности, /WAIT у Т34ВГ1 — это, мне кажется, только выход.

[bigral]

Не хватило бы i/o у atmega16, а i8255 и есть универсальные i/o расширители которые могут менять находу направленность, эти 2шт i8255 - абстракция програмного и аппаратного интерфейса на уровне 2 пачек регистров i8255, потом сам софт для дебага будет легче перенести на разные платформы и подключать хоть к спектруму, хоть к бк-шке, хоть к ардуине.

Т34ВГ1 это процессор, ~wait_n у него должен быть входом, а иначе теряется изначальный смысл самого сигнала.

по поводу доступа к памяти вместе с ULA, да тут такой простой схемы никак не хватит, надо мутить автомат на рт-шках и заводить на него сигнал /CLK (ну и ~wait_n) а процессор при этом держать в режиме dma...

[caro]

Союз Arduino и классического процессора:
https://habr.com/ru/post/446048/

[dvarkin]

Да-да, ошибся, в последнем абзаце #2 ВГ имелся ввиду.
И с ATmega16 тоже не угадал, вот у ATmega8515 (также у ATmega161 и ATmega162) 35 GPIO — после ША и ШД останется 11 свободных, используем для UART 2 и получится 9, вроде, хватает, и шины нагружать не будет сильно.
Однако, если будет написан софт для спектрума, то ВВ55 ИМХО оправдан, так уж и быть.

[dvarkin]

А у STC12C5A60S2 (1T 80C51) GPIO даже больше!

[bigral]

а ктото может нарисовать схему "эмуляции" доступа z80 к шине (с учетом ~wait_n и clk сигналов)? схема должна уметь писать и читать ячейку памяти или регистр порта

[bigral]

чето я тут поэксперементировал немного подумал и сделал вывод что такой debug можно сделать только для классической схемы на z80 (ну т.е. схемы в которой не применяются те хаки с задержкой clk которые применяют в zx spectrum), потому что если этот debug будет стопорить процессор по ~wait и потом читать что там процессор выставил на шину (какой адрес) и что там ему отвелила память то может произойти конфликт с ULA который по ~wait процессора естественно не стопорится и будет считан какойто мусор

это правильные мысли? или я чегото не понял?

кроме того dram висит прямо на шине данных и refresh происходит за счет регистра R процессора, т.е. такая схема явно не рассчитанна на длинное удержание ~wait (так как refresh dram будет невозможен), чтоб нормально стопорить на долгое время нужно чтобы был или SRAM которому пофиг сколько держать результат на выходе, либо регистр который бы сохранял результат чтения dram на нужное время не задерживая refresh dram (ну и тогда нужно по сути как-то сэмулировать на шине поведение SRAM а сигнал refresh процессора можно не использовать).

[shurik-ua]

лучше использовать BUSRQ имхо

[bigral]

лучше использовать BUSRQ имхо

я так понимаю его нужно будет использовать при желании делать peek/poke, т.е. сначала процессор тормозиться по ~wait и можно глянуть что он там выставил на шину и куда обращается, потом ему устанавливаем busreq и после получения busack можем прочитать скажем следующие несколько байт для того чтобы показать дизассемблированный текст оператору с указанием текущего положения PC, потом отпускаем шину и отпускаем ~wait, схема single step которая учитывает сигнал /m1 таки нужна для того чтобы например выставить breakpoint на обращение к данным и потом сделавши step узнать откуда ж таки это обращение было сделано