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

Особенности работы 'специального' ресета.

В общих чертах все более-менее правильно описано было в этой статье.

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

1. Вовсе не обязательно выдерживать длительность сигнала специального ресета такой, как описано в патенте. Импульс может быть длинной даже менее полутакта. Главное, чтобы во время фиксации ресета (в M1.T2.2) он был активен, а в M1.T2.4 уже не активен.
2. Импульс специального ресета устанавливается по М1.Т2, далее по M1.T1 следующего цикла происходит сброс регистра PC, а по M1.T2 импульс специального ресета снимается.
3. Импульс специального ресета задействует механизм запрета декодирования кода команды, который также используется в IM1,2, NMI, HALT. В этом режиме любая команда воспринимается декодером команд, как 00 (NOP).
4. Если специальный ресет поступил во время выполнения любой команды с префиксом, то выполнение специального ресета откладывается до окончания выполнения этой команды.
5. Также специальный ресет снимает режим HALT.
6. Если обычный ресет пришел во время M1.T2, то он задерживается на 1 такт.

КО. там упомянут один из двух патентов
https://patentimages.storage.googlea.../US4486827.pdf
про что второй - склероз...

Цитата:

Сообщение от AlexG

https://patentimages.storage.googlea.../US4486827.pdf

Я все читать не стал, но по картинке там только схема ресета в этом документе.

Интересную вещь рассказал nukeykt с эмураши.
Он сохраняет в верилоге оригинальный дизайн, а асинхронные латчи эмулирует так:

Код:

always @(posedge MCLK) begin if (CLK) x <= a; end

Т.е. MCLK (мастерклок) превышает CLK в разы.

Titus, я про это изначально всегда говорил. Ньюк эту идею подхватил когда я там был пару лет назад, когда он сначала дербанил декап YM2612 а затем Сегу-Денди.

Потихонечку пишу модули на верилоге.

Пример модуля (пока набросок):

Скрытый текст

Код:

//---------------------------------------------------------------------- // // Модуль управления внешней шиной // //---------------------------------------------------------------------- module Bus_control( input clk, // Тактовый сигнал input res, // Сигнал сброса input [98:0] pla, // Шина ПЛМ input m1, // Машинный цикл M1 input t1, // Такт T1 input t3, // Такт T3 input t3_del, // Такт T3 с задержкой input t4, // Такт T4 input grp_io, // Сигнал GRP_IO input int_ack, // Сигнал INT_ACK input dis_bus, // Сигнал DIS_BUS input bus_z, // Сигнал BUS_Z input req_write, // Сигнал запроса записи input [15:0] pcr, // Регистр PCR output mreq, // Сигнал запроса памяти MREQ output rd, // Сигнал чтение памяти или портов ввода-вывода RD output reg p_m1, // Сигнал машинного цикла M1 output reg rfsh, // Сигнал рефреша памяти RFSH output reg [15:0] adr // Шина адреса (16 бит) ); wire start_mem_cycle; // Сигнал запуска цикла чтения/записи MREQ, RD reg mreq_rs; // Триггер сигнала MREQ reg rd_rs; // Триггер сигнала RD reg disable_rd_port; // Триггер запрета вывода в порт RD (для циклов записи, холостых циклов и прерываний) //---------------------------------------------------------------------- assign stop_rd_cycle = ((!m1) & t3) | t4 | res; // Сигнал окончания циклов MREQ, IORQ, RD для чтения/записи данных // По сигналу RES // По T4 любого цикла // По Т3 любого цикла кроме M1 // Сигнал нначала цикла памяти assign start_mem_cycle = ((!m1) & t1 & (!grp_io) | // По сигналу GRP_IO и T1 любого цикла, кроме M1 (m1 & t1 & (!int_ack))) & // По M1.T1, кроме INT_ACK (цикл чтения кода команды) (!dis_bus); // При этом сигнал DIS_BUS не должен быть активен // Вспомогательные сигналы assign m1_t3_mask = t3_del & m1 & t3; // Сигнал маски по M1.T3.2 always @ (negedge clk) // Управление триггером mreq_rs (/CLK) begin if (stop_rd_cycle) // Если сигнал окончания записи, mreq_rs <= 0; // то mreq_rs = 0 (высший приоритет), else if (start_mem_cycle) // Иначе, если сигнал начала цикла памяти, mreq_rs <= 1; // то mreq_rs = 1 end assign mreq = mreq_rs & (!m1_t3_mask); // Внешний сигнал запроса памяти формируется с учетом врезки окончания цикла чтения кода операции always @ (posedge clk) // Управление разрешением RD (CLK) begin disable_rd_port <= (int_ack & m1) | // В m1.int_ack, req_write | // В цикле записи dis_bus; // В цикле без доступа к памяти end always @ (negedge clk) // Управление триггером rd_rs (/CLK) begin if (stop_rd_cycle | // Если сигнал окончания чтения, (m1 & t3)) // или начало цикла регенерации памяти M1.T3, rd_rs <= 0; // то mreq_rs = 0 (высший приоритет), else if (start_mem_cycle & (!disable_rd_port)) // Иначе, если сигнал начала цикла памяти и сигнал RD не запрещен, rd_rs <= 1; // то mreq_rs = 1 end assign rd = rd_rs & (!(t3_del & m1)); // Внешний сигнал чтения памяти формируется с учетом удлиненной врезки окончания цикла чтения кода операции always @ (posedge clk) // Управление портом M1 (CLK) begin if (t3 | bus_z) // В такте T3 любого цикла (а на самом деле в M1.T3) или же по сигналу BUS_Z p_m1 <= 0; // порт M1 переводится в 0 else if (m1 & t1) // В такте M1.T1 порт M1 переводится в 1, что означает начало цикла M1 p_m1 <= 1; // end always @ (posedge clk) // Управление портом RFSH (CLK) begin rfsh <= m1 & (t3 | t4); // Цикл рефреша памяти в тактах M1.T3 и M1.T4 end always @ (posedge clk) // Управление шиной адреса (CLK) begin if (((m1 & t3) | t1) & (!dis_bus)) // Если нет сигнала запрета чтения/записи (dis_bus), то adr <= pcr; // в такте T1 любого цила активен общий цикл чтения/записи, // либо в такте M1.T3 активен цикл записи IR на шину адреса end endmodule

[свернуть]

я правильно понимаю ситуацию после запуска процессора (PC=0, прерывания IM1 разрешены ?, во всех регистрах нули)

Цитата:

Сообщение от goodboy

я правильно понимаю ситуацию после запуска процессора (PC=0, прерывания IM1 разрешены ?, во всех регистрах нули)

Ты имеешь в виду посл ресета, а не запуска?
В регистрах конечно не нули. Ни после запуска, ни после ресета.
А после ресета PC равен нулю.

Кстати, EXX и EX AF,AF' меняет индексы группы регистров в M1.T2, а EX AF,AF' меняет в M1.T1. Интересно, зачем так по-разному сделано:v2_neutr:

И при постепенном переводе схемы на синхронный дизайн, схема становится намного нагляднее и компактнее. Большое количество латчей просто выкидывается.

Цитата:

Сообщение от Titus

Кстати, EXX и EX AF,AF' меняет индексы группы регистров в M1.T2, а EX AF,AF' меняет в M1.T1. Интересно, зачем так по-разному сделано:v2_neutr:

Осмелюсь предположить, как и в случае с ВМ80, регистр А и тем более флаги - особые. Они не находятся в общем регистровом файле (у ВМ80 регистр А физически в АЛУ, а флаги вообще просто набор отдельных триггеров, раскиданных вокруг АЛУ), а значит задействуют несколько другие сигналы управления.

Цитата:

Сообщение от HardWareMan

Осмелюсь предположить, как и в случае с ВМ80, регистр А и тем более флаги - особые.

В случае Z80 как раз AF хранится в общем регистровом файле, а флаги кэшируются непосредственно перед выполнением очередной команды.
Но думаю, что задумка была именно такая, подальше разнести момент обмена AF (такт T1) и загрузка AF по умолчанию в начале следующей команды (такт T2).
Думаю, если перенести EX AF,AF' с T1 на T2, все работало бы так же прекрасно.
Впрочем, если хотелось так заранее все сделать, никто не мешал авторам и EXX сделать в T1, а не T2.
В общем, как сделали, так и сделали)

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

Кстати, поговорил с ребятами с эмураши (nukeykt), они рассказали, как реверсили Z80.
Сперва NMOS в августе 2022, затем сейчас CMOS уже почти сделали (примерно месяц на реверс процессора!).
Схема на уровне вентилей перегонялась сперва на Си, затем на Verilog.
Т.к. версия оставалась асинхронной, то делался дополнительный мастер-клок (MCLK), в несколько раз превышающий CLK, и с помощью него эмулировались латчи примерно так, как я уже писал выше:

Код:

always @(posedge MCLK) begin if (CLK) x <= a; end

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

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

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

Цитата:

Сообщение от Titus

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

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

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

Мои все проекты на аналогичном принципе работают, по поводу ресурсов особо не парюсь, т.к. даже камни с 150к ячеек вполне себе доступны на Али, не говоря уже о 6-ти или 10-ти тысячных Циклонах IV .
Так например те же ядра процессоров Денди (PPU + APU) можно вполне себе вместить в Циклон II с 5к ячеек. Но при оптимизации дебаг будет заметно веселее, так как мест, где можно косякнуть будет заметно больше. :smile:
Единственное, что я оптимизировал, так это инверсную логику.

Цитата:

Сообщение от and1981

Мои все проекты на аналогичном принципе работают, по поводу ресурсов особо не парюсь, т.к. даже камни с 150к ячеек вполне себе доступны

Вопрос не только в количестве ячеек, но и в максимальной рабочей скорости симулируемого устройства.

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

Цитата:

Сообщение от and1981

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

Да, тут безусловно все так)

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

Цитата:

Сообщение от and1981

Мои все проекты на аналогичном принципе работают

Какие у тебя проекты?

Цитата:

Сообщение от Titus

Вопрос не только в количестве ячеек, но и в максимальной рабочей скорости симулируемого устройства.

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

Да, тут безусловно все так)

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

Какие у тебя проекты?

ядро 6502 и чипы APU и PPU NES

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

Цитата:

Сообщение от and1981

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

Я согласен, что это ускоряет процесс разработки и уменьшает число багов.
Но мой характер оптимизатора или перфекциониста, не знаю, что тут играет роль, заставляет всегда стремиться к оптимизации, если я вижу ее возможной.
Хочется из любой вещи слепить конфетку. Чтобы смотреть и любоваться)
Хотя это человекоресурсоемко, и далеко не на все хватает усидчивости)
Поэтому и получаются эмуляторы без интерфейсов типа EmuStudio. Типа, хотел, чтобы еще на тех старых PC (2005 года) все летало синхронно с разверткой, чтобы поиграться в любимые игры детства. Сделал, поигрался, удовлетворил потребность, и все.

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

Кстати, наверное это вопрос к @Alex_G, можно ли в Vivado сделать так, чтобы участок памяти ПЛИС отображался в виде какой-то графики в окне? Т.е. визуальное наблюдение за битовым массивом в виде картинки хочу.

Реализовал синхронный модуль специального ресета.
Некоторая проблема в перевода в синхронный дизайн была в том, что в основе модуля асинхронный RS-триггер, который управлялся как CLK, так и /CLK-синхронными сигналами.
Но в итоге все же перевел в полностью синхронный дизайн, и все диаграммы полностью совпали с теоретическими:v2_dizzy_ok:

reset - внешний сигнал сброса, не синхронный с CLK.
reset_c - тот же сигнал, но синхронизированный с CLK.
res - внутренний сигнал сброса, синхронный с /CLK (при специальном ресете так и остался в нуле)
spec_res - сигнал специального ресета. Активизировался, т.к. короткий сигнал внешнего сброса пришел во время такта M1.T2. И длится сигнал до следующего машинного цикла, такта М1.Т2.

https://pic.maxiol.com/images2/17300...d102720240.png

"можно ли в Vivado сделать так, чтобы участок памяти ПЛИС отображался в виде какой-то графики в окне?"

Теоретически - да (как бы в теории сия фишка была придумана для ускорения моделирования, и вряд ли для работы с графикой . хотя чем чОрт не шутит...).
Практически:
- это требуется exp lvl 50+
- знание Си (CLANG /gcc) (НЕ С++ ?)
- знание api wimdows (наверно уровня win32 - простейшие функции по работе с окнами)
- ключевые слова DPI. (для начала почитать UG900)
- возможно потребуется применение каких либо особенностей systemverilog (там вагон и тележка функционала применительно к тестированию).

Выглядит как DLLка. с точки зрения симулятора оно видится как реализация некоторого "модуля" (только не на языке верилог , а на Си - заранее скомпилированного)

ПС: такой потребности у меня ещё не было - обходился "модулями на верилоге" (для эмуляции/моделирования внешних устройств)
ПС:ПС: возможно существуют и другие возможности...
вот что первое на гуглил
https://www.doulos.com/knowhow/syste...-dpi-tutorial/

Вот пример на русском для старой версии вивады
https://fpga-systems.ru/publ/xilinx/...ivado/8-1-0-49

Вопрос задавал на емураше, но чего-то однозначного ответа не получил:

У меня такая дилемма, как реализовать банк регистров.
Или же генерить адрес регистра, с которым я работаю (0..13), и тогда удобнее использовать массив регистров reg [7..0] reg_block [16].
Либо же генерить 14 линий, и каждая линия выбирает свой регистр reg_AF, или reg_HL и т.д. Но тогда им на выходе нужно много логики, чтобы все выходы 14 8-битных регистров обьеденить в одну шину. Если бы реализовал на базе массива регистров, то это бы не понадобилось, т.к. там выбирается по адресу.
Поэтому и спрашиваю, что будет быстрее работать?

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

И еще, я спрашивал, как сделать так, чтобы компилятор не превращал многовходовый элемент типа 10-ИЛИ в кучу каскадно включенных элементов 2-ИЛИ. А чтобы группировал их параллельно. Мне предложили ключ KEEP="TRUE', но это никак не отразилось в Schematic)

максимально компактно память реализуется на примитиве BRAM - по сути это ОЗУ N*M
А вот во что реализуется память на рассыпухе - это "секрет".
По факту проще реализовать оба варианта и посмотреть что после синтеза получилось (не после елаборатион, а именно после синтеза).
То что выглядит "страшно" в коде - может быть "изящным в примитивах" и на оборот.
С другой стороны "этот кусок схемы" "живёт" в окружении других схем. По сему и выбирать "конкретный" вариант схемы.

Про атрибуты (* KEEP="TRUE' *) и еже с ними - их достаточно много для разных применений.
см UG901 глава 3. и да, есть атрибуты и для имплемента.

Про: KEEP "предложение" несколько не применимое к 10-ИЛИ.
"10-ИЛИ в кучу каскадно включенных элементов 2-ИЛИ." По факту превратится в два слоя примитивов (мне так видится на вскидку) два примитива 5 входовых и второй слой из 2 входной логики.
и сиё не зависит от этого аттрибута тк в плисе не существует единого примитива. Можно попробовать применить BRAM (это изврат)

ПС: 1) любое применение атрибутов приводит к потери "переносимости" кода verilog между разными производителями плис.
2) некоторы аттрибуты устарели
3) и временами важно где именно размещается атрибут (у имени цепи или у места определения модуля) - короче есть нюансы.

ПСПС% ну и на последок: вполне возможно (очевидно) что результат синтеза на этапе уже учитывает времянки и синтезатор может по разному синтезировать схему (и не забываем что и от имплементация ещё зависит конечный результат), Конечно если цель получить прошивку для конкретной плис и конкретной тактовой. а Если "забить на времянки" то зачем волноваться за "красоту" которую никто не увидит (да и излишне она будет для симуляции)

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

Что же касается управления памятью/портами, то там да, много активности и в полутактах. Возможно, где-то из-за того, что пытались уместить в 4 классических такта и чтение опкода, и регенерацию памяти. Поэтому чтение 1.5 такта, регенерация 1 такт. А может по каким-то еще причинам.

Но вообще, авторы - монстры. Не даром процессор столько лет живее всех живых)

Titus, ну они смогли переключиться с двухфазовой модели на однофазную и это реально прорыв.

Цитата:

Сообщение от HardWareMan

Titus, ну они смогли переключиться с двухфазовой модели на однофазную и это реально прорыв.

Двухфазная - это ты про 8080?

Цитата:

Сообщение от Titus

Двухфазная - это ты про 8080?

Именно.

Цитата:

Сообщение от HardWareMan

Именно.

Кстати, зачем нужно было двухфазное тактирование?

Цитата:

Сообщение от Titus

Кстати, зачем нужно было двухфазное тактирование?

Прозрачные латчи nMOS. На них трудно построить синхронный D триггер. Он просто не экономный выходит.

Очередной шедевр, когда сразу две единицы подаются на RS-триггер.

В случае активного ресета (RES = 1), на RES_TCLK тоже подается 1.
Сама подача RES в этом случае теряет смысл, т.к. она не просто загоняет триггер в ненужное состояние, да еще и не сбрасывает его.

Триггер находится в цепи управления остановки инкремента PCR в режиме обработки прерываний или HALT.

https://pic.maxiol.com/images2/17310...d110720240.png

тут наверно надо смотреть времянки между RES и RES_TCLK кто из них раньше (позже) относительно клока.

Цитата:

Сообщение от AlexG

тут наверно надо смотреть времянки между RES и RES_TCLK кто из них раньше (позже) относительно клока.

Это не важно, т.к. триггер синхронный, и гонка сигналов на него не влияет.

оффтоп
сорри. пьян.

Еще одна интересная особенность Z80, которая выяснилась при моделировании. Вернее, она видна и по схеме, но не приходило в голову об этом подумать.

Во время сброса процессора, сбрасывается не только счетчик PC, но еще и IR.
Это происходит из-за того, что во время ресета принудительно выбраны PC и IR одновременно. Поэтому при любой записи в PC (в такте T2) или IR (в такте T4), запись идет в оба этих регистра. А так как при сбросе обнуляется регистр инкремента PCR, то каждый цикл записи идет запись 0 в PC и IR, пока не сняли ресет.

Дошел до модели АЛУ, и тут наткнулся на подозрение, что такая конструкция переводится в схему не так, как казалось бы должно:

Код:

always @ (negedge clk) // RS-триггер выбора фазы работы АЛУ begin if (start_alu) sel_alu_low = 1; else if (req_alu_high) sel_alu_low = 0; end

Код:

always @ (negedge clk) // Регистр фиксации младшего полубайта результата begin // if (sel_alu_low) // alu_low <= alu_out[7:4]; // end //

Но второй триггер почему-то защелкивает результат на 1 такт CLK раньше чем должен.
Совершенно непонятно, как это может быть.

https://pic.maxiol.com/images2/17312...d111020240.png

Все, отбой, разобрался.
Это из-за использования неблокирующего присваивания в первом триггере. Странно, что на графике выход триггера выглядит абсолютно правильно, а симулируется неправильно.

Описание работы команд ADD/ADC/SBC HL,dd

Одна из самых нестандартных команд для Z80. Для работы сделаны множество патчей в тех или иных блоках Z80.

Описание на примере команды ADD/ADC HL,DE:

Цикл M1:

T1-T3 - выборка кода команды и завершение предыдущей ALU-операции
T4 - ALUA = L
* Загрузка в регистр PCR текущей выбранной регистровой пары HL (побочка от какой команды?)

Цикл M4:

T1 - ALUB = E
* Инкремент PCR
T2 - сложение младших полубайтов
* Запись PCR в выбранный по умолчанию регистр WZ (фактически в WZ записывается HL + 1)
(побочка от функционала записи декрементированного PC для блочных команд, чтоибы вернуться к началу блочной команды)
T3 - сложение старших полубайтов и запись результата в L
влияние на флаги P/V, Z, S (только для ADC/SBC)
влияние на флаг C
T4 - ALUA = H
флаг C записать во флаг H

Цикл M5:

Т1 - ALUB = D
T2 - сложение младших полубайтов
T3 - сложение старших полубайтов и запись результата в H

Цикл М1:

Т1 - нет стандартного ALU-цикла
T2 - влияние на флаги P/V, Z, S (только для ADC/SBC)
влияние на флаг C
Т3 - нет стандартной записи результата
T4 - сохранение флагов в регистре F

Замечание: флаг N устанавливается для любой стандартной АЛУ-операции
флаг H устанавливается для любой АЛУ-операции

Не смотря на не очень высокий интерес массовой публики к подробным (а уже не подробные, лаконичные) разборам особенностей выполнения команд, все же буду выкладывать интересное)
А именно егодня начал распутываться загадочный клубок с побочной записью/чтением регистра WZ (в некоторых документах его называют MEMPTR).
Обновил чуть выше уже опубликованный сценарий работы команд ADD/ADC/SBC HL,dd, с добавлением комментариев, где, как и почему происходит влияние на регистр WZ.

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

Фактически, после окончания цикла M1, в котором блок PCR был занят инкрементом PC, а затем IR, блок брошен на произвол судьбы, как пропеллер сорвавшийся с вентилятора) И как только ему попадается какое-то число, он его инкрементирует или декрементирует и обратно выплевывает на шину PCRBUS. В большинстве случаев от этого ничего плохого не происходит, если вдруг какой-то участок схемы, где применялось неполное декодирование условий, вдруг взял и сработал не тогда, когда надо. В нашем случае он сработал два раз, первый раз в такте M1.T4 (тут еще не знаю, побочка от какого функционала), а второй раз в такте M4.T2. Вот тут совершенно четко понятно из-за чего. В этом такте (а так же M4.T4) блочные команды откатывают PC на два шага назад, чтобы вернуться к начальному адресу блочной команды. Но как оказалось, цикл M4 использует для вычислений и команда ADD, функционал которой реализован массовыми патчами разных участков схемы. Работе команды ADD это не помешало, так как запись младшего байта результата происходит в M4.T3, т.е. посередине между M4.T2 и M4.T4. Видимо, авторы проверили, все норм работает, а то, что там попутно куда-то полетели данные в WZ, ну и фиг с ними)

Да уж, тема заглохла)

Можно закрывать лавочку за отсутствием интересующихся)

Цитата:

Сообщение от Titus

Можно закрывать лавочку за отсутствием интересующихся)

или за отсутствием у них времени на достаточное погружение в тему
ведь чтоб задать правильный вопрос, надо знать б0льшую часть ответа
да еще отрывочно излагаешь, надо бы оформить в статью нормальную

Цитата:

Сообщение от Lethargeek

да еще отрывочно излагаешь, надо бы оформить в статью нормальную

Излагаю по мере исследования.
И так уже пишу самым простым языком, и группируя по командам.
Вот такая команда, вот такая особенность.

Цитата:

Сообщение от Titus

Да уж, тема заглохла)

Можно закрывать лавочку за отсутствием интересующихся)

Мне интересно, просто я слишком далёк от таких инженерных тонкостей. Другим было бы не интересно, не было бы столько просмотров (сейчас уже 92469). Понятно, что ТС хотелось бы обратной связи (т.е. диалога и вопросов), но иногда может это и к лучшему: не отвлекает от проекта.

Цитата:

Сообщение от yashcher

хотелось бы обратной связи (т.е. диалога и вопросов), но иногда может это и к лучшему: не отвлекает от проекта.

У меня так, если нет обратной связи, то это никому не нужно, и я сам теряю интерес)

почему-же интересно, просто я отладкой TZX формата занимался. До доработки внутренностей Z80 пока руки не дошли, нужно вначале графический интерфейс для linux доработать.