4-bit Processor

[Shaos]

А куда столько диодов по низу?

[Lavr]

А это же диодный ДЕШИФРАТОР КОДОВ ОПЕРАЦИЙ АЛУ!
Придуманный и проверенный мной уже давно - вот сейчас он
быстро и вписался в схему ЦПУ...

[Shaos]

А это же диодный ДЕШИФРАТОР КОДОВ ОПЕРАЦИЙ АЛУ!
Придуманный и проверенный мной уже давно - вот сейчас он
быстро и вписался в схему ЦПУ...

понял

P.S. а есть схемка побольше, а то номеров не видать

[Lavr]

...а есть схемка побольше, а то номеров не видать

Пока нету... я сейчас выполняю окончательную проверку и вношу изменения в схеме,
о которых написал выше. Как закончу - выложу большую схему и весь проект
"Протезуса", ну как я обычно и делаю...


P.S. Ну и прикольно же я имплементировал инструкцию HLT, аж самому смешно!
Без единого дополнительного вентиля!!!
Как в популярной в былые времена песенке:"Сделано всё без единого выстрела!..."

Я уже выше написал, что HLT приостанавливает микропрограммный счетчик,
ну или тактовый генератор приостанавливают, а для этого нужен
хотя бы RS-триггер, чтобы потом по RESET запустить всё заново
и "отпустить" счетчик или тактовый генератор...
А мне просто жуть как не хотелось ничего добавлять, но от
нереализованной инструкции CALL остались свободными 2 вывода
ПЗУ микрокоманд. И поскольку программный счетчик команд РС сделан
на реверсивных счетчиках К155ИЕ7, то я и завёл один из выводов
ПЗУ микрокоманд на вход счета на уменьшение...

Инструкция HLT теперь откатывает программный счетчик команд - РС
на 1 инструкцию назад, т.е. указывает снова на саму себя, а после
нее FETCH увеличивает на 1 РС, но снова выполняется HLT, который
откатывает РС назад... Так всё и топчется на адресе инструкции HLT!

Кстати, чисто на будущее, это куда лучше остановок микропрограммного
счетчика или тактового генератора, поскольку процессор не остановлен,
а работает, можно легко обслужить прерывание, если будет нужно, а
не только выходить из состояния HLT по RESET...

Но выглядит это реально смешно, когда смотришь на индикатор РС...

[Lavr]

Аппаратно хочу пока заменить этот странный 155ИР26, которого у меня так и нет, на К155РУ2,
аналог которой - (К589РУ01 - 16 слов по 4 разряда) я таки сподобился приобрести...

Приобрести оказалось хоть и не совсем просто, но проще, чем заменить...
Аналог этих двухпортовых ОЗУ - 74LS189 - в моей версии "Протезуса" не поддерживается,
а модели, найденные в сети, изругали мой "Протезус", как непотребно старый...

Пришлось делать модель для ОЗУ на 16 нибблов самому, и самый кратчайший путь оказался -
смоделировать на 4-х моих же собственных моделях 155ИР26, сделанных ранее.

74LS189_sch.gif

Получилось не совсем точно К155РУ2 = К589РУ01 ~ 74LS189, но довольно
близко к оригиналу. Ну и главное - заработало нормально...

16 4-битных регистров общего назначения - всё же получше, чем 4.. хотя несколько изменилось
управление ими, но, надеюсь, это не ухудшит проект.

[Lavr]

Ну вот, в преддверии Нового Года более-менее безглючная Beta-версия 4-битного нищебродского
процессора из ТТЛ-хлама и заработала довольно-таки устойчиво...
Вычистил все глюки и ошибки, которые нашел (но, наверняка, насовал новых на этом пути).


Увеличить

Схема электрическая принципиальная (большая).

Итоговая система команд выглядит следующим образом:



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



В общем-то вручную я написал примерно байт 200 кода и это меня подутомило...
Поэтому в архиве проекта 4_Bit_CPU_ALU есть утилита от PIC - Bmp2asm.exe - транслирующая
BMP-картинку нужного размера LCD в массив кодов, ну и я дописал утилитку ASM2HEX.EXE,
превращающую этот массив кодов в бинарный код 4-bit CPU.

Под LCD от Nokia 3310 расположена игровая клавиатурка, дублирующая кнопки, подключенные
к порту ввода, но кнопки этой клавиатурки управляются кроме мыши еще и нажатием клавиш
на клавиатуре компьютера "1", "2", "3", "4". И это можно легко поменять, если надо...
Кнопки "2" и "3" сейчас не выполняют в программе определенных функций, хотя и опрашиваются.
То есть, я прицеливался написать какую-либо игрушку, но оценив скорость эмуляции LCD,
я отказался от этой бесперспективной затеи - медленно слишком...

Да и программировать в кодах - это, конечно, спорт своеобразный... но особого экстаза не вызывает...

[tihsasha1967]

По моему в системе команд перепутаны команды SKIP NC и SKIP C. Другие условные переходы не проверял.
Делаем так.

Code: Select all

000  11    MVA  0x01   ;  A=1.
001  B7    DCR         ;  A=0.  Тут СF не должен установиться. Но  _CF_  pin2U13='1' 
002  A9    SKIP NC     ; пропуск 2-х байт, если нет паритета. Реально тут его нет.
003  F0    JMP         ; безусловный переход на 007h.  Мы попали сюда. Хотя должны были эти 2 байта пропустить.
004  07                ;
005  00   
006  00
007  B7    DCR         ;  A=0Fh,  тут СF должен установиться. Но  _CF_  pin2U13='0' 
008  A1    SKIP C      ; пропуск 2-х байт, если паритет. Реально он тут есть.
009  F0    JMP         ; безусловный переход на 000h.   Мы сюда попали, хотя не должны были.
00A  00                ;
00B  70    HLT         ; 

Кстати, команда HLT повела себя совсем не так, как Lavr рассказал (Dec PC и Inc PC). Останова не произошло. К программе выше это не относится.

[Lavr]

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

Хотя с 10 дек 2015 года я находил некоторые ошибки и неточности (в частности неверно аппаратно
работает инструкция SFA), но на SKIP XX и HALT у меня нареканий не было.

Возможно, у Вас версия Proteus несколько иная. Я тестирую на 6.7 и 7.7.

Но если Вам кажется, что это действительно так, то я выкладывал редактор микрокода, можете
сами себе микрокод подправить.


P.S. Проверил Ваш пример: SKIP C(NC) работают верно, DCR работает верно, а вот с установкой
флага C, действительно, есть неувязка, и мы её вот здесь обсуждали.
Команду DCR АЛУ выполняет как A - 1 или как A + (/1 + 1) = A + Fh.
Отсюда и получается: 1 - 1 = 1 + Fh = 10h - возникает перенос C.
Возможно, следует инвертировать флаг переноса в последнем такте операции DCR.
А может быть - просто учесть эту особенность, чтобы не усложнять CPU аппаратно...

[Lavr]

Я думаю, надо подвести некоторые итоги этому проекту, поскольку проект получился, и основной
своей цели он достиг. А цель была - сделать довольно функциональный процессор на логике,
причем логика должна быть легко доступной, как для журнала "ЮТ" в 80-х годах.

Вторая цель этого проекта оказалась несколько эфемерной: сделать простой процессор на логике,
но так, чтобы он смог эмулировать КР580ВМ80 на приемлемой скорости - этого достичь трудно.

С 10 дек 2015 года я к этому проекту не раз возвращался, и довольно добротно его всё же
протестировал, нашел аппаратную ошибку в реализации инструкции SFA (перед ней не сбрасывался
флаг переноса C).

Я далее выложу последний исправленый вариант проекта и более вносить аппаратных изменений
в этот проект не буду. На мой взгляд, в нём достигнут приемлемый баланс функциональности
и "нищебродскости". Расширять функциональность при желании нетрудно, для этого я оставил
в системе команд инструкции IN и OUT. В PDP-8 посредством их делаются многие расширения,
и здесь это тоже сработает: можно расширить память, коммутируя банки памяти и т.п.
Но этот вариант будет простейшим и базовым.

Немного об особенностях, обусловленных "нищебродскостью" проекта:
1. Нет полноценных CALL и RET.
Их реализация в любом варианте приводит к усложнению схемы, которое я счел неприемлемым
для данной простой конструкции.
Есть компромиссное решение - возврат на фиксированный адрес, кратный 256. Это требовало
специфического ассемблера, я такой ассемблер написал и далее выложу его.
Второй компромиссный вариант - использовать некое подобие программного стека, как это
сделано в 4-битном компьютере Nibbler. Суть этой затеи в том, что мы входим в подпрограмму
инструкцией JMP без условия, но в один из регистров записываем признак возврата = 1, 2, ...
на выходе из подпрограммы, анализируем этот регистр, и по записанному в нём числу выполняем
безусловный JMP туда, куда следует вернуться. Криво, несколько длинно, но работает!
Я считаю, двух этих вариантов достаточно, чтобы обойтись без полноценных CALL и RET.

2. В операциях вычитания флаг переноса C получается инверсным, поскольку вычитание выполнено
как сложение с инверсией вычитаемого + 1. Возможные варианты - инвертировать флаг переноса C
ПОСЛЕ каждой операции вычитания, а их в наборе команд три!
Поэтому я решил для упрощения делать инверсию флага переноса C один раз ПЕРЕД вычитанием с
заёмом - там это наиболее критично для арифметики. В остальных случаях это совершенно незатратно
учитывается программно. Да, это создаёт впечатление, что SKIP C(NC) работают с точностью до
наоборот, но это только впечатление, программу не удлинняет ни на один байт.
В нищебродских конструкциях принцип такой: что можно просто решить программно - решаем программно.

Теперь немного о том, почему этот проект, как он есть, нет возможности развести под готовую
плату: в нём в четырёх местах введены формирователи короткого импульса на цифровой задержке.
Вот, как на рисунке ниже:

4_Bit_CPU_Buf.gif

Естественно, предполагалось, что это будут RC-цепочки в железе. Их надо подобрать будет.
И только после этого делать разводку.

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

Но сам я предполагаю воплотить этот проект в ПЛИС, поэтому проверил формирователи короткого импульса
без RC-цепей по следующей схеме:

4_Bit_CPU_DEL.gif

Гуру по ПЛИС будут ругаться, но решение найдено на форумах по ПЛИС, и в ПЛИС оно работает!

В приложении - последний вариант проекта "так как есть" со всеми актуальными исправлениями.
Поскольку дальше я начал изменять схемотехнику в расчете на реализацию в ПЛИС.

4_Bit_CPU2016.zip

[Lavr]

Ну и поскольку мне совершенно неизвестно было, поместится этот проект в ПЛИС, или не поместится,
я решил проверять его в ПЛИС по отдельным блокам, чтобы удостовериться в итоге, что полезет в ПЛИС,
а что придётся оставить снаружи.

И начал я с самого критичного узла - АЛУ - поскольку в нём присутствует диодный дешифратор, для
схемотехники ПЛИС совершенно неприемлемый, но весьма компактный для "нищебродской рассыпухи", а
также есть элементы формирования коротких импульсов, схемотехника которых на ПЛИС проверена.

В общем вынес я АЛУ в отдельный узел, совершенно ничего более принципиально не изменяя.

4_Bit_CPU2017_3.gif

И пришел я к выводу, что этот вариант удачен с точки зрения смоделировать на этом процессоре
какую-либо полезную конструкцию: появилось место на листе проекта и стал отчетливо виден
узел интерфейса SPI к контроллеру LCD Nokia-3310, который не входит в схему CPU, а реализован
как порты ввода-вывода, адресуемые инструкциями IN, OUT.
В силу особенностей растактовки этого процессора, интерфейс SPI оказался весьма прост, к тому
же он некритичен к частоте передачи, поэтому будет работать при любой тактовой частоте CPU.

Я решил этот вариант проекта тоже здесь выложить, поскольку он компактен и очень удобен для
экспериментов с этим 4-битным CPU в Proteus.

4_Bit_CPU2017.zip

P.S. Файлы проекта защищены от записи, и всякие строгие надписи там имеются, потому как у меня -
это последний эталонный вариант оригинального проекта, который заведомо рабочий, и к которому
можно откатить в случае неудачных изменений.

[tihsasha1967]

Интересный проект. С удовольствием в пошаге смотрел работу. Обучать школьников как работает CPU было бы самое то. В железе бы собрал, но не повесишь же светодиоды на всё. В протеусе видно все сигналы.

[Lavr]

Ну и последнее на сегодня - предновогодний бонус: 4-Bit-CPU-Assembler!

Я его начал было писать сразу как заработал первый удачный вариант проекта 4-Bit-CPU, благо был
у меня собственный довольно удачный шаблон исходного кода от другого проекта.

По пути захотелось внести в код разные изменения с целью улучшения.

Но параллельно я работал и над схемой 4-Bit-CPU в ПЛИС и больше всего мне хотелось реализовать-
таки полноценные CALL и RET, поскольку в ПЛИС "нищебродскость" уже менее важна.
В итоге полноценные CALL и RET у меня получились, но это повлияло как на схемотехнику, так и
на систему команд.

В итоге CALL занял код инструкции HLT (70H).
HLT предполагается теперь исполнять как в 6502:

Code: Select all

METKA:
     JMP METKA

В силу внесенных в схему изменений код FETCH (00H), используемый ранее как NOP, исполнять NOP
без усложнения схемы более не смог, поэтому код 00H из системы команд исключен, а в качестве
NOP используется инструкция SKIP 0000b (A0H), которая и так ничего не делала, работая как NOP.

Для обратной совместимости инструкция возврата по фиксированному адресу RST N поддерживается.
Хотя на её месте сейчас безусловный RET, но совместимости это не мешает.

Старые инструкции NOP и HLT можно ввести в код через оператор DB:

Code: Select all

   DB  00H; NOP
   DB  70H; HLT

Ассемблер облегчает привязку к фиксированным точкам возврата, если такая привязка важна:
Делается это посредством многократного объявления ORG ADDR (как в 6502) и инструкции DF,
указывающей байт заполнения до следующего ORG ADDR.
DF byte (Define Fill byte – определить байт заполнения, по умолчанию 0FFH)

Code: Select all

Пример:
   ORG 0
   DF  00H;  определим байт заполнения
   MVA 00H;  заносим в А - 0;
   JSR SUB1; вызов подпрограммы: SUB1
   ...

   ORG 100H
   OUT $1 ;  сюда вернемся, и выведем А в порт 1
   LDA R15;  считали счетчик-указатель в А
...

SUB1:
   IN 1  ;   читаем порт 1 в А;
   OUT 0 ;   выведем А на индикатор 0.
   RST 1 ;   возврат из подпрограммы на адрес 100H.

пустое пространство между JSR SUB1 и адресом 100H будет заполнено кодом 00H.

Ассемблер также снабжен полноценной системой помощи, где все основные моменты программирования
4-Bit-CPU подробно рассмотрены.
В комплекте с 4-Bit-CPU-ассемблером прилагается файл помощи, утилита редактирования ПЗУ микро-
команд, ассемблерный код примера, используемого в демонстрации проекта, ну и я добавил код,
который привел тут выше коллега tihsasha1967 :

Code: Select all

   ORG 000H
MET0:
   MVA  01   ;  A=1.
   DCR       ;  A=0.  Тут СF не должен установиться. Но  _CF_  pin2U13='1'
   SKIP NC   ; пропуск 2-х байт, если нет паритета. Реально тут его нет.
   JMP  MET7 ; безусловный переход на 007h.
   DB 00H ;NOP ; Мы попали сюда. Хотя должны были эти 2 байта пропустить.
   DB 00H ;NOP
MET7:
   DCR       ;  A=0Fh,  тут СF должен установиться. Но  _CF_  pin2U13='0'
   SKIP C    ; пропуск 2-х байт, если паритет. Реально он тут есть.
   JMP  MET0 ; безусловный переход на 000h.   Мы сюда попали, хотя не должны были.
   DB   70H; HLT;
   END

4_Bit_CPU_ASM.gif

Ассемблер и сопутствующие файлы тестировались под Windows 98, Windows XP, 7, 10.
Старшие версии могут быть недовольны, что в коде нет подписей и сертификатов, ну нет у меня их!

4-BIT-ASSM.zip

С наступающим Новым 2019 Годом всех!
Желаю удачи в Новом Году!!!

[Lavr]

Команду DCR АЛУ выполняет как A - 1 или как A + (/1 + 1) = A + Fh.
Отсюда и получается: 1 - 1 = 1 + Fh = 10h - возникает перенос C.
Возможно, следует инвертировать флаг переноса в последнем такте операции DCR.

Нашел документацию свою за 2015 год, когда я АЛУ конструировал:

ALU_Serial.gif

В принципе, ввести инверсию флага переноса после операций вычитания не так уж и накладно
аппаратно получается. У меня как раз остался незадействованным один элемент управляемого
инвертора XOR - DD1.4.
Подумаю над этим вопросом...

[Lavr]

А куда столько диодов по низу?

А это же диодный ДЕШИФРАТОР КОДОВ ОПЕРАЦИЙ АЛУ!

АЛУ - в нём присутствует диодный дешифратор, для схемотехники ПЛИС совершенно неприемлемый,
но весьма компактный для "нищебродской рассыпухи", ...

В общем, если заменять диодный дешифратор логикой, а он, собственно, выполняет функцию многовходовых
"ИЛИ" для сигналов низкого уровня, то распухает схема АЛУ весьма заметно...

ALU_CPLD.gif

Поскольку 8...9-входовые логические элементы приходится набирать из нескольких вентилей,
согласно законам Булевой алгебры.
Не знаю, упростится ли это в ПЛИС, но пока замена диодов вылилась в такую схему.

Можно было бы это и не показывать, но, заменяя диодный дешифратор, нашел я две ошибки,
которые нетрудно исправить в существующих проектах вот так:

ALU_ERR.gif

Операции ROR и ROL (вращения ниббла вправо и влево) лучше выполнять через функцию
АЛУ "ИЛИ" (OR), в противном случае, как было это сделано ранее, при сдвиге через сумматор
на сдвиги влияет флаг переноса C предыдущей операции.

Можно, конечно, добавить еще 2 диода, и "давить" флаг переноса C на время операций ROR
и ROL, но я подумал, что переключить их выполнение на функцию "ИЛИ" (OR) - проще.

[Lavr]

ну просто видимо при сложении C должен быть прямой флаг, а при вычитании - инверсный

P.S. вот тут устами самого интела говорится, что после вычитания флаг инвертируется (стр.46 в PDF или 2-8 на бумаге):
http://www.tramm.li/i8080/Intel%208080-8085%20Assembly%20Language%20Programming%201977%20Intel.pdf

This is because the processors complement the carry flag at the end of a subtract operation so that it can be used as a 'borrow' flag in multibyte subtractions

Действительно...

Однако если такие операции проводятся микропроцессорами i8080 или i8085, флаг переноса будет СБРОШЕН в конце вычитания. Это происходит потому, что микропроцессоры инвертируют флаг переноса в конце операции вычитания, так чтобы он мог быть использован в дальнейшем в качестве флага «заёма» при многобайтном вычитании.

Опять я споткнулся об эти флаги, программируя 6502...
Оказывается, есть просто разные подходы к интерпретации флага переноса C: от Intel и от MOS Technology

CMP.png

Some architectures, namely MOS 6502 and all ARM CPUs, use "true carry" subtraction implementation that Carry flag from PSW is not inverted before and after subtraction, so, C = 1 means no borrow and C = 0 means borrow.