4-bit Processor

[Shaos]

RDIR_BYTE - прочитать биты направления порта N в аккумулятор?
WDIR_BYTE - записать биты направления порта N из аккумулятора?
бит 1 это вход (высокоимпендансное состояние), а бит 0 это выход...

с другой стороны это всё можно решить внешней схемой и управлять направлениями через те же INP/OUT но с большими номерами

[Lavr]

с другой стороны это всё можно решить внешней схемой и управлять направлениями через те же INP/OUT но с большими номерами

Вот и я так подумал... портами же через те же INP/OUT можно и банки памяти коммутировать,
не вводя никаких дополнительных команд.

[Lavr]

Теперь есть желание "прикрутить" АЛУ.

Не прошло и 2 года, как я АЛУ в это поделие вделал!


Увеличить

АЛУ последовательного типа, но на скорость работы это никак не повлияет.
Что параллельное АЛУ, что последовательное в этой системе выполняют
операцию за 4 такта.

АЛУ реализует следующие операции:



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

Чего я ввиду нищебродскости решил не реализовывать:
CMP, RAL и RAR - сильно распирают скромную схемотехнику.
Но попробовать можно - кардинальных препятствий для этого нет.

Наиболее трудно мне дались CMC и SBB с учетом сохранения схемотехнической простоты.
Но в итоге довольно оригинально извернулся сделать инверсию флага переноса только
на первом сдвиге из 4-х...

Ввел несколько необычную команду SFA - Set Flags on A (выставить флаги по регистру А:
это по сути - операция сложения регистра А с нулём и установкой флагов.
Введена, чтобы быстро оценить значение, считанное из порта, не изменяя его.
В привычном нам 580ВМ80 это нетрудно сделать через ORA A, к примеру.
В этом процессоре такой возможности нет: все операции выполняются между
регистром-аккумулятором А и буферным регистром В, или между А и 0, А и 1.

Большую схему и весь проект пока не выкладываю - надо погонять на ошибки.
И САМОЕ ГЛАВНОЕ - Я-ТАКИ СОКРАТИЛ ОДНУ БИС СТАТИЧЕСКОГО ОЗУ!!!

Содержимое ПЗУ микрокоманд кардинально изменилось, но мой бинарный редактор
мне очень в этом помог. Работать было удобно, ошибок пока не обнаружилось!

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

[Lavr]

...надо погонять на ошибки.

Что-то я впал в полный ступор на тестировании ниббловой операции SUB...
Получается у меня некоторая непонятная мне странность, которой раньше не замечал...

Ну мы все помним, что вычитание в АЛУ заменяется сложением с дополнением вычитаемого до единицы:

SUB:
A - B = A + (/B + 1)

А теперь рассмотрим простой пример:
A = 0Fh
B = 1h

Code: Select all

  1111b = А
 -0001b = В
------- эквивалентно
  1111b
 +1111b
-------
1<1110b

0Fh - 1h = 0Eh и флаг C = 1 - тут всё верно, так ведь?

но при вычитании флаг C = 1 - значит был заём,
а если был заём, то 1h > 0Fh !!! а ведь это не так!?

Вот я и не пойму два дня уже, либо где я затупил, либо - что я делаю не так?

[Shaos]

вот тут пишут, что этот бит надо просто отбрасывать:

https://courses.cs.vt.edu/csonline/NumberSystems/Lessons/SubtractionWithTwosComplement/index.html

возможно это инвертнутый бит переполнения...

P.S. да - вот тут так и пишут: http://www.math-only-math.com/subtraction-by-2s-complement.html

(i) At first, 2’s complement of the subtrahend is found.
(ii) Then it is added to the minuend.
(iii) If the final carry over of the sum is 1, it is dropped and the result is positive.
(iv) If there is no carry over, the two’s complement of the sum will be the result and it is negative.

[Lavr]

вот тут пишут, что этот бит надо просто отбрасывать:

Тоже уже так думал... Но если я работаю с 2-мя нибблами, составляющими байт,
и если отбросить этот бит - получается вроде как некоторая брехня...
Если делать ту же операцию с байтами, то:
0Fh + 0Fh = 1Eh, как же его отбросить, ведь при работе с байтом, я должен
вычесть потом старшие нибблы байта, но уже инструкцией SBB - вычитание
с учетом заема... или я опять где-то затупил?


P.S. У меня что-то такое подозрение, что "собака порылась" здесь вот где:
считать ли ниббл беззнаковым или нибблом со знаком... Хотя ниббл со знаком -
звучит странно, но я же ввёл флаг Sign...

[Shaos]

ну просто видимо при сложении 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

[Lavr]

...устами самого интела говорится, что после вычитания флаг инвертируется

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

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

Спасибо за подсказку - не знал...
А я как раз и проверял операции вычитания через эмулятор 580ВМ80 "Специалиста"...

SBB_8080.gif

Смотрю - а результат-то не сходится с моим АЦП! Подправлю...

[Lavr]

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

Оказывается, не я первый такому поведению АЛУ удивился - в принципе-то оно правильное:
https://en.wikipedia.org/wiki/Carry_flag

For subtractive operations, two (opposite) conventions are employed as most machines set the carry flag on borrow while some machines (such as the 6502 and the PIC) instead reset the carry flag on borrow (and vice versa).

А я помню, когда PIC-ами занимался, в мануалах обращают на это внимание, но я с этим тогда как-то практически не столкнулся...

[Shaos]

А мне помнится мы это уже обсуждали применительно к 6502...


P.S. Вспомнил - недообсуждали, т.к. я потом сам додумал применительно к своему процу
В случае нашего старого-доброго 8080:
A-B-c это тоже самое как A+/B+1-c или A+/B+/c
В случае же прямолинейного использование заёма как инверснутого переноса (6502) будет так:
A-B-/c = A+/B+1-/c = A+/B+c

[Lavr]

Просто получается интересная затея... я инверсию флага С уже реализовал аппаратно - нужно для SBB и CMC.

И вот эта неожиданная особенность вычитания позволила бы всю эту аппаратную часть сократить вместе с
инструкцией CMC - ну чисто из нищебродских соображений. Поскольку есть еще инструкции STC и CLC.

Надо подумать...

Я тут пока воплотил в микрокод и "железо" полноценный JMP ADDR, где ADDR - полный 12-битный адрес!
И умудрился сделать это практически за ОДИН ЦИКЛ! Причем аппаратно - очень просто...

Сейчас вот раздумываю, нужен ли этому нищебродскому 4-битнику CALL ADDR, при глубине стека -
1 адрес возврата, который будет стОить аппаратно - 3 корпуса 555ИР16.


P.S. Я просто пока делал полноценный JMP ADDR (а ведь CALL ADDR отличается всего на 1 импульс! ),
так вот, я призадумался над словами автора Nibbler-а:

При использовании таблиц переходов и специальных ячеек памяти, в программах Нибблера можно реализовать простой механизм вызова / возврата, без реального аппаратного стека.

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

Мне стало казаться, что косвенный JMP полезнее CALL ADDR с одним возвратом...

[Shaos]

Мне стало казаться, что косвенный JMP полезнее CALL ADDR с одним возвратом...

Угу - похоже на то...

[Lavr]

И хотя я не сосчитал еще число корпусов, но на взгляд всё ещё бюджетно и - по-нищебродски...

Сосчитал число корпусов - их примерно 48 - и прикинул размер моим любимым методом:

Plat4cpu.jpg

Примерно 48 - реально должно быть меньше, кое-что лишнее в проекте для убыстрения
"чисто цифровых" вычислений.
Но видно, что весь 4-bit Processor пока на уровне размеров параллельного 4-bit АЛУ на NAND,
и не выходит за габариты большой макетки.

[Lavr]

Мне стало казаться, что косвенный JMP полезнее CALL ADDR с одним возвратом...

Угу - похоже на то...

Да - CALL ADDR в 4-битнике делать не буду: присмотрелся внимательно - это требует
больше микросхем, чем 3 регистра с z-состоянием выхода. И самое неприятное в плане
нищебродства - нужны еще минимум как 2 шинных формирователя. Это портит всё нищебродство...

На том "железе", которое уже есть реализовал немного кривоватый косвенный JMP:
JMI SEG,ADR,REG - сегмент и старший ниббл РС указываются напрямую, а
младший ниббл РС берется из указанного регистра общего назначения.
Это дает возможность косвенно передать управление на 16 ячеек подряд.
Немного, но без аппаратного усложнения - хоть так...

Ввел некий аналог рестарта по типу RST N: только он у меня передает управление на начало
одного из 16 сегментов по 256 байт.
Т.е. RST SEG = JMP SEG,00h,00h.

Думаю, надо ввести еще RST REGB - идея та же самая, но номер сегмента берется не
из команды, а из регистра В. Немного гибкости должно придать...


P.S. Вот еще задумался - нужна ли процессору инструкция HLT с выходом только по RESET ?

[Lavr]

Вот такая система команд у меня утряслась в итоге на имеющемся "железе":

4BITinstr96.gif

Я отказался от CALL ADDR с одноранговым стеком - усложняет схему ~ на 5 корпусов.
Отказался от CMP - тоже зело усложняет схему.
Для нищебродского 4-битника стыдно быть сложным!

Все команды работают, проверены на простеньких примерах. Теперь надо бы что-то спрограммировать
посерьезнее... Теннис ?

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

Ну и, по возможности, постараюсь максимально привести всю схему к базису: 155ЛА3, 155ЛН1.


P.S. Ну и сама схема на данный момент:


Увеличить