nedoPC.org

Electronics hobbyists community established in 2002
Atom Feed | View unanswered posts | View active topics It is currently 28 Mar 2024 09:18



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

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
Я посмотрел в исходники Gigatron ROM и увидел, что software stack там есть.
Впрочем, это и не удивительно, авторы сами об этом везде рассказывают:
Quote:
Is there a stack?

There is no hardware stack register, but the vCPU maintains a stack in the top half of the zero page. There are addressing modes that make function calling and returning relatively easy, and dynamic stacks possible when needed.

И, действительно, судя по исходникам, программный стек начинается с адреса $80.
Я решил не копать пока авторские муторные исходники, а попробовать реализовать software stack
самостоятельно. На мой взгляд всё должно работать примерно так:

Предположим, что у нас выполняется некоторая программа, из которой будет вызов подпрограммы,
и предположим пока для простоты, что ячейки адреса возврата находятся в нулевой странице ОЗУ
по адресам
80Н и 81Н для младшего и старшего байтов адреса, соответственно, а в ячейке 7FH
находится указатель "стека":
Code:
     ORG 0000H
     LDA 80H;    указатель "стека"
     STA [7FH];  инициализируем

... что-то делаем ...

     LDA 00H
     LD  AC,OUT; - clear port
     NOP; - Delay
     NOP; - 20 mS
;------------ собираемся вызвать подпрограмму
     LD  80H,X;    Укажем на ячейку памяти "стека"
     LDA RETADDR<; в A - младший байт RETADDR
     STA [X];      сохраняем младший байт в ячейку памяти "стека"
     ADD 01Н,X;    сдвинем вверх указатель стека
     LDA >RETADDR; в A - старший байт RETADDR
     STA [X];      сохраняем старший байт в ячейку памяти "стека"
;------------ адрес возврата сохранен в программном "стеке"

     LDA [7FH];    берем указатель стека
     ADD 02Н;      указатель сдвигаем на свободную ячейку 82Н
     STA [7FH];    сохраняем указатель "стека"

;------------ готовим вызов подпрограммы по адресу 3F55H
     LD  3FH,Y; - старший адрес (или сегмент) перехода
     LDA 30H;   - аргумент, передаваемый в функцию
     JMP  Y,55Н; переход к подпрограмме
     NOP; - after JMP
RETADDR:  - адрес возврата из подпрограммы (компилятор его знает)
     ...
     ...
     ...
SUB3F55:
... что-то делаем ...
     ...
;------------ готовим возврат из подпрограммы
     LDA [7FH];    берем указатель стека
     SUB 01Н,X;    сдвинем вниз указатель стека
     LDA [X];      взяли из "стека" старший адрес
     LD  AC,Y;     указали старший адрес возврата
     SUB 01Н,X;    сдвинем вниз указатель стека
     LDA [7FH];    берем указатель стека
     SUB 02Н;      указатель сдвигаем на свободную ячейку 80Н
     STA [7FH];    сохраняем указатель "стека"
     LDA [X];      взяли из "стека" младший адрес
     JMP  Y,AC;    возвращаемся из подпрограммы на RETADDR

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

_________________
iLavr


08 Sep 2020 14:21
Profile
Supreme God
User avatar

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

К примеру, есть команда: ST undef,[$OP]; ST <=> STORE

Судя по логике работы механизма адресации это должно выполняться как ST [$OP],[$OP]
То есть, байт из 0-страницы по адресу [$OP] записать в 0-страницу по адресу [$OP].
Но за один такт ОЗУ невозможно прочитать и записать по одному и тому же адресу, так что,
видимо, запись в ОЗУ производится, но на шину данных не включен ни один источник.
Поэтому, вероятно, в ОЗУ и запишется что-то undefind ("неопределеное") с шины.

_________________
iLavr


09 Sep 2020 06:20
Profile
Supreme God
User avatar

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

Попробовал... Плохо ложатся мнемоники Gigatron-а на мои исходники... :-?

В моих исходниках всюду под Интелловское соглашение расточено, типа:
MOV [приёмник],[источник]

А в мнемониках Gigatron-а всё наоборот:
LD [источник],[приёмник]

Много кода перелопатить придётся... :osad:

_________________
iLavr


09 Sep 2020 10:22
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
Shaos wrote:
так как там видео генерируется программно, то надо полагать весь существующий софт ожидает телевизора...

А вот есть мысль весьма недурственная на этот повод:
Если на выход регистра OUT Gigatron-a прицепить эту самую PIA 6820, как в Apple I, или её аналог
типа UART MC6850, как я сделал в Apple_I in Proteus, а затем пропатчить vCPU и v6502, чтобы вместо
генерации VGA-сигнала они делали вывод на UART, то может получиться весьма быстрый виртуальный
6502
и виртуальный Apple I, как бы даже не пошустрее оригинала
!
Да, графики с цветом не будет, но у Apple I их и так не было... :wink:

На выходе UART можно прицепить любую терминальную програму, или же терминалку на контроллере,
коих развелось великое множество, как в "Аюше", к примеру...

_________________
iLavr


10 Sep 2020 00:14
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
Shaos wrote:
Не - мой RASM тупой как валенок - никаких тебе квадратных скобок или плюсиков :obye:

Я просмотрел внимательно систему команд, и пришел к выводу, что скобки там в большинстве случаев -
это просто "понты", хотя и читается довольно удобно, но компилятор ассемблера писать неудобно...

Но, к примеру, на мнемониках i8080 <-> z80: LHLD - это LD [HL], но LHLD проще
обработать в компиляторе ассемблера.

Так же и в Gigatron-е: LD [Y,X] (даже запятая для понтов есть! :lol: Хотя она не особо и нужна,
поскольку это ничто иное, как LDA YX (LYXD - плохо звучит :wink: )
Так скомпилировать легче, поскольку это целиком один код без аргумента.

Вариант Gigatron-а: LD [X] - это, если по-честному, - LD [0,X] - обращение к zero page.
На мой взгляд, LDA X - более простой и однозначный вариант, поскольку спутать не с чем.

Остается LD $OP и LD [$OP] - здесь, как мне кажется, надо поступить, как в ассемблерах 6502:
LDA #$OP - загрузка в А числа $OP, а LDA $OP - загрузка в А числа по адресу [0,$OP].

Я, честно говоря, префикс # для чисел не люблю, он противоречит привычкам... :wink:
Но префикс # всё равно в ассемблере уже будет: #>, #< - взять старшую или младшую
часть числа.

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

_________________
iLavr


10 Sep 2020 00:55
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
В общем, после внедрения в жизнь всех вышеперечисленных мероприятий,
мнемоники ассемблерных команд Gigatron-а приняли следующий вид:

 КОДЫ 00_7FН
Attachment:
CODE00_7F.gif
CODE00_7F.gif [ 45.71 KiB | Viewed 13014 times ]

 КОДЫ 80_ВFН
Attachment:
CODE80_BF.gif
CODE80_BF.gif [ 23.17 KiB | Viewed 13014 times ]

 КОДЫ С0_FFН
Attachment:
CODEC0_FF.gif
CODEC0_FF.gif [ 32.55 KiB | Viewed 13014 times ]

Самая неудачная мнемоника, как мне кажется, получилась: STIT = STore IT :-?

Coбственно и команда не совсем удачная: ST #$OP,$OP - сохранить операнд по адресу,
заданному самим операндом.

Если STore OPerand, то выйдет: STOP, а если STore ARgument, то получится: STAR... :lol:
Остановился на STIT .

_________________
iLavr


10 Sep 2020 10:00
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
Lavr wrote:
...мнемоники ассемблерных команд Gigatron-а приняли следующий вид:...
(Упорядочены по алфавиту)
Attachment:
Gigatron_code_7.zip [5.11 KiB]
Downloaded 328 times

_________________
iLavr


10 Sep 2020 11:37
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
Lavr wrote:
Если на выход регистра OUT Gigatron-a прицепить эту самую PIA 6820, как в Apple I, или её аналог
типа UART MC6850, как я сделал в Apple_I in Proteus, а затем пропатчить vCPU и v6502, чтобы вместо
генерации VGA-сигнала они делали вывод на UART, то может получиться весьма быстрый виртуальный
6502
и виртуальный Apple I, как бы даже не пошустрее оригинала
!

Легче всего реализовать эту идею, что называется, "в лоб", т.е. поставить в схему Gigatron-a
вместо регистра OUT простой UART AY-3-1015 или КР581ВА1 (или их аналоги)...
Но там есть свои трудности с выбором тактирующих частот... :-?

Поэтому UART MC6850,PIA 6820, i8250, i8251 применить интереснее,
поскольку эти БИС более гибкие. Только на этом пути подстерегает одно большое "НО"!
У Gigatron-a всего один порт ввода и один порт вывода, причем аппаратно обращение
к ним в схеме задействованно. Я сразу выкинул порт вывода (он - обычный регистр), и заменил
его на шинный формирователь данных для устройств вывода.

Осталось найти адресное пространство для устройств ввода-вывода. Можно было бы ввести их в
карту памяти, как в "Специалисте", но отдельное пространство для устройств ввода-вывода с
обращением к ним командами IN и OUT - удобнее!

Я посмотрел на команды ввода-вывода Gigatron-a:
Attachment:
GIG_I_O.gif
GIG_I_O.gif [ 6.81 KiB | Viewed 12958 times ]

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

Для простоты реализации я выбрал привычные всем команды LDA IN и LD AC,OUT, и слегка подправил
схему так, чтобы они превратились в привычные всем IN PORT и OUT PORT, при этом значение PORT
аппаратно фиксируется в отдельный регистр типа 74LS373 - он теперь регистр адреса для устройств
ввода-вывода
Gigatron-a.
Остальные команды ввода-вывода на этот порт не влияют, т.е. пишут и читают по последнему
записанному в него адресу.

При программировании выяснилось, что такое решение не самое удачное, поскольку тайминги
Gigatron-a (а он - RISC-типа и выполняет любую команду за 1 такт), так вот его тайминги
плохо подходят к UART БИС, поэтому пришлось "потанцевать с бубном" при программировании. :-?

С другой стороны совместимость с оригинальным Gigatron-ом осталась полная.
По сбросу в регистр адреса для устройств ввода-вывода записывается 00Н, и если подключить
на этот адрес регистр вывода Gigatron-a, то всё будет работать как и было.

А начиная с адреса 0F8H я подключил UART i8250! Его модель в Proteus чувствительна к
сигналу /IOWR, поэтому его аналог в схеме Gigatron-a пришлось укоротить и подзадержать.

Но в итоге - ВСЁ ЗАРАБОТАЛО! :lol:
Attachment:
GIG_Serial.gif
GIG_Serial.gif [ 49.56 KiB | Viewed 12958 times ]


Выкладываю архивчик с моделью для тех, кто хочет "поиграть" в Gigatron с терминалом. :wink:
Attachment:
GigatronS.zip [83.5 KiB]
Downloaded 331 times

Так что Apple_I на основе Gigatron-a может быть и не таким уж медленным! :esurprised:

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

_________________
iLavr


12 Sep 2020 13:54
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
И в связи с последней фразой предыдущего поста здесь надо сделать следующее замечание,
чтобы не получилось так, что я вроде как всех ввёл в заблуждение...

Дело в том, что на частоте 6.25 МГц в схеме Gigatron-а скорее всего ни один реальный UART
работать не будет, потому как не рассчитаны они на такие скорости.
Во всех материнских платах при обращении к УВВ автоматом включается задержка WAIT на
несколько тактов, в схеме же Gigatron-а механизм WAIT не предусмотрен.
Так что в реальном Gigatron-е все БИС UART скорее всего загнутся на частотах 2...4(max)МГц.

А вот LCD c интерфейсом SPI такие частоты совершенно не мешают, они и на бОльших частотах
вполне прилично работают.

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

Именно из-за этого у меня там странная тактовая частота - 990 Гц - она не кратна частоте
отрисовки экрана. В противном случае, на частоте 1000 Гц может случится так, что в цикле
проект как бы "завис", но на самом деле отрисовка попадает в одно и то же состояние.

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

_________________
iLavr


13 Sep 2020 03:11
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
Lavr wrote:
... я укрепился в мысли, что лучший индикатор для Gigatron-a -
это любой подходящий LCD с интерфейсом SPI: ...

В общем решил я "лучший индикатор для Gigatron-a" также проверить, как он работает... :wink:
И заодно проверить все прелести программирования на ассемблере оригинальной конструкции:
тут и software stack есть, и "трамплины", и косвенное чтение массива из ОЗУ.
Attachment:
GigaSPIs.gif
GigaSPIs.gif [ 9.82 KiB | Viewed 12712 times ]

 СХЕМА Gigatron + LCD
Attachment:
GigaSPI.gif
GigaSPI.gif [ 45.47 KiB | Viewed 12712 times ]

И главная неприятность неожиданно всплыла совершенно в другом месте. :x
Я уже в третий раз сталкиваюсь с этим: модель SRAM 62256 Proteus-a при несколько
нестандартном включении начинает глючить. И глюк заключается в том, что после
операции чтения она задерживает снятие данных с шины, что далее приводит к конфликту.

Ясное дело, что и настоящие SRAM поступают примерно так же, но модель не реагирует
и на собственные настройки:
Code:
Address Access Time       100ns
Chip Enable Access Time   100ns
Output Enable Time         50ns
Output Disable Time        35ns
Minimum Write Pulse        60ns

{MODFILE=62256.MDF}
{ITFMOD=NMOS}
{TAA=100ns}
{TCE=100ns}
{TOE=50ns}
{TOD=35ns}
{TWP=60ns}
{PACKAGE=DIL28}
Менял я эти параметры, но к положительному результату это не привело... :osad:

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

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

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

Архив проекта Gigatron-SPI прилагаю:
Attachment:
GigaSPI.zip [378.45 KiB]
Downloaded 311 times

Там все необходимые "приблуды" для комфортной игры с моделью Gigatron-a + LCD.

В старших версиях Proteus модель LCD Nokia-3310 работать не будет.
Её надо заменить на родную модель Proteus-а, как я делал в проекте троичного компьютера.


P.S. Тактовая частота модели Gigatron-a в проекте - максимально возможная. Если её
увеличить, то придётся подобрать задержку Т2 и задержку /WR для SRAM.

_________________
iLavr


21 Sep 2020 00:14
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
Lavr wrote:
Shaos wrote:
Lavr wrote:
Shaos, кстати, посмотри, может быть в исходник твоего RASM (или как его там) удачно ляжет?
Дык у них вроде ж был ассемблер, не?
Оригинальный ассемблерный код в ПЗУ там вобще на "питоне" собирают... :-?
Ну в общем хотелось бы простенький ассемблер даже DOS-овский подошел бы.

Без оригинального нативного ассемблера Gigatron-а всё же трудновато кодить... :-?
Хотя с третьего захода я уже приспособился копипастить сам у себя на ассеблере i8080. :wink:
Главное и самое приятное, что ассеблер этот правильно вычисляет метки, причем вполне
может выделить и старшую и младшую часть:
Code:
    DB    14H,(IMG_MOV/2/256)AND 0FFH; LD  IMG_MOV,Y; - старший адрес (или сегмент) перехода
    DB    0E0H,(IMG_MOV/2)AND 0FFH;   JMP  Y,IMG_MOV; переход к подпрограмме

Всё остальное вручную зело проще, но тем не менее компилятор ассемблера хотелось бы... :roll:
Lavr wrote:
Вот, к примеру, что пишет по этому поводу некто H.G.Muller, который хочет заставить Gigatron
играть в шахматы: The Gigatron project - Page 2 - TalkChess.com ...
И вот этот самый г-н H.G.Muller для себя простенький компилятор ассемблера написал.
The Gigatron project - Page 4 - TalkChess.com

Я обратился к нему с письмецом, не поможет ли он с исходниками нативного ассемблера для Gigatron-а?
A г-н H.G.Muller взял да и помог! :roll:
Attachment:
GIGAssm.zip [6 KiB]
Downloaded 309 times

Единственное, что получилось неудачно, так это то, что г-н H.G.Muller, так же, как и я здесь,
решил изменить оригинальные мнемоники ассемблера Gigatron-а на более близкие к ассемблеру
6502
, поэтому надо будет потестировать его на синтаксис...

Ассемблер Gigatron-а собирается популярными компиляторами, и пару шероховатостей мы с
Shaos-ом нашли и подправили.

Я лично собирал в Microsoft Visual C++ 5.0 как консольное приложение, и если кому нужен
рабочий экземпляр - выношу "в студию":
Attachment:
GIGAssmEXE.zip [17.01 KiB]
Downloaded 315 times

Естественно, всё - "as is", я на нём тоже ещё не программировал, и писал свой последний код под
ассемблером для i8080 для быстроты.


P.S. Special thanks to Mr. H.G.Muller for his Gigatron assembler sources!

_________________
iLavr


21 Sep 2020 02:31
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08:08
Posts: 7777
Location: Россия
Reply with quote
Lavr wrote:
A г-н H.G.Muller взял да и помог! :roll:
Единственное, что получилось неудачно, так это то, что г-н H.G.Muller, так же, как и я здесь,
решил изменить оригинальные мнемоники ассемблера Gigatron-а на более близкие к ассемблеру
6502
, поэтому надо будет потестировать его на синтаксис...

Занялся я этим делом, и пришлось вспомнить знаменитую фразу, что порой легче написать программу
просто заново, нежели разбирать исходники чужие, или даже свои...
:wink:

Но самое интересное оказалось не в этом... Практически с первых строк кода г-на H.G.Muller
сложилось у меня стойкое ощущение, что этот код я ранее где-то видел! :roll:
Хотя понятное дело, что с г-ном H.G.Muller-ом я ранее не был знаком... :-?

Пришлось покопаться в Интернете и на своих флешках, причем сразу было понятно в какую сторону
следует искать: в сторону ассемблеров 6502.
И, действительно, оказалось, что код г-на H.G.Muller-а очень близок к тому, как пишут
ассемблеры для 6502! 8)
Гораздо интереснее для меня оказалось, что и пишут-то их все примерно одинаково!
И если кому интересно, мне попалось даже текстовое описание, как примерно это делается:
Attachment:
Компилятор_ассемблера.zip [223.26 KiB]
Downloaded 319 times


Собственно, в чем разница-то: когда пишешь ассемблер типа i8080, то в подавляющем большинстве
случаев мнемонике сразу соответствует код + его немного доработать по аргументам.
Поэтому у i8080 - MVI R,DATA и MOV Rx,Ry - разные мнемоники, хотя это и не всем нравится, но
компилятор ассемблера написать легче...

В случае, когда одной мнемонике, к примеру LD, соответствуют множество кодов, в зависимости
от аргументов после неё, шаблон компилятора типа i8080 подходит довольно плохо. :osad:

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

_________________
iLavr


26 Sep 2020 03:50
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08: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 12583 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 05:14
Profile
Supreme God
User avatar

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

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

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

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

_________________
iLavr


26 Sep 2020 12:10
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 08: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 12631 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


05 Oct 2020 23:33
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 94 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7  Next

Who is online

Users browsing this forum: No registered users and 9 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.