Данному проекту предшествовали изыскания, описанные в статье на моем сайте: «Взломщик Кодов» Simba's - модификация и оптимизации
Также выходом в свет данный проект обязан другому моему проекту: Продвинутая и расширенная редакция утилиты работы с интерфейсом (программатором) перезаписываемых Sega MegaDrive/Genesis картриджей – FlashKit MD
В настоящий момент, спустя чуть больше недели после своего старта и меньше месяца после приобретения мной картриджа этого инструмента, данный проект можно считать завершенным на своей первой стадии.
Для использования ПО, предлагаемого данным проектом, необходимо внесение небольших, но важных изменений в аппаратную часть взломщика с полным сохранением обратной совместимости: вместо ПЗУ-однократки предлагается установить перезаписываемую flash-ПЗУ, а также обеспечить удобные средства для её программирования (см. ссылки выше). Впрочем, ничто не мешает прошить другую однократку в программаторе и запаять её (но так не интересно, и на будущее непрактично).
В разделе релизов доступны актуальные версии и описания ключевых изменение в каждой из них (мелкие корректировки не релизятся).
Последняя актуальная версия альтернативного ПО Mega-CC имеет ряд преимуществ и нововведений в сравнении со стоковым (даже модифицированным) ПО взломщика, соответственно его использование в большинстве случаев предпочтительнее (для меня уж точно) ...
- Минималистичный и максимально быстродействующий интерфейс! Да это мега-благо! И это один из основных моментов подвигших меня на создание этого проекта. Никакой музыки и заставок – ничего лишнего вообще;
- Для запуска игры может потребоваться лишь нажатие кнопки Старт – это займет не более пары секунд максимум (если не нужно менять содержание и набор активных кодов);
- Пока реализован лишь режим ручного ввода кодов. Однако создание или миграция базы кодов в стоковой версии маппера и не планируется вовсе. Т.к. ценность базы внутри имхо может быть невелика (если искать игру дольше, чем вбить код) – куда как важнее возможность интуитивного и быстрого ввода нужных кодов перед запуском и сохранение введенных кодов при отключении питания … И сейчас это есть!
- Почти полностью переписан обработчик патчинга (мини-подпрограмма - «довесок» к VInt) с целью оптимизации времени выполнения и полноты сохранения контекста прерванной программы! А также поддержки новых функции, а именно …
- Добавлен код приостанавливающий процессор Z80 на время работы патчера для минимизации звуковых артефактов (все это в асме – т.к. важна скорость: см. файлик sega.s). Не везде артефакты исчезли полностью – но это уже аппаратный нюанс и лучше чем сейчас быть на данном железе взломщика видимо не может (мгновенный обратный прыжок не минимизирует артефакты более …);
- Введена функция задержки активации фризинга после запуска основной программы (игры) на картридже. В течение нескольких секунд (максимум до 5-ти, см. исходник – пока не выведено в интерфейс пользователя), фризинг дремлет, щелкая счетчиком по кадрам – это дает возможность отработать заставкам и прочим вступительным алгоритмам для которых патчинг может быть нежелательным (т.к. он не для них). Соответственно ряд игр теперь можно начинать штатно – а не выключать при запуске и включать обратно при прогрузке игры наш взломщик;
- Добавлена опция «отложенной» заморозки – для ее активации следует использовать флаг [!] в столбце статуса для любого или каждого кода (циклическое переключение флага по кнопке C). С данной опцией заморозка по этому коду начинается лишь с момента инициализации указанного в коде адреса заданным значением – ведь без разницы что фризить ;-) Таким образом (в добавок к предыдущему пункту) удается устранить коллизии еще в ряде игр, а не прибегать к использованию тумблера;
- Добавлена проверка аппаратно-программной исправности ОЗУ взломщика при старте (о чем выводится информационная строчка), так же после проверки память полностью очищается (что удобно в дальнейшем);
- Реализована функция энергонезависимого сохранения введенных кодов через самопрограммирование картриджа! Нажатием на центр крестовины осуществляется сохранение, а автоматическая загрузка сохраненного ранее - при каждом запуске (подробности см. ниже);
- Да, управление ориентировано под классический «трехкнопочный» джойстик (для максимальной совместимости). При желании можно легко переназначить функции на дополнительные (другие) кнопки или их комбинации.
Удивительно, но, похоже, я первый в мире кто реализовал, в общем-то, такой незамысловатый и весьма полезный функционал в рамках подобного решения. Это в историческом прошлом (30 лет назад и более) картриджи, хранившие основную программу, как правило, в масочном ПЗУ были обречены иметь второй тип памяти на своем борту доступной также еще и для записи с целью хранения игровых состояний и рекордов в энергонезависимом режиме – если стояла такая задача. Как правило, это была микросхема статического ОЗУ с питанием от литиевой батарейки – такое решение было популярно в применении на многих платформах 80х-90х годов прошлого века. Но МегаДрайв и тут занимал лидирующие позиции! – некоторые игры на своих носителях имели уникальную в своем роде (даже по нынешним меркам) память т.н. FRAM. Это фактически тоже статическое ОЗУ, но не теряющее своего содержимого при отключении питания, а еще к тому же не требующее отдельных алгоритмов для его стирания или записи! – пишется как обычная SRAM. Фантастика, но технология оказалась дорогой и невостребованной по критерию объем/цена – увы, канула в лету. Но изящное решение совсем на поверхности! Ведь можно же обойтись все лишь одной микросхемой, но перезаписываемой – пусть и с несимметричными алгоритмами чтения/стирания/записи … Главное не с окошком чтоб, а электрически-стираемой, да еще и при штатном напряжении (т.е. не любая EEPROM подойдет, а вот т.н. «флэш» - вполне). И самое интересное, что подобные flash-ПЗУ фактически современники МегаДрайва! – но их не применяли в картриджах (не исключено что их цена превосходила даже цену FRAM вкупе с масочным ПЗУ). Сейчас же ретро-железо куда как более доступно, а поэтому я, как и многие гики-энтузиасты, воплощаю в жизнь технически правильные и изящные решения. И так. Для энергонезависимого хранения изменяемого в процессе работы программы блока данных («игровое сохранение») достаточно иметь на картридже всего лишь одну микросхему! Текущая реализация альтернативного ПО для аппаратного чит-девайса «Взломщик кодов» может служить примером и отправной точкой для дальнейшего совершенствования и применения концепции внутрисхемного (внутрисистемного) программирования картриджа в приставке без какого-либо дополнительного оборудования (программатора) и ПО к нему. (Это почти как: «кто девушку кормит, тот и танцует» - так и микросхему flash-ПЗУ: главное «кормить» и командовать понятным ей набором слов, никакой магии и программатор отдельный не нужен.) Все достаточно просто: нужно лишь иметь ввиду и учитывать, что при стирании/записи («программировании») даже блоков flash-ПЗУ не задействованных основной программой – на это время становится недоступной для чтения ВСЯ микросхема! Таким образом, выполнение алгоритма, хранящегося в ней, будет нарушено если мы не предпримем один технологический приём: разместим (скопируем) процедуру реализующую функцию стирания/программирования в основном ОЗУ системы, а также предотвратим любые возможные обращения к формально временно отсутствующему ПЗУ (т.е. еще и прерывания запретим, и сопроцессор приостановим). Представленное решение хоть и выглядит незамысловато-примитивно, но придти к нему сишными конструкциями было очень непросто – это в асме легче многое сделать (SGDK терпишь только ради удобства интеграции графического контента). Реализация же непосредственно алгоритма управления массивом памяти микросхемы не сложнее (а возможно даже проще – так как на единых шинах процессора всё и с максимальным быстродействием) чем создание софта под любой из программаторов (что для меня тоже уже дорожка проторенная): читая документацию на микросхему - транслируем алгоритм с английского на язык программирования.
Несмотря на легенду внизу экрана, напишу тоже самое, но по-русски и чуть более развернуто. В текущей версии предусмотрено использование до 10 «кодов», т.е. можно «заморозить» такое же количество байт в ОЗУ МегаДрайва. Формат кода состоит из адреса (два байта смещения в ОЗУ) и байта данных (который будет по данному адресу безустали записываться, вызывая эффект фриза). Адреса можно располагать в любом порядке, более того: строки можно пропускать также в любом порядке! Актуальными будут лишь те, напротив которых в квадратных скобках проставлен символ звездочки (варьируется кнопкой C при курсоре на любой из цифр в данной строке). Строка (код) активируется автоматически при изменении любой из цифр в данной строке – для этого служат кнопки A и B, которые соответственно инкрементируют или декрементируют цифру под курсором (с переносом или заёмом в/из соседнего разряда при переполнении – обычная арифметика). Навигация курсора крестовиной с зацикливанием через края. Кнопка Старт передает управление картриджу в слоте с инициализацией в работу активных кодов.
Для удобства редактирования есть возможность обнуления кода (текущей строки) – комбинация A + B. При запуске ПО взломщика из области flash-ПЗУ (начало 128-ого килобайта) считывается сохраненная там ранее таблица кодов (если содержимое области отлично от чистого состояния 0xFF), т.е. при старте происходит автозагрузка. Как обычно её отредактировав, при желании можно сохранить обратно: нажав на центр крестовины джойстика (все четыре кнопки направлений одновременно). Сохранение возможно в случае если обнаружен поддерживаемый тип микросхемы памяти (пока это Intel PA28F400 или PA28F200) – будет произведена попытка очистки и перезаписи лишь одного блока микросхемы. Если операция стирания провалилась (вдруг, как вариант: питание заниженным оказалось) – смысла пытаться дальше писать нет, выводится сообщение об ошибке, программа зависнуть не должна (в теории). После завершения записи происходит повторное считывание таблицы: её неизменность на экране – гарантия успешной записи. Запуск игры и коды активные в ней не привязаны к хранящейся во flash-ПЗУ таблице: т.е. можно как записать введенные коды перед запуском игры (чтоб повторно их не вбивать потом), так и не делать этого (таблица с активными кодами будет применена только для конкретного старта). Наличие и детект поддерживаемой для перезаписи микросхемы памяти лишь открывает доступ к функции сохранения – все остальное будет работать на любой микросхеме (хоть на однократке). Вобщем хозяин–барин экспериментируйте :-)
Проект на данном этапе, т.е. в стоковой аппаратной реализации, можно считать завершенным … Поэтому первым делом дальше нужно будет обкатать создание и применение новой конфигурации CPLD вместе с обновлением самой CPLD:
- Выпаиваем и монтируем панельку PLCC-44 на плату взломщика (а вместе с этим создаем отладочный адаптер для прошивки CPLD древнейшего семейства MAX-7000);
- Создаем конфигурацию, повторяющую имеющийся функционал (т.к. у нас будет полная обратная совместимость!);
- Фантазируем с расширенным функционалом (места должно хватить, ведь вместо стоковой EPM7032 будет применена EPM7064 - не густо, но в два раза больше): первое и основное – при старте маппить память картриджа в адресное пространство с 4-ого по 8-ой мегабайты (а-ля которое под «второй слот» и CD-ROM иже с ним). Это даст нам возможность не только читать идентификатор игры вставленного картриджа (и делать выборку из базы, например), но и внутрисистемно записывать флэш-картриджи! Интерфейсом связи с компом может быть любой схемотехнически-простейший интерфейс (хоть через порт джойстика) – ведь у нас памяти для буферизации достаточно. В итоге программатором флэш-картриджей будет сам МегаДрайв: софт для него в памяти взломщика и клиентская софтина на ПК, а также прошивка в контроллере, сопрягающем USB и порт джойстика (если какого-нибудь FTDI будет недостаточно).
Внимательный продолжатель данного проекта наверняка заметит конструкции не используемые сейчас: это или альтернативы имеющимся (которым нашлись лучшие имхо варианты), или пригожие для последующего развития (закомментированы или просто алгоритмически пустуют);
Проект написан с использованием SGDK (1.65) в MS Visual Studio Code и полностью открыт (GNU GPL).
Прилагаю копию своей рабочей кастомной (тюнингованной) сборки SGDK 1.65 (+). Цель этого не только просто дать возможность собрать исходники в том виде, в котором это получилось у меня (многие кодеры кладут болт и не указывают даже версию среды, уж не говоря о конфигах и патчах – в итоге херчтособерешь) - но и пользоваться в дальнейшем настроенной сборкой SGDK которая с использованием куда как более свежих версий инструментов действительно генерирует код компактнее, что для МегаДрайва весьма актуально.
PS. Кому не вникать, а сразу воспользоваться - скомпилированный бинарник.
PPS. Если честно, то Степашка (релизёр SGDK) порядком подзатрахал своими фокусами, ставшими уже недоброй традицией, с новыми версиями! Он чё-сука-издевается?! А я вот о чем: на днях тут вышла уже версия SGDK 1.80 – полезных нововведений по большему счету нет, зато да … просто тупо переименовал старые конструкции! Зачем?! Не иначе как специально чтобы переносимости исходников не было! И это уже далеко не в первый раз! Я, как и многие авторы сега-софта, не будем править и «мигрировать» отлаженный код под очередной его бестолковый выхлоп! Ведь даже сделав это – обратной совместимости всё-равно не получится, в любом случае будет жесткая привязка к версии SGDK (к сожалению не последней) … А еще, в очередных «новых» версиях (второй раз уже минимум) он как ишак продолжает тащить за собой старинный gcc и кривые-неоптимальные make-скрипты! Так на примере данного проекта (и версии SGDK 1.65): компилим проект стоковым комплектом SGDK, потом заменяем make-скрипт и пересобираем снова – выигрываем в объеме в два раза! А если еще и gcc и иже с ним обновить – то еще почти в два раза выигрываем! Какого х… я спрашиваю!!! - нам такую дрянь за обновление выдают?!!
Проверил: если в версии SGDK 1.65 исходники данного проекта можно собрать прямо «из коробки» (архива релиза SGDK, и хоть не с оптимальным результатом - но можно), то в 1.70 для успеха придется копировать минимум мои make-скрипты (makefile.gen и makelib.gen). С моими же скриптами, даже в девственных SGDK (без обновления gcc и прочего, только заменив указанные файлы) сборка возможна как в версии 1.65 (и результат уже будет более оптимален), так и в 1.70 … А вот в 1.80 – всё, шиш! Там даже суть капризов понять сложно, когда в других случаях предупреждений-то и нет (при их активации), тут же отлуп. Даже вникать смысла не вижу. Конец.