Делаю кроссплатформенный эмулятор Atari 2600

[erobson]

Недавно я решил сделать эмулятор 2600-ой атари. Тему здесь создаю, чтобы писать дневники разработчика + скрины. Я постараюсь полностью описать устройство и эмуляцию этой платформы, затем собрать в одну цельную статью. Сейчас работаю над тиа. Вообще, тема довольно интересная, хочется попробовать её портировать на максимум платформ и в приоритете PS1/PSX. Я надеюсь, железа хватит для эмуляции TIA и 6502.
Пока же делюсь скрином нерабочей графики 

[Sharpnull]

в приоритете PS1/PSX. Я надеюсь, железа хватит для эмуляции TIA и 6502.

Для 6502 хватит, если будете писать на ассемблере (есть ImbNES), а простой код на языке C, где читается один байт и интерпретируется будет слишком медленно. Я пробовал писать один эмулятор для PSX с 8-битным процем на C, у меня было медленнее раза в 4 и это без звука и с низкой точностью. Исходный код ImbNES есть, разбирайте.

[erobson]

Sharpnull, да, знаю про imbnes, читал его.  Код я сделал максимально простым. Критические инструкции, или сам switch по возможности перепишу на asm. Благо, mips ассемблер хорошо описан на просторах нета. Вот у меня такой switch:

[Skay]

EgorInventor, кросплатформа и писать куски на asm?)
почему за место свича не делать сразу таблицу переходов? Свитч же в случае пропусков индексов, повторений - будет генерировать лишние вспомогательные таблицы и тд.

[Sharpnull]

почему за место свича не делать сразу таблицу переходов?

Массив указателей на функции? Это вроде не поможет всё равно со скоростью.

кросплатформа и писать куски на asm?)

Хорошее замечание, там мало что может остаться от общего кода после всех оптимизаций.

[erobson]

Sharpnull,  Но кроссплатформа-то липовая!  Как обычно в cmake ручками под каждую платформу свои исходники.

[Skay]

Но кроссплатформа-то липовая!

ну вооот(

Массив указателей на функции? Это вроде не поможет всё равно со скоростью.

из правильно подготовленного switch/case обычно и делается таблица переходов, а не куча ифов) но если появляются пропуски, неравномерности и тдд - там получается хренпойми что. Так что если самим организовать сразу таблицу - просто гарантированно не будет лишнего.

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

[erobson]

Skay, Основное, что удерживает меня от создания таблицы переходов вместо switch - это то, что для инструкций, работающих с памятью, функции режимов арресации возвращают адрес в массиве internalMemory. А если инструкция кушает не адрес, а данные, тогда я вызываю её обработчик так:

p.s. как-то странно объяснил 

[SPOT]

EgorInventor, Вы сначала делаете эмулятор для ПК, а потом будитет портировать его на PSX или же сразу пишите для PS?

[erobson]

SPOT, Сначала делаю графику на SDL2 для пк, потом по ходу буду переделывать её на psx(PSYQ SDK). Пока цель получить нормальную статичную картинку с fps-ом 60

[erobson]

Ура, товарищи! Картинка!

[erobson]

А следом за ней ещё более правильная картинка! На фото видно, что есть расхождения по палитре, которые предстоит вычислить и исправить.

[SPOT]

Не эксперт в Atari 2600, но может расхождения в палитре и нет. Может там не RGB, а как в NES.

[erobson]

SPOT, Я взял цвета с сайта про atari. Затем с помощью python скрипта преобразовал в массив rgb:

Загвоздка в SDL, она не ест ничего кроме rgb)

[SPOT]

Есть какой-то прогресс?

[erobson]

Пока я загружен учёбой, прогресса нет. Однако я в свободные минутки изучаю информацию по PSX

[erobson]

Потерпел фиаско. Почти все опкоды, кроме прерывания и TAX, TAY, T(XX) реализованы. Тут оказалось, что разные опкоды занимают разное кол-во машинных ТАКТОВ! Но в том руководстве которое я читал, такты обозвали ЦИКЛАМИ    Из-за этого в моей реализации каждый опкод - 1 цикл, а такты попросту опущены((  Буду переделывать на днях.

P. S. А ещё я забыл делать комиты, поэтому изменения в 700 строк висят все в одном комите.

[SPOT]

Главное что работа идёт, а то я боялся, что забросил))

[erobson]

SPOT, Не, по крайней мере, до полноценного запуска pac-man я не остановлюсь). И не ожидал, что эта тема окажется так интересна.

[erobson]

Чтобы не мудрить со всеми свичами, циклами и режимами адресации, я делаю очень просто - двумерный массив структур:

Код: [Выделить]

struct OpCode{
void* handler; //Указатель на обработчик
int cycles; //Сколько циклов занимает
AddrType addressing; //Режим адресации
};Потом беру из массива internalMemory 1 байт, и по этой таблице его обрабатываю. Я думаю, это будет быстрее и надёжнее всяких switch'ей, к тому же, всё в одном месте. Так как массивы хранятся в памяти  просто подряд, и поля структур тоже, то проблем с оптимизацией не будет. Плюс, можно сделать фиксированное кол-во бит для каждого поля структуры, не допуская лишних ноликов(такое бывает).

[Skay]

P. S. А ещё я забыл делать комиты, поэтому изменения в 700 строк висят все в одном комите.

только так и учатся пользоваться гитом)) просто читать про то как надо - мало.

И не ожидал, что эта тема окажется так интересна.

Там много еще интересного) JIT, сначала однородный, потом с промежуточным представлением и т.д. Оптимизации наборов инструкций под целевую платформу)

[erobson]

Skay, Если я ничего не путаю, то jit нужен только для оптимизации языков с байт-кодом, каковым родной СИ не является. А по поводу гита - да, наболевшая тема. Я с ним давно, но постоянно про него забываю.

[Skay]

EgorInventor, в эмуляции это тоже применимо.
Очень грубо говоря и косноязычно: Ты независимо от потока в котором исполняешь, читаешь инструкции, перемалываешь их (в т.ч. с оптимизациями) и выстраиваешь очередь с инструкциями понятными для твоей платформы. И вот эту очередь команд, уже выполняешь.

[erobson]

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

[Skay]

EgorInventor, jit это если только в следующую итерацию, для начала надо это заставить работать.

https://bheisler.github.io/post/experiments-in-nes-jit-compilation/

[erobson]

Я вернулся. Последние комиты - таблица переходов, исправление багов, палитру по прежнему не переделал, да и не особо надо пока.

[erobson]

Наконец придумал способ реализовать tia, и скоро приступлю! Идея заключается в том, чтобы при записи по соответствующим адресам в некий стек складывать указатели на обработчики того или иного события, затем в цикле тиа обрабатывать это самое событие. Если при портировании будет замечена потеря в производительности, можно будет сделать систему приоритетов.

[erobson]

Начал работать с ассемблером Mips, чтобы сразу начать переносить на нужную платформу. Пока ничего нового по функционалу нет, кроме исправления багов с счётчиком кадров.

[erobson]

Offtop: Решил использовать Psn00bSDK, т. к. он поразительно удобный и быстрый.
P.S. А ещё все эмуляторы, кроме no$psx - бяка.

[erobson]

Делаю собственную графическую библиотеку специально под windows, так как слишком много лишнего winapi-кода просачивается в логику эмулятора. От использования SDL окончательно отказался, он слишком медленный.
Пишу в свободное время, а его катастрофически не хватает