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

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

Страницы: 18 9 10 11 12 13 Следующая »
#165
14:31, 6 фев. 2020

Mikle

https://gamedev.ru/flame/forum/?id=231791&page=11&m=4968972#m157
Прямо на этой же самой странице. :)


#166
15:16, 6 фев. 2020

=A=L=X=
Блин, не прошло и года :)

#167
(Правка: 15:49) 15:45, 6 фев. 2020

Mikle

Нашёл детальный разбор полётов недокументированных инструкций: https://wiki.nesdev.com/w/index.php/CPU_unofficial_opcodes
И в принципе всё достаточно логично - официальный декодер работал как бы так: 130 слотов в ROM которые работали по принципу "если такие то биты в опкоде зажжены, а такие то погашены, то запустить такой то блок на таком то такте". Т.к. огромная часть опкодов просто не использовалась, то это создало довольно забавные лакуны если запускаемые блоки по сути друг другу не особо мешали.
Например вот тут рассматриваются самые полезные из таких опкодов: https://wiki.nesdev.com/w/index.php/Programming_with_unofficial_opcodes
Например

ALR #i ($4B ii; 2 cycles)
    Equivalent to AND #i then LSR A.

Т.е. одна команда сперва запускала AND аккумулятора с непосредственным байтом и тут же сдвигала полученный аккумулятор вправо.
Порадовала, например, инструкция LAX:
Shortcut for LDA value then TAX.

Т.е. загрузить из памяти в A и тут же сохранить его в X - можно реально экономить байт инструкции. Однако, как замечает статья, хотя LAX работает с почти всеми режимами адресации обычного LDA, но происходит сбой при LAX #data - непосредственном данном, где то внутри при такой комбинации оказывается попорченной шина данных и результат непредсказуем.
И, как в статье резюмируется:
MOS 6502: even the bugs have bugs.
xD

А вот здесь есть тянущее на академическое исследование как работает запрещённый опкод $8B, который привлёк внимание специалистов потому что настолько не стабильно работает, что выдаёт разные результаты даже на одной и той же машине с одними и теми же входными данными.

#168
8:34, 7 фев. 2020

=A=L=X=
> вот тут рассматриваются самые полезные из таких опкодов
А я считал себя первооткрывателем :)
=A=L=X=
> настолько не стабильно работает, что выдаёт разные результаты даже на одной и
> той же машине с одними и теми же входными данными
Почти идеальный рэндомайзер, как такое вообще может быть?

#169
9:52, 7 фев. 2020

Mikle

> Почти идеальный рэндомайзер, как такое вообще может быть?

Если взять RS-триггер и просто включить его - подать напряжение, то он стабилизируется в идеале непредсказуемо - одно транзисторное плечо должно запереть другое в стабильное состояние 0 или 1, но какое именно при включении диктуется не внешним управляющим воздействием, а случайными параметрами схемы - от физических свойств транзисторов, проводов и всего прочего.

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


А я тут, кстати, первую законченную программу на денди написал, которая пойдёт как первый тестовый материал для урока:

#170
12:42, 7 фев. 2020

Ностальгия = онанизм помноженный на бомжевание

#171
13:04, 7 фев. 2020

mega_otec

И игры это инфантилизм помноженный на бегство от реальности.

#172
(Правка: 16:09) 16:05, 7 фев. 2020

Еще один забавный момент всплыл скорее всего широко известный среди программистов на первом популярном компьютере Apple - Apple II.
Сам процессор MOS 6502 насквозь 8-битный и чтобы оперировать 16-битными числами или счётчиками обязательно приходится сперва инкрементировать или складывать младший байт и проверяя на переполнение уже опционально обрабатывать старший байт - восьмибитность доминирует и не отпускает ни на секунду.
И в какой то момент возится с этими длинными цепочками 8-битных команд для того чтобы делать много 16-битных операций в том числе с указателями надоело самому Стиву Возняку - создателю компьютера Apple II.
Причём всплыло это всё во время разработки интерпетатора бейсика и тогда он придумал такую штуку как SWEET16: https://en.wikipedia.org/wiki/SWEET16

Изображение

Хаха! Т.е. программируя на MOS 6502 он постоянно спотыкался об 8-битные шажки для вычислений и написал на одном из первых в мире вообще 8-битных ПК на самой заре их появления... виртуальную 16-битную машину размером в 300 байт! :D Что совсем уж забавно - код был спроектирован так, чтобы вызов подпрограммы входа в режим SWEET16 продолжал выполнение уже "машинных" кодов SWEET16 со следующего адреса программы, а виртуальная машинная команда выхода из режима SWEET16 возвращала поток управления уже реальной инструкции MOS 6502 следующей за ней в памяти, т.е. вход и выход из режима SWEET16 был как бы бесшовным и сам SWEET16 был интегрирован в интерпретатор бейсика чтобы (по словам Возняка) резко экономить память на цепочках 16-битных вычислений которые позарез были нужны интепретатору, но при этом производительность по сравнению с аналогичным кодом на 6502 падала примерно на порядок.
Вот такие дела.
Виртуальные машины были намного раньше в домашних ПК чем я мог себе даже подумать. xD
P.S.
Забавно, что сама статья от самого же Стива озаглавлена как "Машина мечты" - и блин, я припоминаю внезапно что в релевантной моей теме тут как раз уже вспоминали про SWEET16 - и кажется даже про то что кто-то начал делать физическую схему MOS 6502 где SWEET16 был бы реальным аппаратным режимом...

#173
(Правка: 16:49) 16:48, 7 фев. 2020

=A=L=X=
> Сам процессор MOS 6502 насквозь 8-битный и чтобы оперировать 16-битными числами
> или счётчиками обязательно приходится сперва инкрементировать или складывать
> младший байт и проверяя на переполнение уже опционально обрабатывать старший
> байт - восьмибитность доминирует и не отпускает ни на секунду.
В современных ISA для таких операций вводят специальные команды типа "Add With Carry" и "Subtract With Borrow".
Например, в AVR:

Изображение

В итоге сложение многобайтовых чисел выражается в цепочки add+adc+adc+adc... без каких-либо дополнительных проверок и бранчей. Например.
Такие же инструкции есть и в POWER (addc), и даже в 8080 (adc).
Разве у MOS 6502 такого не было?
Хотя, возможно, их ввели как раз из-за полученных на нём попаболей. Было бы занимательно.
#174
(Правка: 17:09) 17:05, 7 фев. 2020

Delfigamer
> Разве у MOS 6502 такого не было?

Напротив, это всё что у него было - у него была только команда adc, а чтобы делать add надо было принудительно перед этим сбрасывать флаг переноса командой clc (clear carry).
Даже в Intel 8080 были отдельные пары команд - add/adc и sub/sbc. А вот в 6502 были только adc и sbc.
Он был ну очень продуман на скупость.
(вообще сам принцип цепочечных сложений очень старый и в 8-битках появился сразу же как давно известная данность)
P.S.
Забавный еще факт, что в 8-битном Intel 8080 были 16-битные сложения, но как раз только ADD без ADC - они воспринимались только как операции с указателями.
А вот Zilog Z80 расширяя систему команд i8080 ввёл и 16-битные сложения вида ADC и при этом 16-битные вычитания тоже, но... уже только вида SBC - т.е. SUB без carry не внёс даже.
Такие вот исторические асимметрии. :)

#175
(Правка: 8 фев. 2020, 4:26) 17:14, 7 фев. 2020

Delfigamer
> без каких-либо дополнительных проверок и бранчей

А, тут снова поясню - с индексными регистрами X и Y или даже с ячейками памяти 6502 мог делать только инкременты/декременты, но прочую арифметику - нет.
Полный спектр арифметических команд в 6502 был доступен только для аккумулятора A и при этом не было команд инкремента/декремента аккумулятора!
Поэтому когда речь идёт про инкремент указателя, который для 16-битной косвенной адресации должен был хранится в двух последовательных байтах zero page, то в этом процессоре проще всего было инкрементировать lsb-байт прямо в памяти и по результату переполнения (carry) решать условным переходом инкрементировать msb байт или нет. Индексация была такая вот.

#176
5:16, 8 фев. 2020

=A=L=X=
> Сам процессор MOS 6502 насквозь 8-битный и чтобы оперировать 16-битными числами
> или счётчиками обязательно приходится сперва инкрементировать или складывать
> младший байт и проверяя на переполнение уже опционально обрабатывать старший
> байт - восьмибитность доминирует и не отпускает ни на секунду.

Ваши бы усилия в современные процессоры направить. :) К чему тревожить старичка MOS6502 ? Пускай покоится с миром... Своё он уже отработал.

С нетерпением жду обзора по микропроцессорам линейки M680x0 :)

#177
(Правка: 6:01) 5:48, 8 фев. 2020

Gradius
> Ваши бы усилия в современные процессоры направить. :)

Дело в том что современное - оно слишком сложно чтобы в одной статье описать, поэтому когда под моё внимание попадает что-то с битностью выше 16, то это в основном крайне поверхностные обзоры: https://gamedev.ru/flame/forum/?id=231027 ибо детальный разбор полётов был бы размером с книгу на 800 листов.

> С нетерпением жду обзора по микропроцессорам линейки M680x0 :)

Что касается m68k - она мне очень нравится как архитектура и возможно я прикоснусь к ней когда-нибудь вплотную на практикумах под Sega Mega Drive. :)
Но для вас может быть уже интересна следующая заметка на эту тему: https://gamedev.ru/flame/forum/?id=226622&page=6#m79 (сперва идёт поверхностный обзор Ricoh 5A22 из SNES, а потом - m68k из SMD в сравнении и с комментарием японского разработчика)
P.S.
И да, я читаю каждое обновление вашей темы про BlackPrism и мне такие штуки крайне нравятся, но просто мне нечего там написать. Всё круто и в принципе своём не вызывает нареканий или вопросов. :)

#178
(Правка: 7:28) 7:28, 8 фев. 2020

=A=L=X=
> ...когда под моё внимание попадает что-то с битностью выше 16, то это в основном
> крайне поверхностные обзоры...

Кстати, никогда не понимал, почему SEGA MD и SNES считаются 16-битными приставками?  Если смотреть шину данных видео-процессоров, то они остались по-прежнему 8-битными.  Что сеговский VDP, что SNES'овский PPU.  Если с колокольни процессора, то M68000 24-разрядный, а 65C816 так и остался 8 битным (могу ошибаться).      Графика 8-битная: у СЕГИ 64 цвета из 512 цветов,  у СНЕСА 256 цветов одновременно (т.е. влазит в байт) .

Скорее всего - рекламный трюк.

Вспомнилось сразу  видео "консольные войны" (SEGA vs. Nintendo) - "What Nintendon't " :)

или

Сейчас бы за такую "рекламу" СЕГА судилась с Нинтендой )))

Победила Нинтенда.  Сега профукала свою консоль.

По поводу олдскульности. Моё мнение - всё, что заходит за пределы спрайтов и 2D - это уже не олдскул.  В частности повороты спрайтов на любой угол, полупрозрачность, масштабирование спрайтов - не олдскул! (этим грешат SNES и GBA).


=A=L=X=
> ...я читаю каждое обновление вашей темы про BlackPrism и мне такие штуки крайне
> нравятся...

За это - отдельный плюс! Спасибо!  Позже лайкну ваши видео, авторизовавшись.

#179
8:08, 11 фев. 2020

Gradius
> Кстати, никогда не понимал, почему SEGA MD и SNES считаются 16-битными приставками?
Насколько я понял принцип довольно простой - битность процессора это не битность шин или даже логических возможностей процессора, но в первую и главную очередь - это битность его ALU.
Та же m68k с самого своего рождения описывает 32-битную процессорную архитектуру и усечение шины адреса до 24 бит чисто прагматичный характер носит - просто не было столько памяти тогда чтобы под неё еще ножки распаивать. Но сами регистры были сразу же 32-битные и верхние биты равноправно участовали во всей арифметике.
Насколько я знаю Apple на этом тоже себе грабли заложила используя верхние биты адреса в своих маках под эту архитектуру и когда переезжать стала на современные версии, то надо было режим совместимости вводить со старым кодом у которого в верхнем байте адреса была служебная информация.
Но так или иначе этот процессор считается 16-битным просто потому что у первых его ревизий - тех самых что были в Sega Mega Drive было 16-битное АЛУ. И все операции с 32-битными данными внутри делались парами как раз через принцип заноса переполнения с предыдущей операции.
В результате Sega нигде не говорила что её Sega Mega Drive 32-битная, хотя логически процессор был именно таким.
Что тут еще интересного - так это то, что операции с данными m68k в сеге делал на 16-битном АЛУ, но вот индексации памяти через адресные регистры (а его 16 регистров общего назначения делились на две равных половины - 8 регистров данных и 8 регистров адресов) сразу в первых же версиях делалась на отдельном 32-битном сумматоре. Это был именно адресный сумматор, не часть АЛУ. Из-за этого на первых ревизиях m68k иногда было выгоднее загрузить данные в адресные регистры и через инструкцию LEA выполнять настоящие 32-битные аппаратно сложения, а потом перемещать их результаты в регистры данных командой MOVE. Тоже своеобразный аппаратно-программный трюк, так сказать.

Страницы: 18 9 10 11 12 13 Следующая »
ФлеймФорумЖелезо