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

[Lavr]

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

Сработали, как ни странно, оба способа: сначала добавил шинные формирователи, но показалось,
что глюк кое-где проскакивает, после этого укоротил цикл чтения до 3/4 от оригинала, глюк исчез,
но посмотрел сигналы - от импульсов /WR пробивает иголоки на /OE ...

Glich.gif

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

P.S. Убрал, шинные формирователи, оставил лишь укороченный цикл чтения:

Glich2.gif

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

[Lavr]

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

В общем-то аппаратный недо-стек Gigatron-а практически процентов так на 80 близок к завершению:

GiG_SP.gif

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

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

[Lavr]

А кто-нибуть встречал динамичные не-текстовые игрушки на 2-строчном 16-символьном LCD-дисплее?

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

В Proteus есть такой пример:

LCD-GAME.gif

Рот с палкой, которого они называют "Пэкман" съедает текстовую строку.

4_Bit_LCD Driver.zip

Я погуглил и нашел одну игрушку такого плана - на Ардуино:

25940574.jpg

Игра называется "Hill Run 2".

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

https://create.arduino.cc/projecthub/Pu ... ame-1b0523

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

[Lavr]

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

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

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



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

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

В общем, выкинул я этот сомнительный узелок, формирующий CLK1 - CLK2 и приделал
нормальный формирователь двухфазной последовательности тактовых импульсов, где
все сигналы синхронно привязаны друг к другу:

Sync.gif

Частоту тактового генератора, правда, пришлось увеличить вдвое, но зато узел позволяет теперь
формировать из следующего набора частот:

GEN.gif

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

[Lavr]

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

Посмотрел я с этой точки зрения на неиспользуемые команды:

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

Tab_0.gif

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

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

Tab_1.gif

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

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

Tab_3.gif

Пока заметен один небольшой недостаток этого решения, следующие команды:

Code: Select all

     ST  PCH,[01,X++]; - сохраняем в стек старший адрес
;-------------------------------------------------------------------- граница сегмента
     JMP Y,55Н; - переход к подпрограмме

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

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

[Lavr]

Не стал я фиксить этот дефект - пусть будет фичей этого процессора. И у оригинального MOS 6502
похожие заморочки с пересечением границы сегмента были.

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

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

Code: Select all

     ST  PCL,[01,X++]; - сохраняем в стек младший адрес
     JMP Y,55Н; - переход к подпрограмме
     ST  PCH,[01,X++]; - сохраняем в стек старший адрес

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

GIG_SP.gif

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

В архиве - проект модели Gigatron-а с аппаратным недо-стеком:

GIG_SP.zip

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

Чтобы не писать длинных простыней, как стек приделан аппаратно, прикладываю также документ,
где всё подробно написано:

GiG_hSP.zip

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

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

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

[Lavr]

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

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

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

[Lavr]

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

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

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

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

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

Схемотехнически получилось весьма просто:

SelDat.gif

Первоначально на выход ПЗУ подключены оба регистра - команд и данных, но запись в них осуществляется через
мультиплексор, которым управляет дополнительный D-триггер U8:A, включенный как счетчик до двух.
Если ничего не подключить дополнительно, то работать эта схема будет так: четный байт записывается
в регистр команд, а нечетный - в регистр данных.
Эту логику корректирует детектор двухбайтного кода U7:A (code detector). Для простоты эксперимента принято, что
команды типа xxxx.xx11b - двухбайтные. Поэтому детектор двухбайтного кода запрещает переключаться счетчику
U8:A для всех команд, кроме двухбайтных.

Поскольку команда типа xxxx.xx11b - каждая четвертая, на осциллограмме видно, что лишь каждый четвертый
импульс CLK1 перенаправляется в регистр данных и блокируется для регистра команд.

SelDiag.gif

Если внимательно посмотреть проект:

SelDat.zip

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

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

[1N4148]

Всем добра.
С интересом прочитал эту тему, но мало что понял, потому как в теории не силен. Но хотелось бы задать несколько вопросов по железу, так как есть у меня плата для Гигатрона, и вот думаю, стоит ли браться за сборку. Был бы признателен получить ответ от квалифицированных специалистов.

1. Микросхемы.
В оригинале и в продаваемом наборе использована HCT-серия. Также авторы собрали один экземпляр на советской 555-ой серии, ну и все работает. Однако у меня нет полного комплекта микросхем из одной серии, а получается набрать солянку из HC, HCT, LS, ALS, AC. Заведется ли такой набор? В Спектруме (собирал Harlequin) такой вариант работает, а как здесь? Не будет ли проблем?

2. SRAM.
У авторов 62256 с временем доступа 55 нс. У меня есть только 62C256 45 нс. Подойдет ли такая замена?

3. ROM.
Подойдет ST M27C1024-10F1 с досупом 35 нс?

4. Проблема найти кварц на 6.25 МГц. Нельзя ли собрать, к примеру, генератор на 25 МГц и использовать делитель на 4?

Заранее благодарю за ответ.

[Lavr]

... есть у меня плата для Гигатрона, и вот думаю, стоит ли браться за сборку.

Безусловно, браться за сборку стОит! Конструкция очень интересная, заодно и опыта наберётесь!
Только не делайте популярную глупость: "если есть плата, я воткнул все микросхемы... а оно и не работает!"
Собирайте последовательно, поблочно, каждый раз проверяя работоспособность по Proteus-модели.

авторы собрали один экземпляр на советской 555-ой серии, ну и все работает. Однако у меня нет полного комплекта микросхем из одной серии, а получается набрать солянку из HC, HCT, LS, ALS, AC. Заведется ли такой набор?

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

У авторов 62256 с временем доступа 55 нс. У меня есть только 62C256 45 нс. Подойдет ли такая замена?

Подойдёт.

Подойдет ST M27C1024-10F1 с досупом 35 нс?

Подойдёт.

Проблема найти кварц на 6.25 МГц. Нельзя ли собрать, к примеру, генератор на 25 МГц и использовать делитель на 4?

Можно!

Заранее благодарю за ответ.

Не стОит благодарности!...
Как шутит один мой близкий друг:"Лучше маленький рубль, чем большое спасибо!"

[1N4148]

Только не делайте популярную глупость: "если есть плата, я воткнул все микросхемы... а оно и не работает!"

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

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

Я так понимаю, что при смешивании серий нарушается Божественная Гармония, и конструкция начинает стремиться к Хаосу.
Однако заметил, что зарубежные коллеги часто вообще не заморачиваются по этому поводу и ставят всё, что под руку попадется. Что ж, поступлю так же.
Осциллограф есть, но аналоговый. Теплый ламповый.

Проблема найти кварц на 6.25 МГц. Нельзя ли собрать, к примеру, генератор на 25 МГц и использовать делитель на 4?

Можно!

Кварц вроде нашел, должен отписаться поставщик. Надеюсь обойтись без делителя.

Так-то вроде все найду для сборки, но неожиданно всплыла еще одна проблема.
Когда собирал Спектрум, то пришлось еще и программатор для прошивки УФ-ПЗУ собрать, Willem. Я что-то был уверен, что 27С1024 он шьет, а оказалось - нет, не шьет. Вернее, может, но только с 16-бит адаптером. Так что теперь и адаптер, видимо, придется собирать
Так как рубль я передать не могу, то примите все-таки мою благодарность за развернутый ответ. Гран мерси.

[Lavr]

Я так понимаю, что при смешивании серий нарушается Божественная Гармония, и конструкция начинает стремиться к Хаосу.

Божественная Гармония в этом случае совершенно не при чем.
У разных серий разные задержки распространения, нагрузочные способности, а порой и логические уровни.
Поэтому могут неожиданно вылезти иголки, случиться непредвиденные гонки и т.п.

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

Вот тут как раз всё с точностью до наоборот.
Все знают, что смешивать серии не есть хорошо, но это не божественный закон, просто когда ставишь другую серию, следует подумать, к чему это может привести.
Gigatron, как и другие любительские компьютеры не полностью синхронный, и иголки в нём точно могут случиться, даже в Proteus-модели это видно.
Другое дело, к чему это приведёт? Может безболезненно обойтись, а может проблему создать.

Осциллограф есть, но аналоговый. Теплый ламповый.

Да "аналоговый" - это совсем не порок! Я сам больше люблю аналоговые.
Главное, чтобы полоса была хотя бы 10 МГц, ну и не забудьте, что в цифровых схемах на таких частотах желательно щупать щупом 1:10.

[Lavr]

Главное, чтобы полоса была хотя бы 10 МГц, ну и не забудьте, что в цифровых схемах на таких частотах желательно щупать щупом 1:10.

Полоса 40 МГц, делитель 1:10 тоже есть.
Вообще нарисовывается картина, что все есть, кроме прошитой ПЗУ.
Программатор у меня Willem версии 3m, совместим с 3.5 ...

Программатор Willem v.3m выделил в отдельный топик.

[1N4148]

Подскажите, а почему авторы выбрали SRAM (LY62256PL-55LLI) с временем доступа именно 55 нс? В DIP-корпусах такие труднодоступны, может, можно заменить на 70 нс?

[Lavr]

Подскажите, а почему авторы выбрали SRAM (LY62256PL-55LLI) с временем доступа именно 55 нс? В DIP-корпусах такие труднодоступны,

Я так думаю, что авторы выбрали SRAM (LY62256PL-55LLI) с временем доступа именно 55 нс в DIP-корпусе,
потому как для них эти SRAM труднодоступными не были.

гиг.PNG

Тем более, что авторы продавали наборы для сборки Gigatron-а, и очевидно не испытывали трудностей со SRAM.

может, можно заменить на 70 нс?

В этом очень легко убедиться самому! Берёте модель Gigatron-а из этого топика, в свойствах SRAM выставляете
параметр 70 нс, и смотрите - будет модель работать, или нет...