В этой статье я хочу разобрать внутреннее устройство легендарной игры Sonic the Hedgehog для приставки Sega Mega Drive, а также способы ее модификации или, как еще говорят, хакинга. Эта игра насчитывает порядка сотни хаков, включающих как действительно достойные работы (такие как Pana Der Hejhog или Sonic Remastered), так и странные и даже жутковатые (вроде An Ordinary Sonic ROM Hack). Чтобы понять, как их создавать, нужно разобраться, как писать на языке ассемеблера Motorola 68K (обычно игры для приставок тех времен писались именно на ассемблере), откуда взять дизассемблированный вариант игры и какую архитектуру имеет ее движок.  Дизассемблирование ROM-файлов для Sega осуществляется при помощи коммерческого дизассемблера и дебаггера IDA Pro. Затем происходит кропотливый процесс разметки, структурирования и причесывания сырого ассемблерного кода с использованием дебаггера (и смекалки). Этот процесс требует хорошего понимания технических особенностей платформы Sega Mega Drive и игр для нее. К счастью, на GitHub уже есть дизассемблированные и размеченные версии всех игр серии Sonic the Hedgehog, созданные энтузиастами при поддержке сайта Sonic Retro. Лучше всего размечен и структурирован исходный код именно первой игры серии. Эта версия кода находится в репозитории sonicretro / s1disasm и именно она будет разобрана в статье. Погружение в внутреннее устройство игрушки начнем с теории. Sega Mega Drive (известная в США как Sega Genesis) оснащена 32-битным центральным процессором Motorola MC68000 (сокращенно Motorola 68K) и дополнительным звуковым сопроцессором Zilog Z80 (взамодействие с Z80 происходит через общую память). Объем оперативной памяти (RAM) – 64K. Разрешение экрана в основном режиме (в американской версии) – 320x224 пикселей. Использованный процессор Motorola 68K в свое время был достаточно распространен. Этот чип применялся в самых разных системах, от популярных домашних компьютеров и игровых приставок до космических шаттлов. Одна из модификаций Motorola 68K даже была установлена в легендарном Apple Macintosh. Графическая подсистема Mega Drive основана на видеоконтроллере Yamaha YM7101 и поддерживает аппаратную работу с двумя слоями фона и отрисовку до 80 спрайтов поверх них. Подробнее графика в игре будет разобрана далее; прочитать о графике в Sega Mega Drive отдельно можно в статье "Как работала графическая система Sega Mega Drive: Video Display Processor". Для сборки игры используется макроассемблер AS. Набор инструкций этой платформы совершенно не сложный и содержит всего 82 инструкции. Для сравнения: по подсчетам пользователя ResearchGate современный Intel Core i7 имеет 338 инструкций. Процессор имеет восемь 32-битных регистров общего назначения: D0–D7. Все эти регистры активно используются в играх для хранения промежуточных данных и в качестве операндов арифметических операций. Также существует восемь специальных адресных регистров A0–A7. Адресные регистры оптимизированы для хранения указателей на какие-либо объекты в памяти и их использование в некоторых операциях невозможно. Последний адресный регистр A7 по совместительству работает указателем стека и имеет алиас SP. Большинство инструкций могут работать в одном из трех режимов разрядности. Суффикс .l (long) обозначает работу в 32-битном режиме. При использовании суффиксов .w (word) и .b (byte) процессор будет работать только с младшими 16-ю или 8-ю битами каждого из операндов соответственно. Разберем основные инструкции Motorola 68K. move – скопировать данные из источника в приемник. Примеры: Как видно из примеров выше, для записи десятичных чисел в этом ассемблере используется префикс #. Для записи шестандатиричных числе используется префикс #$. При записи операнда в скобках вычисление происходит со значением по такому адресу в памяти: Такой режим адресации возможен только для адресных регистров (a*). Примеры: Примеры: Для выполнения условных переходов в процессоре 68K используется регистр CCR (Condition Code Register). Инструкции cmp, tst и btst позволяют выставить биты (флаги) этого регистра, которые затем используются в операциях условного перехода beq, bne, bge, ble и других. Примеры: Более подробно изучить команды Motorola 68K вам поможет отличный мануал (с ужасным фоном и шрифтами) автора Марки Джестера, где каждая из команд разобрана максимально подробно. Репозиторий s1disasm содержит Python-скрипт, автоматически запускающий нужную версию ассемблера для текущей операционной системы со всеми необходимыми флагами. Также этот скрипт выполняет специфическую для игры Sonic the Hedgehog операцию "Kosinski compression", которая сжимает карты уровней и другие бинарные данные (чтобы они поместились в память картриджа). Все, что нужно сделать пользователю, это перейти в git-ветку AS (git checkout AS) и выполнить команду: Результатом выполнения скрипта должен стать готовый ROM-файл игры с названием s1built.bin. Этот файл можно запустить в вашем любимом эмуляторе Sega Mega Drive. Для macOS, например, рекомендуется использовать замечательный OpenEmu. Начнем обзор с основной точки входа для сборки игры – файла sonic.asm. В нем находятся процедуры инициализации: ожидание готовности сопроцессора Zilog Z80 (WaitForZ80), установки параметров видеопроцессора (VDPSetupGame) и проверка контрольной суммы. После инициализации игра выполняет подпрограмму GameInit и переходит в главный цикл MainGameLoop, задачей которого является считывание переменной глобального игрового режима и запуск соответствующему ему кода. Полный список глобальных переменных, используемых игрой вынесен в файл Variables.asm. Каждая переменная представляет собой константу со ссылкой на адрес в RAM, где должно храниться значение переменной. Глобальный игровой режим хранится в переменной v_gamemode. Список глобальных игровых режимов включает в себя: В строке move.b #id_Sega,(v_gamemode).w подпрограммы GameInit в переменную v_gamemode заносится режим, в котором игра должна стартовать. Если заменить id_Sega на id_Title и собрать игру командой ./build.py, то мы получим первый рабочий хак, в котором вместо отображения экрана "Sega" игра сразу приветствует нас титульным экраном, что может сократить время дебага. Переменная v_gamemode определяет подпрограмму для главного цикла, которая должна исполняться в данный момент. Например, в режиме id_Title приставка будет исполнять подпрограмму GM_Title, а в режиме id_Level – GM_Level. Многие переменные, объявленные в файле Variables.asm представляют интерес для хакинга. Рассмотрим для примера v_sonspeedmax, v_sonspeedacc и v_sonspeeddec. Изменяя значения, помещаемые в эти переменные в подпрограмме Sonic_Main, можно изменять динамические характеристики перемещения Соника: максимальная скорость, значение ускорения и торможения соответственно, получая интересные результаты: Дробные переменные хранятся в формате с фиксированной точкой, поэтому для получения реальных значений их необходимо разделить на 256. Так, ускорение Соника составит 0xC / 256 = 0.046875, а торможение – 0x80 / 256 = 0.5 (пикселей на игровой цикл в квадрате). Графикой в Mega Drive занимается тайловый графический процессор Sega 315‑5313 (Video Display Processor, VDP). Конфигурирование VDP производится с помощью регистров, запись в которые производится через специальные адеса в памяти vdp_data_port и vdp_control_port. Изначальная конфигурация процессора устанавливается в подпрограмме VDPSetupGame, которая берет параметры по адресу VDPSetupArray. Однако, в каждом из глобальных игровых режимов, некоторые регистры выставляются повторно. Например, на игровых уровнях это делает подпрограмма GM_Level. Подробное описание функций всех регистров VDP приведено в вики Sega Retro. Для примера приведем скриншот игры с включенным режимом Low Color (нулевой бит регистра Mode Register 1 выставлен в ноль): Video Display Processor позволяет аппаратно работать с двумя фоновыми слоями – background (слой B) и foreground (слой A), а также со слоем спрайтов, которые отображаются поверх фона. Фоновые слои собираются из тайлов 8x8 пикселей с помощью карт тайлов. Спрайты также собираются из тайлов; максимальный размер спрайта – 4x4 тайла. Таким образом, максимальный размер аппаратного спрайта составляет 32x32 пикселя. Удаление кода из подпрограмм работы с фоновыми слоями (LoadTilesAsYouMove, DrawChunks) и спрайтами (BuildSprites) позволяет понять, какие из игровых объектов к какому слою относятся: Как видно из названия, подпрограмма LoadTilesAsYouMove занимается подгрузкой тайлов на фоновые слои по мере продвижения игрока по уровню. В игре Sonic the Hedgehog размер обоих тайловых плоскостей составляет 64x32 тайла или 512x256 пикселей. Графический процессор также позволяет устанавливать не только общее смещение фонового слоя, но и смещение его отдельных горизонтальных рядов тайлов, используя так называемую таблицу скроллинга. Эта возможность позволяет перемещать удаленные элементы фона медленнее, чем близкие. Таким образом создается эффект параллакса, который имитирует 3D-графику и придает сцене объем. Этот эффект используется почти во всех уровнях Sonic the Hedgehog. Эффект параллакса в фоновом слое уровня Marble Zone: Движок игры выделяет 8192 байта в RAM на хранение состояния динамических объектов сцены. Вся эта информация хранится по смещению v_objspace. К динамическим объектам относится все объекты на уровне, кроме стен и пола. Примеры: Соник, враги Соника, мониторы с бонусами, кольца, пружины, Босс и так далее. При необходимости объекты отрисовывают себя в слое спрайтов при помощи подпрограммы DisplaySprite.  Размер данных состояния игрового объекта статичен и составляет 64 байта. Эта информация формирует структуру, поля которой могут быть получены с использованием макросов, объявленных в файле Constants.asm. Адрес структуры данных текущего обрабатываемого игрового объекта обычно заносится в регистр a0. Таким образом, данные игрового объекта могут быть считаны так: Отметим, что система координат в игре типична для экранной графики и имеет ось X направленную вправо, и ось Y, направленную вниз. Подпрограмма ExecuteObjects вызывается на каждом шаге главного цикла уровня. Она последовательно вызывает программный код каждого из игровых объектов, присутствующих на сцене. Список указателей на программный код каждого из объектов задан в таблице в файле Object Pointers.asm. Программный код большей части объектов вынесен в отдельный файл в каталоге _incObj. Многие из объектов имеют по несколько подпрограмм, которые соответствуют разным этапам жизни объекта (например, только что созданный объект, объект в рабочем состоянии, "предсмертное" состояние). В этом случае номер подпрограммы, которую необходимо выполнять сейчас, хранится в поле obRoutine. При необходимости передвижения объекта с заданной скоростью вызывается специальная подпрограмма SpeedToPos. Она интегрирует скорость текущего объекта, прибавляя ее значение к его координатам. В качестве примера реализуем довольно простой хак, который может понравиться самым ярым фанатам игры: no-ring challenge. Этот хак предлагает пройти игру без золотых колец. В результате, каждая атака Соника будет сразу убивать его и заставлять игрока проходить уровень заново (либо с точки сохранения). Перейдем в главную подпрограмму объекта "Кольцо" – Ring_Main и добавим в самое ее начало простейшую инструкцию прыжка (bra) на процедуру удаления кольца: С бонусными мониторами поступим так же. Главная подпрограмма объекта "Монитор" находится в файле 26 Monitor.asm. Тип монитора хранится в поле obSubtype размером 1 байт. Экспериментальным методом выяснено, что значение для монитора с кольцами равно 6. Добавим простую проверку типа монитора с помощью инструкции cmp и условный прыжок beq на процедуру его удаления в случае, если его тип равен шести: Можно убедиться, что в получившемся ROM'е кольца и бонусные мониторы с кольцами на уровнях будут отсутствовать, что усложнит прохождение. Патч целиком можно посмотреть на GitHub. Туда же выложен готовый бинарник на случай, если кто-то захочет поиграть в такую версию игры, не разбираясь со сборкой. В первой и второй играх серии бонусный щит только защищает игрока, но при этом не имеет никаких дополнительных функций. Попробуем его улучшить и добавить к нему возможность электрического щита из Sonic the Hedgehog 3 – притягивание колец. Алгоритм, использующийся для этого эффекта, подробно описан в вики Sonic Retro. Если персонаж, обладающий электрическим щитом, находится ближе, чем в 64 пикселях от кольца по каждой из осей, кольцо переходит в режим намагниченности и начинает движение. В дальнейшем этот флаг больше не снимается с кольца. В режиме намагниченности кольцо ускоряется на 0.1875 за каждый шаг в сторону игрока, если оно уже движется в нужную сторону по данной оси. Если же кольцо движется от игрока, ускорение составляет 0.75. Разница в значениях предусмотрена для того, чтобы кольца с одной стороны не слишком перестреливали, но, с другой стороны, если перестрел уже случился либо если игрок движется быстро и резко оказывается с противоположной стороны, быстро "исправлялись" и меняли свое направление движения. Изучим подробнее исполняемый код объекта "Кольцо", который находится в файле 25 & 37 Rings.asm. Список подпрограмм объекта: Кольцо имеет несколько жизненных этапов: Main – инициализация; Animate – обычное висение с анимацией вращения; Collect – момент сбора Соником; Sparkle – анимация искр при сборе Соником; Delete – удаление кольца. Для того, чтобы изменить поведение кольца в обычном его состоянии, смотрим в сторону подпрограммы ptr_Ring_Animate. Для хранения состояния намагниченности кольца отлично подойдет однобайтное поле obStatus. Анализ кода кольца показывает, что в этой версии игры флаги состояния для этого объекта не используются. Назначим нулевой бит obStatus (наиболее младший) ответственным за хранение флага намагниченности. Установка отдельного бита ячейки памяти будет возможна с помощью инструкции bset, а проверка, установлен ли он – с помощью инструкции btst. Добавим в начало подпрограммы Ring_Animate код, устанавливающий флаг намагниченности в случае, если игрок ближе к кольцу, чем на 64 пикселя по каждой оси: Реализация алгоритма предполагает разное ускорение в зависимости от того, летит кольцо в сторону игрока или нет, что по сути может быть представлено как сравнение знаков значений скорости кольца и разницы положений кольца и игрока. В псевдокоде такое сравнение может иметь примерно такой вид: Для простой реализации такого сравнения вспомним, что способ хранения знаковых целых чисел в большинстве процессоров (включая Motorola 68K) подразумевает возможность определить знак числа простым считыванием самого старшего бита, причем 0 будет обозначать положительное число, а 1 – отрицательное. Проверить равенство битов в байте можно с помощью операции исключающего "или" – XOR (eor на Motorola 68K). Как уже было отмечено выше, дробные значения (включая скорость игровых объектов) хранятся в формате с фиксированной точкой, поэтому необходимые значения ускорения (0.1875 и 0.75) необходимо домножить на 256 (получив 48 и 192 соответственно). Реализуем процедуру притягивания колец: Для того, чтобы кольцо действительно осуществляло движение согласно установленным скоростям, необходимо добавить вызов упомянутой выше подпрограммы SpeedToPos: Собираем итоговый ROM игры, запускаем и — вуаля — фича из Sonic 3 доступна в Sonic 1! На GitHub можно просмотреть патч целиком, а также скачать получившийся бинарник. Эта статья является лишь базовым разбором методов модификации игры. Статья не рассматривает инструменты для редактирования уровней (SonED2, Chaos), создание новых персонажей, игровых объектов и механик. Также не рассмотрен симулятор/отладчик Motorola 68K EASy68K, который может помочь более пристально разобраться, как работает процессор Sega. Тем не менее, я получил большое удовольствие, покопавшись в кишках любимой игры детства. Надеюсь, этой статьей мне удастся разбудить в ком-то такую же ностальгию, к тому же черпать вдохновение для работы можно и из сотен уже реализованных хаков, и из последующих игр серии. Senior Pomidor Developer