nedoPC.org

Community of electronics hobbyists established in 2002

...
Atom Feed | View unanswered posts | View active topics It is currently 26 Nov 2020 15:03



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

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Но это всё не столь уж принципиально, гораздо интереснее другое: аппаратного стека в Gigatron-е
точно нет. А вот как его эмулируют чисто программно? :roll:

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

_________________
iLavr


08 Sep 2020 03:07
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Lavr wrote:
Просто в схеме Gigatron-а реализован зачаточный ПДП в командах типа:
LD [Y,X++],OUT
это пересылка байта из памяти (ОЗУ) непосредственно в порт вывода с аппаратным
инкрементом адреса! :lol:

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

Объясняю для очень внимательных: для X++ в схеме реализована аппаратная поддержка:
Attachment:
0007.gif
0007.gif [ 8.94 KiB | Viewed 1232 times ]

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

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

_________________
iLavr


08 Sep 2020 04:27
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09:08
Posts: 7777
Location: Россия
Reply with quote
Lavr wrote:
гораздо интереснее другое: аппаратного стека в Gigatron-е
точно нет. А вот как его эмулируют чисто программно? :roll:

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

Вот, к примеру, что пишет по этому поводу некто H.G.Muller, который хочет заставить Gigatron
играть в шахматы:
The Gigatron project - Page 2 - TalkChess.com
H.G.Muller wrote:
mar wrote:
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-а я пока всю эту процедуру плохо себе представляю... :-?

_________________
iLavr


08 Sep 2020 08:15
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09: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 15:21
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09: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 07:20
Profile
Supreme God
User avatar

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

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

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

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

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

_________________
iLavr


09 Sep 2020 11:22
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09: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 01:14
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09: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 01:55
Profile
Supreme God
User avatar

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

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

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

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

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

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

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

_________________
iLavr


10 Sep 2020 11:00
Profile
Supreme God
User avatar

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

_________________
iLavr


10 Sep 2020 12:37
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09: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 1080 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 1080 times ]


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

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

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

_________________
iLavr


12 Sep 2020 14:54
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09: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 04:11
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09: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 834 times ]

 СХЕМА Gigatron + LCD
Attachment:
GigaSPI.gif
GigaSPI.gif [ 45.47 KiB | Viewed 834 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 34 times

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

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


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

_________________
iLavr


21 Sep 2020 01:14
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09: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 37 times

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

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

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

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


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

_________________
iLavr


21 Sep 2020 03:31
Profile
Supreme God
User avatar

Joined: 21 Oct 2009 09: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 33 times


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

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

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

_________________
iLavr


26 Sep 2020 04:50
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 86 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next

Who is online

Users browsing this forum: Google [Bot] and 2 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.