nedoPC.org

Community of electronics hobbyists established in 2002

...
Atom Feed | View unanswered posts | View active topics It is currently 21 Oct 2020 00:59



Reply to topic  [ 86 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6
Gigatron (компьютер на рассыпухе) 
Author Message
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Lavr wrote:
...в процессе разбора кода пришла мне в голову очень заманчивая идея,
о которой расскажу я далее...

А идея, собственно, касается того, что в Gigatron-е при его оригинальной схемотехнике довольно
просто можно реализовать аппаратный стек!

Я тут ранее писал:
Lavr wrote:
...гораздо интереснее другое: аппаратного стека в Gigatron-е точно нет.
А вот как его эмулируют чисто программно?
В PDP-8, как я помню, это не было слишком сложной программной затеей...

И я эту идею проверил, она работает, вот только код сохранения адреса в программный стек и
извлечения адреса из него довольно монструозный по объёму
... :-?
Ситуацию не спасает даже то, что код выхода из подпрограммы всегда одинаков, и на него можно
переходить из всех подпрограмм через JMP Y,$OP на его адрес.

Код входа в подпрограмму с сохранением адреса возврата в программный стек все равно довольно
объёмный, что зело увеличит объём программы и нивелирует удобство стека... :osad:

Дело в том, что PDP-8 - 12-разрядный компьютер, и его 12-разрядный адрес легко сохранять в
12-разрядную же память одной операцией, как, собственно, и считывать адрес из памяти.

Gigatron же - 8-разрядный компьютер с 16-разрядной шиной адреса, поэтому сохранять адрес возврата
приходится по меньшей мере двумя операциями, а если манипулировать указателем стека программно,
то операций, естественно, больше.

Но у Gigatron-а есть некоторые схемотехнические "родимые пятна", которые могут помочь работу
со стеком весьма упростить! :roll:

Если взглянуть на схемотехнику мультиплексоров адреса:

 Схема мультиплексоров адреса
Attachment:
0005.gif
0005.gif [ 17.19 KiB | Viewed 393 times ]

Можно увидеть, что в младший байт адреса подаётся содержимое регистра Х или непосредственно
операнда $OP. В старший же байт адреса подаётся содержимое регистра Y или просто 0,
при этом мультиплексор старшей части адреса просто аппаратно выключается, а на входы мультиплексора
поданы логические уровни "1" просто, чтобы входы не потребляли ток.
Так обеспечивается короткий доступ в Zero Page из любого места программы.

Доступные режимы адресации при такой схемотехнике следующие: [0,$OP], [0,X], [Y,$OP] [Y,X].
Но у Gigatron-а есть аппаратная фишка автоинкремента X -> X++, мы её ранее разбирали:
Image
Суть её в том, что аппаратно регистром X является счётчик типа 74161, но этот счетчик вполне
можно заменить на аналог типа 155ИЕ7, который работает как на увеличение, так и на декремент.

Тогда кроме режима автоинкремента X -> X++ появится и возможность автодекремента X -> X--,
что идеально с точки зрения указателя стека! :kruto:

Остаётся лишь доработать мультиплексор старшего байта адреса: подать на его неиспользуемые
сейчас входы комбинацию 0000.0001b и изменить коммутацию этого мультиплексора так, чтобы были
возможны режимы [01,Х++] и [01,Х--].

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

То есть, если сейчас я для безопасности пишу:
Code:
    JMP  Y,$OP
    NOP

То с аппаратным стеком вместо бесполезной инструкции NOP будет инструкция сохранения в стек
младшей части адреса, которая в Gigatron-е всегда на 1 больше.

Конечно же на вход ОЗУ надо будет предусмотреть шинные драйверы от младшей и старшей половин РС,
и также придётся несколько усложнить декодер команды - Control Unit, но мне кажется, что аппаратный
стек
этого стОит, если учесть и тот факт, что у Gigatron-а есть как повторяющиеся, так и вовсе
неиспользуемые команды.

_________________
iLavr


26 Sep 2020 06:14
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Lavr wrote:
...у Gigatron-а есть как повторяющиеся, так и вовсе
неиспользуемые команды.

Посмотрел я с этой точки зрения на неиспользуемые команды:
Attachment:
undef.gif
undef.gif [ 15.19 KiB | Viewed 373 times ]

В общем-то, судя по коду, отловить их и интерпретировать иначе весьма нетрудно.
Да и количество самих команд весьма приличное.

Тем более, что относятся они к группе ST = STORE (сохранить), значит половину
функционала стека уже аппаратно реализуют.
Осталось продумать вторую половину этой схемотехники...

_________________
iLavr


26 Sep 2020 13:10
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Lavr wrote:
И главная неприятность неожиданно всплыла совершенно в другом месте. :x
Я уже в третий раз сталкиваюсь с этим: модель SRAM 62256 Proteus-a при несколько
нестандартном включении начинает глючить. И глюк заключается в том, что после
операции чтения она задерживает снятие данных с шины, что далее приводит к конфликту.

Ясное дело, что и настоящие SRAM поступают примерно так же, ...
Пришлось "пошаманить с бубном". С точки зрения схемотехники зашаманить не получилось,
хотя в схеме Nibbler-a похожая проблема решилась небольшой задержкой одного из сигналов.
Здесь такого не получилось, а усложнять схему оригинального Gigatron-a я тоже не хотел.

Проблема решилась весьма странным образом: если после чтения сразу же сделать запись
по тому же адресу - глюк модели SRAM 62256 далее не мешает...
Так что в ассемблерном тексте везде вот такое:
Code:
    DB    01H, 7FH;  LDA [7FH] - читаем  указатель "стека"
    DB    0C2H,7FH;  STA [7FH] - сохраняем

это просто "шаманство с бубном"... :-?

Попробовал я ликвидировать это "шаманство с бубном", но оказалось, что не так это просто... :-?

Действительно, реальные БИС SRAM удерживают данных на шине в операции чтения некоторое время
после снятия управляющих сигналов.
Вот, к примеру, диаграмма цикла чтения для SRAM HM62256 из её даташита:
Attachment:
SRAM62256.gif
SRAM62256.gif [ 9.47 KiB | Viewed 313 times ]

Понятно, что Proteus пытается эту диаграмму в меру сил симулировать, в том числе и "хвост" данных.
С точки зрения корректности эмуляции SRAM - это однозначно верно, и время "хвоста" не может быть = 0.

В большинстве процессоров в следующем такте Next t никто на шину не лезет, процессор
обрабатывает данные и "хвост" ничему не мешает.

Gigatron же воплощает RISC архитектуру, поэтому в следующем такте Next t на шину выдаёт свои
данные один из источников, что приводит к конфликту, поскольку даже операция NOP у Gigatron-а -
это либо MOV A,A, либо ORA A, то есть операция-то пустая, бестолковая, но транзакции данных на
шине проходят. :osad:

Получается, что "шаманство с бубном":
Code:
    DB    01H, 7FH;  LDA [7FH] - читаем  указатель "стека"
    DB    0C2H,7FH;  STA [7FH] - сохраняем

оказалось самым верным и незатратным решением: на шину выдаётся то, что и так на ней "залипло",
конфликта не происходит... :wink:

Аппаратно устранить эту ситуацию можно двумя затратными способами: первый - укоротить цикл чтения
разными RC-цепями, чтобы он влезал точно в такт Gigatron-а, второй - отделить выход SRAM от
общей шины с помощью шинных формирователей, то есть: не пускать "хвост" на общую шину
по завершению такта чтения.
И то и другое требует аппаратного усложнения... :-?

_________________
iLavr


06 Oct 2020 00:33
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Lavr wrote:
Аппаратно устранить эту ситуацию можно двумя затратными способами: первый - укоротить цикл чтения
разными RC-цепями, чтобы он влезал точно в такт Gigatron-а, второй - отделить выход SRAM от
общей шины с помощью шинных формирователей, то есть: не пускать "хвост" на общую шину
по завершению такта чтения.
И то и другое требует аппаратного усложнения... :-?

Сработали, как ни странно, оба способа: сначала добавил шинные формирователи, но показалось,
что глюк кое-где проскакивает, после этого укоротил цикл чтения до 3/4 от оригинала, глюк исчез,
но посмотрел сигналы - от импульсов /WR пробивает иголоки на /OE ...
Attachment:
Glich.gif
Glich.gif [ 2.17 KiB | Viewed 301 times ]

Возможно, если их убрать, шинные формирователи будут излишни...

P.S. Убрал, шинные формирователи, оставил лишь укороченный цикл чтения:
Attachment:
Glich2.gif
Glich2.gif [ 2.09 KiB | Viewed 299 times ]

Глюка чтения из памяти нет, хотя иголки по /OE остались. Пусть пока так будет.

_________________
iLavr


06 Oct 2020 05:25
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Lavr wrote:
... идея, собственно, касается того, что в Gigatron-е при его оригинальной схемотехнике довольно
просто можно реализовать аппаратный стек!

В общем-то аппаратный недо-стек Gigatron-а практически процентов так на 80 близок к завершению:
Attachment:
GiG_SP.gif
GiG_SP.gif [ 23.58 KiB | Viewed 299 times ]

В стековую область 0100H...01FFH четко заносится адрес возврата, сам стек сохраняется в Zero Page.
Глюк, связанный с чтением памяти, я устранил, значит считываться адрес возврата должен без проблем.
Осталось кое-что по мелочевке подчистить и будет Gigatron с аппаратным недо-стеком...

Недо-стек - поскольку отдельный регистр стека я вводить не стал, его функции там, где это необходимо,
выполняет регистр Х, содержимое которого сохраняется в Zero Page.

_________________
iLavr


06 Oct 2020 06:03
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
А кто-нибуть встречал динамичные не-текстовые игрушки на 2-строчном 16-символьном LCD-дисплее?

В LCD можно свои шрифты произвольные загружать и воспроизводить подобие анимации...

В Proteus есть такой пример:
Attachment:
LCD-GAME.gif
LCD-GAME.gif [ 8.99 KiB | Viewed 252 times ]

Рот с палкой, которого они называют "Пэкман" съедает текстовую строку. :wink:
Attachment:
4_Bit_LCD Driver.zip [19.33 KiB]
Downloaded 11 times


Я погуглил и нашел одну игрушку такого плана - на Ардуино:
Attachment:
25940574.jpg
25940574.jpg [ 70.16 KiB | Viewed 252 times ]

Игра называется "Hill Run 2". 8)
Quote:
Задача играющего - перепрыгивать через горы, а также приседать, когда мимо пролетают вороны. По горизонтали персонаж игры перемещается автоматически, игрок управляет лишь его перемещением по вертикали, поэтому кнопок всего две.
https://create.arduino.cc/projecthub/PunkyMunky64/lcd-hill-run-v2-runner-game-1b0523

Но что-то мне играшка не понравилась... Может кому встречались другие?

_________________
iLavr


08 Oct 2020 17:04
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Lavr wrote:
... идея, собственно, касается того, что в Gigatron-е при его оригинальной схемотехнике довольно
просто можно реализовать аппаратный стек!

Закончил я аппаратный недо-стек Gigatron-а, на первый взгляд - всё работает корректно,
но надо будет протестировать всё на каком-то реальном примере...

Пока делал недо-стек, просто забодал меня вот этот тупенький узел Gigatron-а: :twisted:

Image

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

Ясно, что на фиксированной тактовой частоте - это простой способ создать двухфазную последовательность
тактовых импульсов, и в Gigatron-е довольно жесткая привязка импульсов CLK1 и CLK2:
По фронту CLK1 - начинается такт и на шину выдаётся состояние одного из источников сигнала.
По фронту CLK2 - результат операции записывается в один из регистров.
За время между фронтами CLK1 - CLK2 должно успеть сработать самодельное АЛУ.
И, наконец, по спаду CLK1 - происходит запись в память, а чтение из памяти, как я ранее
выяснил всегда надо закончить до конца такта, воизбежание конфликта на шине.

В общем, выкинул я этот сомнительный узелок, формирующий CLK1 - CLK2 и приделал
нормальный формирователь двухфазной последовательности тактовых импульсов, где
все сигналы синхронно привязаны друг к другу:
Attachment:
Sync.gif
Sync.gif [ 3.73 KiB | Viewed 209 times ]

Частоту тактового генератора, правда, пришлось увеличить вдвое, но зато узел позволяет теперь
формировать из следующего набора частот:
Attachment:
GEN.gif
GEN.gif [ 5.69 KiB | Viewed 209 times ]

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

_________________
iLavr


10 Oct 2020 12:43
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Lavr wrote:
Закончил я аппаратный недо-стек Gigatron-а, на первый взгляд - всё работает корректно,
но надо будет протестировать всё на каком-то реальном примере...
Lavr wrote:
Посмотрел я с этой точки зрения на неиспользуемые команды:
Image

Переделал я эти команды аппаратно следующим образом, вторая группа:
Attachment:
Tab_0.gif
Tab_0.gif [ 3.59 KiB | Viewed 204 times ]

Это команды для сохранения РС в стек и сохранения самого временного указателя стека - Х в Zero Page.
Команда ST Y,[00,X] к стеку отношения не имеет, просто удобно в схемотехнику легла... :wink:

Из первой группы команд лишь две команды было сравнительно нетрудно переделать для извлечения
из стека адреса возврата:
Attachment:
Tab_1.gif
Tab_1.gif [ 2.15 KiB | Viewed 204 times ]

Остальные команды - так и оставил неиспользуемыми...

Новая система команд и её аппаратная поддержка полностью совместимы с оригинальным Gigatron-ом,
но с помощью новых команд осуществить вызов подпрограммы и возврат из неё существенно проще,
нежели чем при чисто программной реализации стека возвратов:
Attachment:
Tab_3.gif
Tab_3.gif [ 17.41 KiB | Viewed 174 times ]

Пока заметен один небольшой недостаток этого решения, следующие команды:
Code:
     ST  PCH,[01,X++]; - сохраняем в стек старший адрес
;-------------------------------------------------------------------- граница сегмента
     JMP Y,55Н; - переход к подпрограмме

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

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

_________________
iLavr


10 Oct 2020 15:27
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Не стал я фиксить этот дефект - пусть будет фичей этого процессора. И у оригинального MOS 6502
похожие заморочки с пересечением границы сегмента были. :wink:

Здесь как ни крути, но в момент выполнения JMP программный счетчик никак не указывает на адрес
возврата, а указывает на команду после JMP, а её этот процессор в силу особенностей своей архитектуры
выполняет сразу же на адресе перехода, и лишь потом сам код по адресу перехода... :-?
Поэтому адрес возврата при возврате из подпрограммы приходится корректировать программно.

Если группа команд сохранения адреса возврата :
Code:
     ST  PCL,[01,X++]; - сохраняем в стек младший адрес
     JMP Y,55Н; - переход к подпрограмме
     ST  PCH,[01,X++]; - сохраняем в стек старший адрес
находится в одном сегменте, то стек вполне замечательно работает! :kruto:
Attachment:
GIG_SP.gif
GIG_SP.gif [ 23.48 KiB | Viewed 174 times ]

Собственно за такими мелочами должен следить компилятор ассемблера, ведь даже у х86 компилятор
отслеживает адреса коротких JMP, и предупреждает если JMPS out of range.

В архиве - проект модели Gigatron-а с аппаратным недо-стеком:
Attachment:
GIG_SP.zip [97.45 KiB]
Downloaded 9 times

Вызовов подпрограмм там достаточно, а игрушку псевдографическую я писать не стал (хотя в коде есть
попытка начать
), поскольку на эрзац-ассемблере делать это неудобно, а хобби предполагает, что задача
решается с удовольствием. :P

Чтобы не писать длинных простыней, как стек приделан аппаратно, прикладываю также документ,
где всё подробно написано:
Attachment:
GiG_hSP.zip [448.24 KiB]
Downloaded 7 times

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

P.S. На схеме видно, что кнопка "7" зашунтирована переключателем - это для режима пошаговой отладки.

P.P.S. А жалко вобще, что я поздно внимание обратил на Gigatron, его перерисовать бы заново, чтобы
получился нормальный недо-6502 без ненужных костыликов. Ресурс такой у Gigatron-а есть!

_________________
iLavr


11 Oct 2020 15:56
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Lavr wrote:
А жалко вобще, что я поздно внимание обратил на Gigatron, его перерисовать бы заново, чтобы
получился нормальный недо-6502 без ненужных костыликов. Ресурс такой у Gigatron-а есть!

Обдумываю возможность реконструировать Gigatron в недо-RISC-компьютер принстонской архитектуры,
чтобы была возможность исполнять его собственную систему команд из ОЗУ, а ПЗУ команд включить в карту
памяти в качестве Монитора, ну или BIOS.

В чем смысл этой затеи: на данный момент из 256 команд Gigatron-а по меньшей мере 138 не используют
операнд в качестве второго байта. Конечно, стОит учитывать частоту вызова команд в реальной программе,
но так или иначе значительный объём ПЗУ команд пустует, поскольку у 138 команд из 256 аргумент чисто
фиктивный.

_________________
iLavr


17 Oct 2020 08:52
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Lavr wrote:
Обдумываю возможность реконструировать Gigatron в недо-RISC-компьютер принстонской архитектуры,
чтобы была возможность исполнять его собственную систему команд из ОЗУ, а ПЗУ команд включить в карту
памяти в качестве Монитора, ну или BIOS.
В общем-то сама идея тут достаточно проста и понятна: если в ПЗУ команды и данные следуют друг за другом,
то в том случае, когда декодер командыControl Unit) обнаруживает код, которму необходимы данные,
то есть, двухбайтную команду, он должен перенаправить строб записи в регистр данных, а у регистра
команд
строб записи в этот момент заблокировать.

Честно говоря, это всё можно уложить в один такт, но есть одно усложняющее обстоятельство.
В существующей схемотехнике команда и данные появляются одновременно и за первую четверть такта должно
успеть сработать АЛУ
, поскольку после первой четверти такта происходит запись результата на выходе АЛУ
в один из регистров или аккумулятор. Этого не избежать - данные всегда проходят через АЛУ, даже если надо
всего лишь записать их в регистр или память.
Запись в память начинается с середины такта, так что временнЫе привязки в такте довольно жесткие.

Поэтому я решил ввести дополнительный такт для чтения данных в двухбайтной команде.
В этом случае диаграмма по тактам будет следующая: в начале такта код команды фиксируется в регистр команд,
программный счетчик РС при этом указывает уже на следующий байт в ПЗУ - следующая команда или данные
для текущей команды
.
Если декодер командыControl Unit) обнаружил код, которму необходимы данные (двухбайтную команду),
он блокирует импульсы записи в регистры и ОЗУ, и перенаправляет строб записи в регистр данных.
После того, как данное зафиксировано, выполняется обычный такт ЦПУ с этим данным и командой.

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

Схемотехнически получилось весьма просто:
Attachment:
SelDat.gif
SelDat.gif [ 17.81 KiB | Viewed 46 times ]
Первоначально на выход ПЗУ подключены оба регистра - команд и данных, но запись в них осуществляется через
мультиплексор, которым управляет дополнительный D-триггер U8:A, включенный как счетчик до двух.
Если ничего не подключить дополнительно, то работать эта схема будет так: четный байт записывается
в регистр команд, а нечетный - в регистр данных.
Эту логику корректирует детектор двухбайтного кода U7:A (code detector). Для простоты эксперимента принято, что
команды типа xxxx.xx11b - двухбайтные. Поэтому детектор двухбайтного кода запрещает переключаться счетчику
U8:A
для всех команд, кроме двухбайтных.

Поскольку команда типа xxxx.xx11b - каждая четвертая, на осциллограмме видно, что лишь каждый четвертый
импульс CLK1
перенаправляется в регистр данных и блокируется для регистра команд.
Attachment:
SelDiag.gif
SelDiag.gif [ 957 Bytes | Viewed 46 times ]

Если внимательно посмотреть проект:
Attachment:
SelDat.zip [20.24 KiB]
Downloaded 5 times

то можно увидеть откуда у данной схемы такая необычная фишка: выполнить команду после инструкции перехода JMP,
ту, что была прямо за ней по коду.
Дело в том, что счетчик типа 74LS161 - полностью синхронный, и когда выполняется команда JMP, на выходе ПЗУ
приготовлена уже
эта самая следующая команда. Команда JMP выставляет на входы счетчиков адрес перехода и
устанавливает разрещение параллельной записи, но счетчик 74LS161 - полностью синхронный, поэтому адрес
перехода
запишется в него только по фронту CLK1, но этот же фронт защелкнет в регистр команд тот байт, который
уже был на готове
, то есть байт, непосредственно следующий за командой JMP xxH.

Если применить счетчики типа 74LS193 (555ИЕ7), а я уже делал это в схеме для регистра Х, то этого эффекта
не будет - параллельная запись в счетчик типа 74LS193 - асинхронна, не зависит от тактовых сигналов и
имеет над ними преимущество.
Другое дело, что совершенно понятно, почему в оригинальной схеме применены счетчики типа 74LS161 - на высокой
тактовой частоте 6.25 МГц
все 4 счётчика РС переключаются строго одновременно, а счетчики типа 74LS193 - не
полностью синхронные
: при каскадировании имеют задержку на каждый корпус.
Но мне кажется, в данной схеме это непринципиально, поскольку считываем байт из ПЗУ мы всегда при установившемся
адресе
, и по этому же фронту счетчик увеличивает своё значение - к следующему фронту наверняка уже будет
стабильно удерживать адрес.

_________________
iLavr


19 Oct 2020 05:11
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 86 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6

Who is online

Users browsing this forum: Google [Bot] and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.