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

[Titus]

А что, там читается именно AF, не просто F? А при записи - тоже? Там 16-битная шина считывания из регистрового файла? А по записи - тоже 16 бит?

AF читается всегда целиком 16 бит. А записываться может по частям..
Там две 8-битных шины, каждая из которых может работать отдельно друг от друга. Кроме того, обе эти шины могут обьединяться (пробрасывается мост с HBUS на LBUS). Причем, практически все операции как раз и проходят в режиме обьедененных шин, т.к. работа идет с 8 битами.

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

А там возможно одновременное чтение и запись в регистровый файл? Или только по очереди, чтение либо запись?

Есть возможность одновременного чтения/записи в старшую/младшую часть регистров. Единственное ограничение, это должен быть один и тот же регистр. Допустим, A читаем, F пишем. Другой вопрос, используется ли это, я еще не проверял.

Что касается всего регистрового файла, то, как я уже писал выше, он состоит из двух матриц. В одной из них почти все регистры, в другой PC и IR. И между ними тоже может образовываться мост. Вот в эти две части регистрового файла можно писать и читать одновременно разные регистры. Например, PC читается, и в это же время какой-то другой регистр тоже читается или записывается.

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

А кто присвоил шинам эти названия, это ты сам в ходе анализа? Или есть где-то отсылка к "оригинальным" названиям?

Несколько названий сохранились от проекта Z80 Explorer, другие же я обозвал сам по их назначению. Впрочем, пришлось переименовать шины, названные в Z80 Explorer VBUS и UBUS в LBUS и HBUS, т.к. это лучше соответствовало их назначению.

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

Кстати, вот еще интересный вопрос. АЛУ 4-битное, значит, не может принять весь операнд за один заход. Где хранится та часть операнда, которая ждет обработки в следующем такте? Она держится на шине, которая все это время прокоммутирована к источнику информации (регистровому файлу и т.д.)? Или там есть промежуточные регистры хранения?

Там много промежуточных защелок, в которых все это хранится. Как на входе АЛУ, так и на выходе.

Вот кусочки схемы:

Выход


Вход


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

Скажи, а ты что, сам занимаешься анализом Z80? Это же какая охренительная должна быть квалификация! Ты что заканчивал?

Я занимаюсь для того, чтобы понять нюансы его работы) Без этого точный эмулятор не напишешь. А я же эмуляторщик)
Ничего не заканчивал связанного с электроникой. Я программист.
Но я уже столько отреверсил чипов (для УКНЦ), что для меня это уже не особо сложная задача, просто кропотливая. Что делать, если никто не сделал, а хочется)

Многие реверсят до транзисторного вида, иногда даже не причесывая, и либо засовывают в FPGA, либо симулируют, как в Z80 Explorer. Но это не дает информации о нюансах работы. Да и плавающие состояния тут можно упустить. Единственный вариант, на мой взгляд, познать всю суть работы процессора - это построение причесанной и понятой транзисторной схемы, а по ней логической.

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

Вот чего мне менее всего интересно, это сидеть перерисовывать слои с кристалла.

Идеально, если уже есть потранзисторная схема, пусть даже просто в виде списка транзисторов и соединений. С чего я и начал реверс Z80, собственно.

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

ну почему же.
есть тесты CCF\SCF, причем в зависимости от производителя\мануфактуры - аж три различных варианта поведения этих самых недокументированных флагов.

На счет этого теста.
Думаю, что причина в том же - обилие динамических защелок в блоке формирования флагов.
Впрочем, их много в принципе в этом микропроцессоре. Но большинство из них тактируются CLK, и на частоте работы процессора работают как статические. А вот в блоке формирования флагов много наворотов, в том числе и с динамическими защелками, тактируемыми как придется. Так что вполне возможно, что утечки можно добиться. Надо проанализировать их работу на досуге, просто пока до них не дошел, только до флага S, о котором рассказывал выше.

Замечу, никто еще не вызвался проверить мое предположение на NMOS реале.

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

Немного о блоке формирования флагов:

S - флаг знака самый простой, в него просто копируется 7-бит результата работы АЛУ.
Z - флаг нуля почти такой же простой, формируется, если результат работы АЛУ равен 0. Однако там есть дополнительная цепь установки, сброса, обратной связи. Зачем она нужна, еще не разбирался.
N - флаг сложения/вычитания. Именно по этому флагу АЛУ знает, что нужно делать, складывать или вычитать (то же сложение, но второй аргумент инвертируется). Крайне интересно, что команды относительного условного перехода (и не только), использующие АЛУ для получения эффективного адреса, кешируют во нутренний кеш этого флага предыдущее состояние флага S(!). С чего бы это? Еще не разбирался. Должно быть, чтобы понять, вычитать смещение или прибавлять, в зависимости от знака смещения.
C - флаг переноса. Работает в целом весьма документированно, за исключением того, что для команд AND, CCF, SCF в него копируется инвертированное значение флага H(!) (полупереноса). Видимо, таким образом команда CCF инвертирует флаг C, пропуская его через полуперенос.
H - флаг полупереноса один из самых навороченных. Единственное, что пока могу сказать, он всегда изменяется для всех команд, которые влиют хотя бы на какие-то флаги. Т.е. у него нет кеша предыдущего его значения.
PV - флаг четности/переполнения - пока не разбирался.

[Advertiser]

[Кря Кря]

Причем, практически все операции как раз и проходят в режиме обьедененных шин, т.к. работа идет с 8 битами.

И вот этот момент не воспроизвести в FPGA, как и висящее на зарядах затвора значения.
У меня есть подключенный к DE1 z80, могу провести разного рода эксперименты, при условии понятного мне условия теста и тестового кода

[Titus]

И вот этот момент не воспроизвести в FPGA, как и висящее на зарядах затвора значения.
У меня есть подключенный к DE1 z80, могу провести разного рода эксперименты, при условии понятного мне условия теста и тестового кода

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

Если процессор NMOS, то обязательно надо сделать тест. На других архитектурах не надо, т.к. от них нет реверса.

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

шта? по всем докам ровно наоборот - по сложению или вычитанию значение флага определяется

Доки врут)
Я смотрю на схему и она гласит об обратном) Сначала выставляется флаг, потом АЛУ смотрит на флаг и говорит - о, флаг вычитания стоит, значит инвертирую второй аргумент.

[Кря Кря]

Если процессор NMOS, то обязательно надо сделать тест. На других архитектурах не надо, т.к. от них нет реверса.

Нужен конкретно zilog или nmos от других производителей тоже подойдут?

[Titus]

Нужен конкретно zilog или nmos от других производителей тоже подойдут?

А вот этого я не знаю. Я даже не знаю, с какой конкретно модели в проекте Z80 Explorer снимали схему.
Но, думаю, стоит попробовать на любом NMOS.

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

Игрался с z80 и МК. Могу задавать любую частоту, могу анализировать всё что хош. Выставляйте условия.

Задача такая. Если на спектруме, то по адресу $4000 разместить примерно такой код:

DI
LD A,0 (или $FF для второго теста)
OR A
NOP (загрузка кеша текущими значениями флагов)
ADD HL,DE (или SCF) (на все 48Кб)
В конце выполнения смотрим регистр флагов

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

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

На основании кода команды. А именно:



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

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

Кому известна? Блоку декодирования команд и флагов) А АЛУ неизвестна. АЛУ как раз ориентируется на флаг, чтобы инвертировать аргумент.

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

инверсия - НЕ унарный минус! (в дополнительном коде)

Разумеется. Но по скольку АЛУ всегда делает ADC, а не ADD, то как раз инвертируя входящий перенос и получается вычитание. Вообще, т.к. блок АЛУ 4-битный, он не ориентируется на флаг C, он ориентируется на флаг H. Думаю, поэтому флаг полупереноса вообще и был сделан в процессоре в том числе, т.к. он фактически является связующим переносом между двумя отдельными действиями 4-битного АЛУ.

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

Кстати, еще из интересного.

Регистр WZ, выбирается всегда, когда на том или ином этапе выполнения команды не выбран другой регистр. Там так и стоит широкое условие, что если не AF, если не HL, DE и т.д., то тогда выбираем WZ.

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

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

И еще кстати - я думаю, что то, что имеется в виду под регистром MEMPTR, от которого в 3 и 5 битах в регистре флагов остаются следы, на самом деле не существует. Это просто остаточный заряд на шинах HBUS/LBUS. А так как LBUS используется для формирования флагов, и во время формирования флагов 3 и 5 биты просто не презаряжаются, а остаются, как есть, то и получается соответствующий результат.

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

Есть, конечно регистр PCR (так его назвали авторы Z80 Explorer). Может его и можно считать MEMPTR, т.к. через него инкрементируются 16-битные регистры типа PC, IR (7 бит).

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

Если кому интересно, текущий набросок выглядит так:

NMOS Z80 - sketch rev.14.pdf

[Lethargeek]

Кому известна? Блоку декодирования команд и флагов) А АЛУ неизвестна. АЛУ как раз ориентируется на флаг, чтобы инвертировать аргумент.

казалось бы, почему декодеру не сообщить тип операции в АЛУ напрямую
а так выходит, что многие команды флаг по сути портят (для единственного штатного применения)
ну, и под значениями флагов в доках понимается значение перед выполнением команды, а не в процессе

[Titus]

а так выходит, что многие команды флаг по сути портят (для единственного штатного применения)

Выходит, что так. Особенно с флагом полу-переноса.

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

при сложении наверно надо еще записать #0000 в DE.

Это не обязательно, т.к. мы смотрим флаг S, а на него ADD HL,DE не влияет не зависимо от аргументов.

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

проверил на сером +2

По твоему тесту сбоя не видать. У тебя NMOS процессор?

[goodboy]

ADD HL,DE (или SCF) (на все 48Кб)

при сложении наверно надо еще записать #0000 в DE.
проверил на сером +2

add hl,de ; a=#00 ; ............... ; F=#44
            a=#FF ; ................; F=#84

SCF ;       a=#00 ; ............... ; F=#45
            a=#FF ; ................; F=#AD

отличия с эмулем есть !!!
SpecEmu выдаёт #6C

[Titus]

отличия с эмулем есть !!!
SpecEmu выдаёт #6C

Ну это из-за другой особенности, из-за CCF, я думаю.

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

Погулял по транзисторной версии схемы, никакой утечки во всем блоке формирования флагов не нашел
Значит недокументированное поведение CCF не связано именно с утечкой в блоке флагов.
Надо будет посмотреть последовательно алгоритм выполнения CCF.

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

Проследил всю цепочку выполнения CCF.
Отличия от обычного NOP:
1. В такте T5 (T4 + 1) копируется кешированный ранее флаг C во флаг H
2. В такте T6 ничего не происходит
3. В такте T7 (T4 + 3) копируется инверсная копия H во флаг C.
4. В такте T8 (Т4 + 4) флаги выставляются на шину LBUS (кроме 3 и 5).

Поэтому если какой-то глюк и есть в CCF, то его надо искать только в 3 и 5 флагах, т.е. в состоянии LBUS во время выполнения CCF.

Но на LBUS я тоже не вижу никакого мусора. Туда копировался флаг F перед началом команды, значит флаги 3 и 5 должны были сохраниться.

Словом, пока не вижу по схеме потенциальных глюков, откуда они взялись в тестах иностранных товарищей.

А что касается команды SCF, то она работает абсолютно также, как CCF, за единственным исключением - в такте T5 флаг H очищается. Поэтому флаг H=0 при инверсии становится 1, и C становится равной 1.

[Barmaley_m]

У меня есть подключенный к DE1 z80, могу провести разного рода эксперименты, при условии понятного мне условия теста и тестового кода

Это дает огромные возможности. Скажем, если снизить тактовую частоту Z80 и подставлять ему команду SCF (или какая там нужна) в циклах M1 по всем адресам памяти - то можно выдержать достаточно времени до гарантированного разряда емкостей затворов, если от них что-нибудь зависит.