1.4

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

• Код разделен на отдельные файлы: отделены части касающиеся ОЗУ и ПЗУ взломщика;
• Большая (в сравнении с предыдущими) часть конструкций переписана на ассемблере (*.s - файлы), но некритичные вещи оставлены в с-реализации (в качестве примера такой возможности);
• В оперативу (в качестве «RAM-функций») можно заставлять копироваться как сишный код, так и ассемблерный (см. заголовок asm_dat.i). Но последнее предпочтительнее, т.к. иначе будет требоваться ручная проверка в ходе отладки – ибо неизвестно какого мусора и откудова прилинкуется вместе с сишным кодом (примитивные конструкции SGDK генерят на выходе просто аццкий говнокод на ассемблере!);
• Скорректирована обработка комбинации A + B для избегания ложных срабатываний одной из кнопок при несинхронном их отпускании;
• Удалил старый закомментированный код, который впредь явно не актуален;
• Для сборки использован SGDK с обновленным компилятором и утилитами (см. далее).

К релизу прилагаю копию своей рабочей кастомной (тюнингованной) сборки SGDK 1.65 (+). Цель этого не только просто дать возможность собрать исходники в том виде, в котором это получилось у меня (многие кодеры кладут болт и не указывают даже версию среды, уж не говоря о конфигах и патчах – в итоге херчтособерешь) - но и пользоваться в дальнейшем настроенным комплектом SGDK который с использованием куда как более свежих версий инструментов действительно генерирует код компактнее, что для МегаДрайва весьма актуально. И так, в целом, что скорректировано в SGDK:

• Обновлены средства компиляции кода m68k (и скорректированы make-файлы): вместо архаических 10-летней давности gcc-6 и иже с ним – теперь самосборный (мной) комплект gcc-10 из репозитория проекта marsdev. Экзешники заменить легко, но вот компилировать их (средствами msys64/mingw32) чертовски-долго (больше часа). Так же необходимо учесть, что другая версия «gcc и компании» наверняка будет требовать изменений параметров в make-файлах (а то может запросто получиться кратное увеличение, а не уменьшение объема результата, к примеру). Следует также не забыть снабдить папочку с новыми экзешниками актуальными версиями требуемых библиотек (скопировать из mingw в которой их собирали) – так разработчик marsdev сдуру выложил только бинарники, в результате они не более чем неюзабельный мусор! (у него-то наверняка все работало, если пути прописаны, а вот переносимость – нулевая в итоге). Результат: экономия в размере генерируемого кода в ROM-картриджа - до двух раз!;
• Компоненты SGDK по обработке ресурсов являющиеся java-приложениями также пересобраны из прилагающихся исходников и вместе с этим добавлены упакованные в exe-формат их экземпляры для удобства запуска из командной строки или батников (если будет нужно вдруг);
• Скорректированы (по необходимости и для единообразия) и пересобраны все тестовые примеры SGDK;
• Старые файлы из комплекта SGDK не удалены, а переименованы в *.bak (можно удалить);

Попутно напомню, что для фиксации и применения любого изменения в исходниках SGDK необходимо заново осуществлять сборку объектной библиотеки libmd.a (запускать build_lib.bat), т.к. при компиляции и сборке сега-приложения (скриптом makefile.gen) она будет просто прилинкована в части касаемой в бинарном виде (невзирая на текстовые исходники и их наличие).

Переходить на следующую версию (1.70) с текущей моей (1.65) – смысла не вижу никакого, от слова совсем!

1.3

• Реализована функция «отложенной» заморозки – для ее активации следует использовать флаг [!] в столбце статуса для любого или каждого кода (циклическое переключение флага по кнопке C). Классический режим [*] (как в стоке) также остался и доступен без изменений.

В отличие от Game Genie, где код отрабатывает зачастую лишь единожды (в начале игры на этапе инициализации переменных) и поэтому его цель, как правило, записать максимальное количество «ресурса» (чтоб на всю игру хватило, ведь расходоваться он будет штатно) – Взломщик кодов корректирует ячейки памяти за секунду многократно! А раз так то формально без разницы какое значение мы будет фризить взломщиком: хоть максимально возможное, хоть штатное, хоть какое еще … ведь оно все равно для игры меняться не будет! Получается что смысловая нагрузка байта как записываемого значения в полной мере не раскрывается. Однако при этом нередко на этапе предшествующему игровому процессу (заставки, настройки и т.п.) ячейки памяти, где хранятся впоследствии данные об игровых ресурсах, которые мы намерены заморозить, будут использоваться для иных целей, а их фризинг с самого начала может привести к зависанию. Ранее я в попытке обойти данную коллизию реализовал задержку запуска патчинга (до 5сек.) – это имеет право на жизнь, но время запуска (пропуска всех заставок) у разных игр разное. Есть игры, которые реально быстрее чем за 30сек. не запустишь! Выделять лишний байт под счетчик и отдавать управление им пользователю? Придумал способ поизящнее: будем начинать фризинг лишь тогда, когда нужная нам ячейка получит волей игровой программы ожидаемое нами значение (а до этого пусть живет как хочет)! В теории, конечно, такой алгоритм может сработать и раньше ожидаемого (но не ранее 5сек.) – но на практике оказалось что это еще как успешно работает! Получается что в коде мы должны указать не «заоблачное» (или в целом произвольное) количество игрового ресурса (для заморозки-то оно все равно), а именно штатное – которое как только появится, так и будет дальше уже фризиться.

1.2

• Реализована функция энергонезависимого сохранения введенных кодов через само-программирование картриджа! Проект на данном этапе, т.е. в стоковой аппаратной реализации, можно считать завершенным … При запуске ПО взломщика из области flash-ПЗУ (начало 128-ого килобайта) считывается сохраненная там ранее таблица кодов (если содержимое области отлично от чистого состояния 0xFF). Т.е. при старте происходит автозагрузка. Её как обычно можно отредактировать и при желании сохранить обратно, нажав на центр крестовины джойстика (все четыре кнопки направлений одновременно). В случае если обнаружен поддерживаемый тип микросхемы памяти (пока это Intel PA28F400 или PA28F200) – будет произведена попытка ее очистки и перезаписи (лишь одного блока микросхемы). Если операция стирания провалилась (вдруг, как вариант: питание заниженным оказалось) – смысла пытаться дальше писать нет, выводится сообщение об ошибке, программа зависнуть не должна (в теории). После завершения записи происходит повторное считывание таблицы: её неизменность на экране – гарантия успешной записи. Запуск игры и коды активные в ней не привязаны к хранящейся во flash-ПЗУ таблице: т.е. можно как записать введенные коды перед запуском игры (чтоб повторно их не вбивать потом), так и не делать этого (таблица с активными кодами будет применена только для конкретного старта). Вобщем хозяин–барин экспериментируйте :-)

1.1

• Почти полностью переписан обработчик патчинга с целью оптимизации времени выполнения и полноты сохранения контекста прерванной программы! А также поддержки новой функции, а именно …
• Введена функция задержки активации фризинга после запуска основной программы (игры) на картридже. В течении нескольких секунд (максимум до 5-ти, см. исходник – пока не выведено в интерфейс пользователя), фризинг дремлет щелкая счетчиком по кадрам – это дает возможность отработать заставкам и прочим вступительным алгоритмам для которых патчинг может быть нежелательным (т.к. он не для них). Соответственно в ряде игр можно начинать штатно – а не выключать при запуске и включать обратно при прогрузке игры наш взломщик;
• Нешустро, но верно движемся к реализации «сохранений». Т.е. к функционалу «внутрисеговской прошивки» картриджа. На текущий момент пройдена значительная часть, хоть и выглядит всего-лишь как чтение идентификатора микросхемы флэш-ПЗУ. Но для этого нужно код в оперативу мигрировать (т.к. ПЗУ для чтения адекватного содержания недоступна будет) – т.н. «ramfunc» (представленное решение выглядит примитивно, но придти к нему сишными конструкциями было очень непросто – это в асме легче многое сделать);
• А по этому также обкатан вариант интеграции в основной сишный код асм-функций из соседнего файла (но в оперативу их засунуть изящно пока не удалось, костыльно – не хочу), как всегда комментирование старого предпочел удалению;
• По мелочам: для дальнейшего удобства добавлена опция обнуления строки с кодом – кнопки A + B.

1.0

• Минималистичный и максимально быстродействующий интерфейс! Да это мега-благо! И это один из основных моментов подвигших меня на создание этого проекта. Никакой музыки и заставок – ничего лишнего вообще;
• Для запуска игры «насквозь» (без кодов) достаточно просто нажать кнопку Старт – это займет не более пары секунд максимум;
• Пока реализован лишь режим ручного ввода «кодов» при каждом горячем (ре)старте системы. Однако создание или миграция базы кодов в стоковой версии маппера и не планируется вовсе. Т.к. ценность базы внутри имхо может быть невелика (если искать игру дольше, чем вбить код) – куда как важнее возможность интуитивного и быстрого ввода нужных кодов перед запуском … И сейчас это есть!
• Мини-подпрограмма патчинга ОЗУ приставки («довесок» к VInt), как и формат таблицы патчинга в ОЗУ взломщика реализованы без существенных изменений (там не так уж все и плохо было). При этом добавлен код приостанавливающий процессор Z80 на время работы патчера для минимизации звуковых артефактов (все это в асме – т.к. важна скорость: см. файлик sega.s). Также внимательный продолжатель данного проекта наверняка заметит конструкции не в полной мере используемые сейчас, но имхо пригожие для последующего развития (закомментированы или просто алгоритмически пустуют);
• Добавлена проверка аппаратно-программной исправности ОЗУ взломщика при старте (о чем выводится информационная строчка), так же после проверки память полностью очищается (что удобно в дальнейшем);