Войти
ФлеймФорумЖелезо

А если ли у нас ностальгирующие по MOS 6502?

Страницы: 1 2 310 11 Следующая »
#0
16:34, 28 ноя. 2017

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

; Move memory down
;
; FROM = source start address
;   TO = destination start address
; SIZE = number of bytes to move
;
MOVEDOWN LDY #0
         LDX SIZEH 
         BEQ MD2 
MD1      LDA (FROM),Y ; move a page at a time 
         STA (TO),Y
         INY
         BNE MD1
         INC FROM+1
         INC TO+1
         DEX
         BNE MD1
MD2      LDX SIZEL
         BEQ MD4
MD3      LDA (FROM),Y ; move the remaining bytes
         STA (TO),Y
         INY
         DEX
         BNE MD3
MD4      RTS
Ужасно по моему всё. Он 8-битный настолько насколько это вообще возможно. Даже цикл длиннее 256 итерацией не делали.
Не только аккумулятор A и два индексных регистра X и Y были 8-битными, но и регистр вершины стека S тоже был 8-битным. Если подробить ОЗУ на блоки по 256 байт, то стек просто всегда находился во второй странице.
Единственное что было 16-битного - это счетчик инструкций.
Это приводило к тому, что в регистрах вообще не могло лежать ничего 16-битного для той же пересылки данных процедуры MEMMOVE.
Фишкой проца была относительно короткая адресация байт в zero-page, то есть первых 256 байтах ОЗУ - была масса команд с разными режимами.
Вершинами их было две пары адресаций, которые используются в коде выше
LDA (FROM),Y - Загрузить в аккумулятор из ячейки памяти из zero-page по адресу (байт) FROM, где лежит слово (2 байта) к которому прибавляется содержимое регистра Y (1 байт) и из полученного адреса и загружается аккумулятор.
Замечу тут некоторую ассиметричность регистров X и Y, потому что аналогичная команда для X выглядела бы так:
LDA (FROM,X) и означала бы другое - взять из ячейки памяти по адресу FROM+X (это всегда будет байт с прокруткой вокруг zero-page) адрес (2 байта) и из него загрузить аккумулятор.
Таким образом использованные команды можно подытожить:
LD* - загрузить A,X,Y
ST* - сохранить A,X,Y
IN* - инкремент A,X,Y
DE* - декремент A,X,Y
B* - переход по условию
RTS - return

И вот что по сути происходит в этом диком коде - он сперва пересылает порции по 256 байт столько раз сколько SIZEH - верхний байт пересылаемого количества и потом добивает это передачей оставшихся SIZEL байт.
Потому что 8 бит и адресовать 16 бит можно только из zero-page.

Мде... Вот органически меня передёргивает от этого всего и у меня возникает вопрос - среди нас есть те кто испытывает к этому процессору тёплые ностальгические чувства?


#1
16:37, 28 ноя. 2017

P.S.
Сам проц при этом конечно эпохален - это первые эпплы, это Famicom/NES/денди и еще много всего разного - в своё время MOS совершило ценовую революцию и на этот проц плотно подсела куча народу.

#2
19:32, 28 ноя. 2017

=A=L=X=
> Мде... Вот органически меня передёргивает от этого всего и у меня возникает
> вопрос - среди нас есть те кто испытывает к этому процессору тёплые
> ностальгические чувства?
Вот я прямо сейчас пишу под это семейство. Правда не на ассемблере, а на С, но сс65
хоть и имеет флаги оптимизации, но это номинально, без чтения листинга и правки
все равно далеко не уехать. В принципе сильно больших проблем писать на чистом
ассемблере под него не вижу, дело привычки. И кстати на нем (ассемблере под 6205)
до сих пор пишут, причем игры )))

Вот эта например


Правда есть одна проблема, после того, когда ты реально рад что у твоей игры будет не
256 байт ОЗУ, а целых 512, а то и 1024, смех над фразой про 640 килобайт вызывает непонимание,
а текстовый редактор которому нужно полгига или  IDE на 4 гига, заставляют долго думать. )))))

#3
19:47, 28 ноя. 2017

exchg
И уже что то у тебя получается? Я так понял по истории тем что ты под nes и пишешь?

#4
20:01, 28 ноя. 2017

=A=L=X=
> И уже что то у тебя получается? Я так понял по истории тем что ты под nes и
> пишешь?
Под нее, из визуалочки пока пока нечего особенного показать

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

#5
20:08, 28 ноя. 2017

exchg
Хорошая анимация.

#6
21:00, 28 ноя. 2017

=A=L=X=
> Хорошая анимация.
Хороший художник. Мое то дело там маленькое.

#7
21:14, 28 ноя. 2017

=A=L=X=
> от этого всего и у меня возникает вопрос - среди нас есть те кто испытывает к
> этому процессору тёплые ностальгические чувства?
Есть!
Году в 90-м или 91-м у меня появился Atari 65 XL, до этого программировал только на калькуляторе МК-54 и на фокале на БК-0010, который мне оставили на 2 недели. К Atari была книжка по бейсику на английском и кто-то дал мне  книгу по ассемблеру 6502 на польском. Быстро выучив бейсик, я перешёл к ассемблеру, начал понимать, но программировать было не на чем - не было самого компилятора ассемблера. Тогда я написал свой компилятор на бейсике (в книге была таблица машинных кодов и соответствующих мнемоник), потом дописал дизассемблер, на этом инструментарии много чего успел сотворить. Потом, наконец, мне попался фирменный ассемблер, но я понял, что мой лучше.

#8
7:34, 29 ноя. 2017

Mikle

Круто, понятно. :)

#9
8:32, 29 ноя. 2017

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

Кстати, из 8-битных процессоров того времени 6502 отличался самым быстрым выполнением команд, поэтому 1мгц 6502 вполне соответствовал 3мгц Z80. Не последнюю роль тут играла нулевая страница, которую многие использовали в роли некоего аналога регистров - команды записи и чтения туда из регистров были в 2 раза быстрее, чем в другие ячейки памяти.

До сих пор поражаюсь, зачем создатели Apple ][ сделали графический режим не 256 на 192, а 280 на 192. Насколько это замедлило игры! Хотя ответ понятен - Возняк заботился не о программистах, а о себе. Это очевидно, если посмотреть на чудовищное и кривейшее отобоажение матрицы экрана на видеопамять.

Кстати один из шикарных современных проектов, написанных на ассемблере 6502 - это игра Planet X2 для Commodore 64, написанная 8-bit Guy. Один из интереснейших приемов, примененных им в ней - одновременное использование RAM и ROM, отображенных на последние 8кб адресного пространства. Советую посмотреть на ютубе его ролик "the making of Planet X2".

#10
8:46, 29 ноя. 2017

ZeebaEata
Дык отсутствие умножения и деления на 8ми битных CPU - это как раз правило. И даже на гибридных 8/16 как z80 и i8080 не было умножения и деления (а только двоичные сдвиги).

Кстати я что-то не смог найти инфо о том в каких CPU умножение/деление появилось.

#11
9:27, 29 ноя. 2017

ZeebaEata
> Одна из забавных фич этого процессора - отсутствие команд умножения и деления

Ну это мягко говоря не фича и касалось это большей части 8-битных процессоров.
В самых распространённых альтернативах - Intel 8080 и Zilog Z80 умножения тоже не было.

#12
9:33, 29 ноя. 2017

Dexus
> И даже на гибридных 8/16 как z80 и i8080

Они не гибридные, они полностью 8-битные во всей красе. Арифметико-логическое устройство было 8-битным. 16-битная арифметика из сложения/вычитания и инкремента-декремента не изменяла флаги и потому характер её использования был скорее в духе адресации массивов, то бишь не ALU-шная задача. Это всё строго попадает под дефиницию 8-битного процессора, то что шина адреса 16 бит и могут быть какие то облегчения к её эксплуатации - неважно, на битность не влияет.
Битность проца равна битности его ALU, поэтому даже полностью 32-битный по архитектуре Motorola 68000 первых выпусков трудившийся в Sega Mega Drive считался 16-битным. Несмотря на то что регистры даже данных у него были 32-битные.

#13
10:22, 29 ноя. 2017

=A=L=X=
> Они не гибридные, они полностью 8-битные во всей красе.
И тем не менее, 16 битные операнды использовались очень активно.

> 16-битная арифметика из сложения/вычитания и инкремента-декремента не изменяла флаги
Не могу сказать по другим, но в Z80 арифметика с 16битными операндами меняет флаг P/V при переполнении. Но это не важно, по сути это "шорткат" для двух 8мибитных операций.

#14
10:30, 29 ноя. 2017

Dexus
> И тем не менее, 16 битные операнды использовались очень активно.

Еще как.
Перепроверил - это инкременты/декременты с регистровыми парами не меняли никакие флаги, были вот как раз больше для операций с указателями. А сложения и вычитания - таки меняли их в полной мере. Так что про ограниченную поддержку 16-битных операций таки можно говорить в рамках ALU, но да, она скорее всего состояла из двух 8-битных подряд, поэтому не считается. Но это классические 8-битные процы, они не "смесь с 16 битами". Это было одинаково в Z80 и 8080 так как первый совместим со вторым.

Страницы: 1 2 310 11 Следующая »
ФлеймФорумЖелезо