Gigatron (компьютер на рассыпухе)

[Shaos]

Не - мой RASM тупой как валенок - никаких тебе квадратных скобок или плюсиков

[Lavr]

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

К примеру, если упорядочить, то увидим:

dup.gif

И таких участков в таблице кодов прилично...

Значит LDA $0P трактуем при компиляции как 00h, а если вдруг понадобится другой код,
то вставляем его как DB 0CH; к примеру?

[Lavr]

Gigatron в принципе нетрудно повторить в Proteus, ...

В общем это я потихонечку и делаю...

Но тормознулся со схемотехникой АЛУ на мультиплексорах...
На мой взгляд в схеме АЛУ есть ошибка, приводящая к его неработоспособности.

 Схемотехника АЛУ на мультиплексорах

00061.gif

Приведу также краткое описание принципа работы этого АЛУ от автора:

ALU.gif

Ошибка в схеме на мой взгляд состоит в том, что в нижней части схемы все выводы 7 мультиплексоров
74НСТ153 должны поступить на входы А сумматора, а все выводы 9 мультиплексоров должны поступить
на входы В сумматора. Тогда схема будет работать согласно приведенному описанию.
На приведенном выше оригинале схемы у двух мультиплексоров подключение к сумматору выводов 9 и 7
перепутано.

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

[Lavr]

Правильная схема АЛУ на мультиплексорах, на мой взгляд, должна быть следующая:

 Исправленная схема АЛУ на мультиплексорах

ALU2.gif

Правда, при этом сигналы управления AR0:3 инверсные, но они соответствуют таблице,
описывающей принцип работы АЛУ:
AR0 - это сигнал Cin. По таблице при инструкции LD сигнал Cin = 0.
Также при этом один из мультиплексоров выключен (= 0), второй - повторяет входы Bus.

На выходе сумматора и ALU получается А = 0 + Bus = Bus, не зависимо от Ain.

Надо будет проверить, как при этом ведут себя другие операции ALU...

[Lavr]

Да, похоже, что исправленная схема АЛУ на мультиплексорах работает верно...

Для управления АЛУ на мультиплексорах необходимы следующие сигналы AR0:3 и AL :

00AR_TAB.gif

Также показано, как формируются столбцы таблицы для операций LD и AND.

Аппаратно сигналы данной таблицы в схеме устройства управления Gigatron-а формирует вот такой
шифратор с диодной матрицей:

Coder.gif

Принцип его построения следующий: там, где в таблице 1, на схеме должен быть диод.
На приведенной выше оригинальной схеме несколько диодов придётся поменять местами, чтобы было
соответствие таблице.

Первоначально я предполагал ошибку в инверсии, но тут подвела модель буфера 74хх240 в Proteus -
инверсия в ней ошибочно отсутствует...

Прилагаю также модель АЛУ на мультиплексорах в Proteus и надеюсь, что больше ошибок нет.

ALU_Gig.zip

[Lavr]

Shaos, кстати, посмотри, может быть в исходник твоего RASM (или как его там) удачно ляжет?

Не - мой RASM тупой как валенок - никаких тебе квадратных скобок или плюсиков

А если заменить мнемоники на похожие от i8080? Тогда получится?

Я тут читал один материал от автора, команду, где Х++, он сам назвал иначе: STIX, то есть,
STore & Increment X.
Можно и другие команды со скобками переименовать похожим образом, обходились же в ассемблере
i8080 без скобок!

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

[Lavr]

Проект практически заработал, ...

Вот так проект на данный момент выглядит:

 Gigatron в Proteus

GIG_10.gif

Свободный угол оставлен под LCD индикатор типа LM016L (2 строки по 16 символов),
но пока я с этим тормознулся, поскольку с ним довольно точно надо временнЫе интервалы
в протоколе инициализации выдержать, а я в данный момент запускаю проект либо в
пошаговом режиме, либо на низкой частоте 100 Гц, чтобы успевать видеть процесс работы.
Т.е. все интервалы у меня заведомо больше, чем это необходимо...


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

GigSchematics.zip

[Shaos]

Shaos, кстати, посмотри, может быть в исходник твоего RASM (или как его там) удачно ляжет?

Не - мой RASM тупой как валенок - никаких тебе квадратных скобок или плюсиков

А если заменить мнемоники на похожие от i8080? Тогда получится?

Я тут читал один материал от автора, команду, где Х++, он сам назвал иначе: STIX, то есть,
STore & Increment X.
Можно и другие команды со скобками переименовать похожим образом, обходились же в ассемблере
i8080 без скобок!

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

Дык у них вроде ж был ассемблер, не?

[Lavr]

Shaos, кстати, посмотри, может быть в исходник твоего RASM (или как его там) удачно ляжет?

Не - мой RASM тупой как валенок - никаких тебе квадратных скобок или плюсиков

А если заменить мнемоники на похожие от i8080? Тогда получится?

Дык у них вроде ж был ассемблер, не?

Да там ассемблер, как пишут, "трое в одном флаконе". Неохота с ним заморачиваться...
Не хочу ничего плохого сказать про автора, но как-то сложно он всё замутил для довольно простой
железки. Если внимательно присмотреться, то это практически 8-битный Nibbler по идее.

Оригинальный ассемблерный код в ПЗУ там вобще на "питоне" собирают...

Ну в общем хотелось бы простенький ассемблер даже DOS-овский подошел бы.

Пока надумал сделать так - в ассемблере от i8080 писать программу Gigatron-а через DB XXh.
В WINHEX, на котором я сейчас пишу в кодах, раздвигать и вставлять в код неудобно...

[Lavr]

Урааааааа!
Модель Gigatron-а в Proteus с LCD-индикатором LM016L заработала!

TheGIG.gif

Вот вроде мелочь, а приятно! И самое приятное, что заработала не сразу...
Немного поупрямилась, от этого обычно результат приятен вдвойне!

Пока надумал сделать так - в ассемблере от i8080 писать программу Gigatron-а через DB XXh.

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

Как-то так этот процесс выглядел:

Code: Select all

;--------------------------------;
;   Gigatron + LCD_LM016L.ASM    ;
;          05.09.2020            ;
;                                ;
;  CLC = 100Hz, T = 0,01S = 10mS ;
;  .                             ;
; 0FFH - Фиктивный параметр...   ;
;--------------------------------;

;0123456789012345
;> The Gigatron <
;Press any key...

    ORG  0000H;
START:
    DB    08H, 00H;  LDA 00H
    DB    1AH, 0FFH; LD  AC,OUT - clear port
;-------------
    DB    0EH, 0FFH; NOP - Delay
    DB    0EH, 0FFH; NOP - 20 mS
    DB    0EH, 0FFH; NOP
;-------------
    DB    08H, 30H;  LDA 30H
    DB    1AH, 0FFH; LD  AC,OUT
    DB    0EH, 0FFH; NOP - pause
    DB    4CH, 04H;  ORA 04H = 0000.0100 STB UP
    DB    1AH, 0FFH; LD  AC,OUT
    DB    0EH, 0FFH; NOP - pause
    DB    2CH, 0FBH; ANI 0FBH = 11111011 STB DN
    DB    1AH, 0FFH; LD  AC,OUT
    DB    0EH, 0FFH; NOP - pause
;-------------
    DB    08H, 30H;  LDA 30H
    DB    1AH, 0FFH; LD  AC,OUT
    DB    0EH, 0FFH; NOP - pause
    DB    4CH, 04H;  ORA 04H = 0000.0100 STB UP
    DB    1AH, 0FFH; LD  AC,OUT
    DB    0EH, 0FFH; NOP - pause
    DB    2CH, 0FBH; ANI 0FBH = 11111011 STB DN
    DB    1AH, 0FFH; LD  AC,OUT
    DB    0EH, 0FFH; NOP - pause
;-------------
    DB    0EH, 0FFH; NOP - Delay
    DB    0EH, 0FFH; NOP - 20 mS
    DB    0EH, 0FFH; NOP
    DB    0EH, 0FFH; NOP - Delay
    DB    0EH, 0FFH; NOP - 20 mS
    DB    0EH, 0FFH; NOP
;-------------
   ...

По RTF-файлу искал нужный мнемокод, записывал его в комментарий, а в DB XXh вставлял
код этого оператора.
После компиляции разбивал *.bin-файл на четные и нечетные байты для двух ПЗУ с помощью
утилиты romsplit.exe (отдельное спасибо - Шурику!)

Проект работает на частоте 100 Гц - под эту частоту ориентировочно подобраны интервалы
для LCD-индикатора LM016L, причем выбраны они заведомо большими.

Если кто захочет поднять частоту и допилить проект до работы с "дисплеем" следует
обратить внимание на следующее: Gigatron тактируется двумя фазами, причем вторая
фаза получается задержкой на конденсаторе.

00021.gif

Ёмкость конденсатора (и задержка фазы 2) зависит как от рабочей частоты, так и от
быстродействия примененных логических элементов.
В Proteus вместо конденсатора я поставил цифровую задержку, её величина подобрана
для частоты 100 Гц и микросхем серии 74LS.
Критерий подбора задержки следующий: в Gigatron данные всегда проходят через АЛУ,
и после АЛУ попадают в регистры или память в фазе 2, отсюда задержка должна быть
такой, чтобы в фазе 2 в регистр-аккумулятор четко записывалось значение на выходе
АЛУ, в противном случае задержку следует увеличить.
При выбранной задержке следует протестировать запись в микросхему ОЗУ - сбоев быть
не должно!

Ну и, как обычно - архив с проектом Proteus:

Gigatron.zip

В нём всё, что нужно, кроме компилятора ассемблера для i8080, его я давным-давно
выкладывал здесь на форуме в ветке Proteus DLL.

[Lavr]

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

А теперь выложу набор схем, которые я правил, и по которым собирал проект Gigatron-а в Proteus :

GIGSchems.zip

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

Кстати, именно поэтому я и применил в проекте серию 74LS - серия 74НСТ в моём устаревшем
Proteus-е довольно бедна...

[Lavr]

... а вот формировать видео-сигнал и паралельно делать что-либо полезное у тебя вряд-ли получится.

Так вот, когда читаешь интернет, представляется просто какое-то чюдо!
Не, ну надо же! - Программная генерация VGA-видеосигнала процессором на 6.25 МГц!
Это в то время, как у "Специалиста" была аппаратная генерация TV-видеосигнала 384х256
при частоте обновления пикселей 8 МГц!

А когда разберёшься и внимательно присмотришься, то чюда-то никакого и нет...
Просто в схеме Gigatron-а реализован зачаточный ПДП в командах типа:
LD [Y,X++],OUT
это пересылка байта из памяти (ОЗУ) непосредственно в порт вывода с аппаратным
инкрементом адреса!

А я еще смотрю и думаю, почему ж нет аналогичной команды для чтения массива в аккумулятор?
А вот нет её! Только под формирование видеосигнала и стробирования звука команда расточена!

[Lavr]

Но это всё не столь уж принципиально, гораздо интереснее другое: аппаратного стека в Gigatron-е
точно нет. А вот как его эмулируют чисто программно?

В PDP-8, как я помню, это не было слишком сложной программной затеей...

[Lavr]

Просто в схеме Gigatron-а реализован зачаточный ПДП в командах типа:
LD [Y,X++],OUT
это пересылка байта из памяти (ОЗУ) непосредственно в порт вывода с аппаратным
инкрементом адреса!

А я еще смотрю и думаю, почему ж нет аналогичной команды для чтения массива в аккумулятор?
А вот нет её! Только под формирование видеосигнала и стробирования звука команда расточена!

Объясняю для очень внимательных: для X++ в схеме реализована аппаратная поддержка:

0007.gif

Регистр А - аппаратно просто регистр, регистр Х - два счетчика с параллельной загрузкой.
То есть INR A - это ADDA 1, а вот INR Х - это Х++ - реализован аппаратно.
При этом LD [Y,X++],OUT - существует, а LD [Y,X++],А - не существует, хотя это
аппаратно ничуть не сложно, отсюда и был этот вывод:

Только под формирование видеосигнала и стробирования звука команда расточена!

А уж сомневался в этом кто-то или нет - это личное дело каждого...

[Lavr]

гораздо интереснее другое: аппаратного стека в Gigatron-е
точно нет. А вот как его эмулируют чисто программно?

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

Вот, к примеру, что пишет по этому поводу некто H.G.Muller, который хочет заставить Gigatron
играть в шахматы:
The Gigatron project - Page 2 - TalkChess.com

I wonder how one does function calls; there's no stack so one would have to emulate it manually
which would be costly/tricky (thinking of how to compute return address, managing stack)

Indeed. The Gigatron has the quirk that it always executes the instruction following a branch, even if the branch is taken. (A result of the instruction-fetch pipelining.) When jumping to subroutines, I use this instruction to load the return address in the accumulator. The subroutine can then start saving that, in a fixed place when it is not called recursively, and on a software stack it maintains itself when it is. This assumes the subroutine is in the same memory page as its caller, or at least knows in which page the caller must be. This is usually not too much of a problem.

Идея-то и без него понятна: надо как-то самим программно сохранять в памяти адрес возврата,
а по возврату из подпрограммы также самим считать эти данные в Y и A, после чего выполнить инструкцию JMP Y,AC.
Но в кодах Gigatron-а я пока всю эту процедуру плохо себе представляю...