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

[xolod]

а это совсем другой проект - и он возможно собирается (не смотрел)
z80.v сам по себе несколько хитёр - выглядит как "по транзисторная копия" - но насколь верно хз.

Это просто порт этого проекта на MiSTer

[Advertiser]

[AlexG]

ОФФТОП: в первом не хватает файлов (в принципе) для целостности "именно этого проекта", а во втором оные файлы добавлены.
По Теме: в z80.v зачем-то присутствуют две тактовые CLK и MCLK. Их соотношение между собой мне неизвестно. Для этого надо копать либо первый проект, либо второй (заточен под альтеру, а у меня "нет" квартуса).

[AlexG]

Всё это несколько ОФФТОП для ТС.

[Titus]

Фух!

Наконец-то перевел транзисторную схему Z80 NMOS в логическую, попутно причесывая и транзисторную.

Чем дальше понимаешь логику работы, тем лучше причесывается схема, группируется по функциональным блокам и т.д.

Логическая схема полу-причесана, поэтому это только первый этап.

Кстати, уже нашел всякие интересности. Например, странную избыточность в цепи выборки команд CB.
Наверняка, при анализе какие-нибудь тайны Z80 все-таки всплывут)

Для затравочки кусочек с ALU:


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

Из интересностей:

Всего в процессоре 14 16-битных регистров. 12 регистров (IX, IY, HL, DE, BC, HL', DE', BC', AF, AF', WZ) сидят на основной шине, а два регистра PC и IR расположены на отдельной шине, причем при необходимости между этими двумя шинами может выстраиваться мост, чтобы получался доступ к PC и IR с основной шины.
Впрочем, оно и понятно, т.к. PC и IR имеют свои блоки инкремента/декремента, сравнения и т.д., т.к. используются параллельно с основным вычислительным блоком.

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

И похоже, что всякие блок-схемы Z80, в фирменно документации и не только - не имеют никакого отношения к реальной структуре процессора. Может просто я не все их видел.

[parallelno]

Titus, очень крутая работа!

[Titus]

Несколько интересных фактов о Z80 для затравочки:

• Внутренняя частота работы процессора фактически в два раза выше, чем частота тактирования CLK. Это связано с тем, что часть действий процессор выполняет во время положительного полутакта CLK, а часть во время отрицательного полутакта CLK.
  
  
• Многие блоки в процессоре конвейеризированы, из-за чего команды выполняются быстрее, чем без конвейера. Например, простейшая команда вида LD r1,r2 в реальности выполняется за 6 тактов, а с конвейером за 4 такта. А команды работы с АЛУ вида ALU A,r в реальности выполняются за 7 тактов, а с конвейером за 4 такта.
  
  
• Команды вида ALU A,r модифицируют регистр флагов F в 7-м такте своего выполнения. В этом же такте следующая команда должна считать регистр AF из регистрового файла для своей работы. Чтобы не было накладок, предусмотрен специальный режим, когда следующая команда не читает AF из регистрового файла, а читает его с шины HBUS/LBUS одновременно с записью предыдущей командой регистра F в регистровый файл.
  
  
• Абсолютно любая команда в начале своего выполнения читает в 3-м такте регистр AF из регистрового файла, не зависимо от того, понадобится этот регистр или нет.
  
  
• Дополнительный блок быстрого инкремента/декремента 16-битного числа, позволяет делать инкремент/декремент всего за один такт. Во время выполнения самой короткой однобайтовой команды (4 такта) этот блок используется два раза - первый раз для инкремента регистра PC, второй для инкремента регистра IR (младшие 7 бит). Следует заметить, что было бы совсем не сложно используя этот блок, добавить дополнительные команды адресации с автоинкрементом типа (HL)+. Но авторы почему-то этого не сделали.
  
  
• Тактовый генератор формирует до 6 T-циклов, и до 5 М-циклов, в зависимости от команды. Линия WAIT влияет только на задержку между циклами Т2 и T3. Все остальные циклы приостанавливаться не могут.
  
  
• M-циклы могут быть различной длины. Например, цикл M1 длится 4 такта для всех команд, кроме LD SP,HL, PUSH, IND/DEC dd, DJNZ, RET cc, LD I/R,A, LD A,I/R, OUTI/OUTD/OTIR/OTDR, INI/IND/INIR/INDR, RST, а так же в прерываниях IM1 и IM2.
  
  
• Процессор построен как конечный автомат без каких-либо микропрограмм. Если переложить на язык программирования, то упрощенно говоря весь процессор - это огромный список команд IF, с множеством условий каждая. Например, IF (TAKT=T1 && CYCLE=M2 && REQ_FLAGS=0) THEN DO SOMETHING.
  
  
• Процессор спроектирован достаточно оптимизировано. Говоря языком программирования, хорошо скомпилирован. Однако, в некоторых местах встречаются избыточные цепи, а в некоторых местах видно, как обьединялись несколько модулей, каждый из которых оптимизирован, но суммарная оптимизация после обьединения не производилась.
  
  
• И, конечно, внутренняя структура мало соответствуют тем блок-схемам, которые описывают Z80 в различных документациях.

[Titus]

Оказывается, регистр флагов имеет некий промежуточный динамический кэш, который требует регенерации.
И получается очень интересное дело.

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

Кто-то может сказать - почему же не предусмотрели ситуацию, когда часть флагов надо кешировать из F, а часть изменять? Это усложнило бы схему. И так, 50 лет процессору почти, а никто на эти подводные грабли еще не наступил.

Смоделируем следующую ситуацию:
1. Выполняем NOP. Текущие флаги закеширповались в динамическом кэше F.
2. Выполняем последовательно много раз команду, которая влияет не на все флаги. Например, SCF.

Во время выполнения команды SCF предполагается, что, например, флаг Z не изменился, поэтому кэшированное значение не обновляется. Однако, ячейка хранящая состояние флага S динамическая, поэтому ей все время нужна регенерация. И через некоторое время она потеряет свое значение.

Предлагаю реальщикам провести тест на процессоре NMOS архитектуры, примерно вот такой:

LD A,0 (или $FF)
OR A
NOP (загрузка кеша текущими значениями флагов)
SCF (на все 48Кб)
тут смотрим флаг S

[Lethargeek]

SCF (на все 48Кб)

~56 миллисекунд - сильно сомневаюсь, что утечёт
помнится, раздельную память на фирме тестировали, ждали долго

[Titus]

~56 миллисекунд - сильно сомневаюсь, что утечёт
помнится, раздельную память на фирме тестировали, ждали долго

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

Если не получится изловить на 48кб, надо посмотреть, можно ли соорудить цикл, который не перекеширует флаги, и тогда в цикле уж точно выловится.

Похоже, реальщиков желающих пока не нашлось)

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

Хм... думаю, что цикл устроить не получится, т.к. любая команда перехода перекеширует флаги

Однако, время работы непрерывной последовательности можно увеличить, заменив SCF, например, на ADD HL,dd.

[zebest]

Похоже, реальщиков желающих пока не нашлось)

ну почему же.
есть тесты CCF\SCF, причем в зависимости от производителя\мануфактуры - аж три различных варианта поведения этих самых недокументированных флагов. Вернее есть и 4 вариант("синдром"), что-то похожее на утечку, но пока это малоповторимо и точно никто из причастных не может сказать, с чем связано 4-е поведение, говорят - невоспроизводимый глюк Тесты от Патрика же, с картинками...
https://github.com/raxoft/z80test/tree/master/img
это результаты, других вариантов по паттернам не бывает.
Но бывает, что картинка "дрожит", как буд-то флаги произвольно меняются, что в принципе не должно быть. Может это та самая утечка?))
https://github.com/raxoft/z80test/bl.../z80ccfscr.asm
как бы сам тест, десяток строк