Pull to refresh

Comments 77

А нельзя ли автоматизировать подход, путем поиска опкода инструкции по записи в память? Возможны, конечно, ложные срабатывания, но, думаю, что это сильно сузит круг подозреваемых мапперов, особенно для опытного специалиста. Можно вообще даже сделать эвристику, зная то, как ведут себя извесные мапперы.

P.S.: Я имею ввиду автоматизированный подход без использования дизассемблера
Там могут быть очень хитрые условия переключения банков. Но если заранее знать, что в картридже стоит какой-то из популярных мапперов, то теоретически можно сделать. Но в таких случаях проще перебором.
Я так понимаю, что в любом случае переключение осуществляется через запись в память, поэтому отправная точка — это поиск этого места в бинарном коде.

Ну и ламерский вопрос: а взор с лупой на микросхему не даёт ответа на этот вопрос?
Да, но эта операция может выполняться очень условно. Не всегда очевидно, как оно работает.
Если картридж оригинальный лицензионный, то там обычно видно, какой стоит маппер (на фото в посте как раз есть), но в современных китайских стоят бескорпусные микросхемы.
Там походу эмулятор исполняет игру, и когда случается write, эмулятор прерывается даёт сигнал дамперу о том, что появился новый банк.
Запись в память картриджа не всегда переключает банки, иногда это может делаться много раз в секунду. И не только запись в область картриджа может переключать банки.
Да, но видимо эмулятор знает про разные типы эмуляторов и фильтрует неимеющие к переключению банков записи.
Так смысл тогда теряется, если эмулятор знает :) В таком случае проще картридж целиком сдампить и эмулировать. Ретрон вроде так и делает.
Как это смысл теряется? Эмулятор тут как раз вспомогательный инструмент для того, чтобы сдампить картридж и не ковыряться в ассемблере.
Вы противоречите сами себе. Если софт уже знает маппер, то уже не нужно ни ковыряться в ассемблере, ни использовать эмулятор. А если не знает, то возникает вышеописанная проблема.
Секундочку. Софт не знает маппер априори. Но может догадаться эвристически, зная как управляются известные софту мапперы и видя как и куда происходит запись. Это можно автоматизировать. А руками и глазками придется искать дольше.
Слишком уж многие мапперы реагируют на абсолютно одинаковые операции, но дают разный результат. Но вообще да, теоретически так можно автоматически определять их. Но смысл всё равно сомнительный. Всё несдампленное обычно на каких-то ещё неизвестных мапперах.
Ха, вот это мой девайс. С эмулем все как раз просто: программа сама говорит когда и что записать, Копифамиклон просто пересылает в эмуль изменившиеся данные. Так как это требует некоторого времени, эмулятор их кеширует. Так что самый 100% вариант дампинга неизвестной игры — прогнать ее на таком устройстве. С другой стороны, в игре могут быть неиспользуемые блоки или для дампинга некоторых придется пройти всю игру.
А как оно узнаёт, когда данные изменились? Устройство держит в себе какой-то кеш и уведомляет эмулятор при изменении данных? Эмулятор же в таком случае должен каждый раз к железу обращаться, разве нет? Или проверка идёт только после записи в 0x6000-0xFFFF?
Никакого кэша в железе. Действительно, в эмуляторе ведется мониторинг записи в адреса 0x6000-0xFFFF, при обнаружении таковой, эмуляция ставится на паузу и делается подобная запись на копифамиклоне. Затем вычитывается новое состояние, которое кэшируется эмулятором. И так до следующей записи.
Но этот метод не является 100% универсальным. И для полноценного дампа надо же всё равно вручную разбираться в принципах работы маппера.
Он таки как раз универсален и не зависит от маппера вообще. А вот 100% полноту дампа не гарантирует, о чем я и сказал выше.
Ну просто нет гарантии, что маппер реагирует именно на запись в 0x6000-0xFFFF, хоть это и в 99% случаев так. Ну и потом всё равно надо сидеть и разбираться, где какой банк, и как они переключаются, чтобы сделать полноценный ROM.
А вы не имели опыта «пересадки» палитры? Я знаю из какой игры заставка в последней многоигровке — это «Король Лев» для сеги и там нормальные цвета, есть пиратский порт на фамиком — но там цвета тихий ужас (подозреваю что пираты повредили палитру), я все пытался — но неосилил.
А на NES скорее всего красивее и не сделать из-за ограничений палитры. В пиратском порте Короля Льва на NES вроде такие же цвета, если мне память не изменяет.
UFO just landed and posted this here
Именно пиратского порта со SNES? У меня есть, есть ещё порт на MMC3.
Есть — вечером могу скинуть, на NESTOPIA идет на ура, но там явно «битая» палитра, Игра выглядет по краскам где-то уровня 2600 атари.
UFO just landed and posted this here
По ссылке ниже ужаснейший официальный порт с геймбоя. Это очень странный случай, когда пиратский порт на голову выше по качеству.
У меня есть порты от конторы «Supergame». Если надо, пишите в личку.
Шикарно! Спасибо. Сильно ли отличаются картриджи для Sega, SNES, N64?
По поводу переключения банков памяти пока не вникал, но везде вплоть до GBA принципы похожие — память с параллельным доступом, которая включается прямо в шину. Потом стали использовать последовательный доступ и шифрование.
Помню, в 90х годах я сдампил один многоигровой картридж с маппером. Шел тем путем, как описанные в статье первопроходцы: сначала сдампил первый банк, потом продизассемблировал его (код меню выбора и запуска игры). Нашел, как программируется маппер и тогда уже считал (подключив картридж через переходник к программатору УФППЗУ) из него все данные. Получилось 256Кб, из них 128 — графика.

При этом дизассемблер 6502 был собственной разработки. Он работал на ZX Spectrum (кросс-дизассемблер). Все это делалось в рамках проекта «контроллер дисковода для Dendy». Проект так и не был завершен, не в последнюю очередь — из-за мапперов и прочей аппаратуры, которую ставили на картриджи и которую никак нельзя было в универсальном виде поставить на контроллер дисковода. Ну и из-за обнаружившейся чрезвычайной трудоемкости считывания и адаптации картриджей. Над каждым пришлось бы корпеть днями.
О, спасибо! Первая интересная статья в этом году.
Отличная статья!

Кстати, не помешал бы мощный холивар на хабре на тему рейтинга консольных игр. У меня сейчас в PSP почти всё, кроме NeoGeo. Реально доставляет запускать игру 1981 года и играть, получая удовольствие. Ъ игр уже почти не делают.
Инетесно :) не только статьи Ализара угадываются по заголовку
Отнюдь. Про «умный дом» не было )
А про приставки было.
Половину статей ClusterM по заголовку угадал, когда они выходили :)
А сделали бы адресацию сразу 32-х битной и проблемы бы такой не было как класса.

P.S.
Будешь много играть на приставке — сядет трубка :P
32-х битная шина на 6502 и в 1983м году? Тогда очень важно было сделать игровую консоль дешёвой.
Вы не поверите, хватало. И игрушки были загляденье. А попроси среднего современного тыжпрограммиста написать игру, уложившись в 32К?
Я знаю о чем речь(у меня был Pentagon128, ещё можно заглянуть мне в профиль), но
А сделали бы адресацию сразу 32-х битной и проблемы бы такой не было как класса.
звучит подобно
640кб хватит всем!
, однако теперь нам и 32-х битов не хватает :)
Дайте мне прямой доступ к оборудованию, чтоб ОС не мешалась, и 16-разрядный код, чтоб команды много места не жрали — и можно даже в 4к уложиться. За примерами далеко ходить не надо, под DOS и сейчас средней криворукости кодер не то что на ASM'е — даже на Turbo Pascal 7.0 может написать простенькую игрушку, уложившись в 32к.
В начале даём:
{$A-,B-,D-,E-,F-,G-,I-,L-,N-,O-,P-,Q-,R-,S-,T-,V+,X+} {$M 16384,0,655360}
потом:
asm
 mov ax,13h
 int 10h

Ну и дальше как-то через mem[$A000:i]:=...
Минимум документации (всего пара книжек), минимум кодерского скилла — и оно легко напишется и будет работать. ИМХО даже проще и понятнее, чем инициализировать DirectX или написать шейдера в WebGL.
Недаром же говорят — если хочешь уменьшить размер программы минимум на порядок, начни с того, что выкинь все фреймворки.
Очень интересная статья! Спасибо. А какие ваши дальнейшие планы на статьи/ видео? В принципе, с удовольствие посмотрел бы на разработку клона nes/famicom хоть на ориганальном железе, хоть на плис:) касательно первопроходцев — если речь о тех, кто спиративал игры. То, думаю там в большинстве случаев было завладевание исходных кодов игр. Иначе как объяснить всяческие изменения в число жизней, замену текстур и т.д. Не диссасемблили же они игры) второй вариант — тупо считывали 2 пзушки и перезаписывали их.
Про дальнейшие планы пока секрет.
Конечно дизассемблировали. По вашей логике у создателей Game Genie должны были быть исходные коды абсолютно всех игр, ведь именно они были первоисточником всех патчей в те годы. Да и не было бы особого смысла в исходниках, они всё равно на ассемблере писались. Текстуры же легко заменяются без изменения кода игры.
Про текстуры плохой пример — согласен.
Просто, например, зачем потенциальному пирату лезть в код игры, если он может скопировать ROM и реверснуть плату картриджа. Это кажется как-то более простым.
Дизассемблерованный код изучать — не самое приятное занятие.
Это так — просто мысли. Я картриджами для NES особо не интересовался ранее.
До Санчеза мне явно далеко. На мои просьбы о помощи он отреагировал как-то неоднозначно…
Это одиозная фигура, получившая широкую известность еще в те далёкие времена, когда ромы лежали только на pristavka.kulichki.net, a цвет эму-сцены обитал исключительно на emu-russia.km.ru/forum. И даже тогда Санч был не сильно охоч к помощи новичкам. Сейчас он активно принимает участие в разработке Demul и даже там резко отсекает любое проявление некомпетентности в вопросах Dreamcast.
К сожалению, те люди, которые легко уживались с нубасами на эмураше сейчас воспринимают современных новичков весьма враждебно.
У Hardwareman, вроде, был аккаунт здесь, а сейчас не могу найти.
ХВМ куда проще в общении. На правильно поставленные вопросы он, зачастую, даёт развёрнутые адекватные ответы.
Никогда не было, теперь есть. Люди слезно попросили. :3
Кстати, интересно, по какому алгоритму из двух ромов склеивается файл .nes?
Там сначала идёт простенький заголовок на 16 байт, в котором указывается маппер, мирроринг, размер программной памяти, размер памяти с изображениями и прочие параметры. После него идут все данные по очереди. Погуглите структуру NES-файла, там ничего особенного.

Вот тут у меня класс, который разбирает и собирает nes-файлы: github.com/ClusterM/famicom-dumper-client/blob/master/NesFile.cs
В свое время описывал в рамках своего проекта NES-файл. А в конце еще захотел сделать обратную операцию: сделать картридж. :)
А поясните, пожалуйста, для чего в NES-файле вообще указывать маппер? Ведь у эмуляторов нет ограничений по разрядности шины и данные в NES хранятся, насколько я понимаю, не постранично, а сплошным потоком.
Игра-то при этом умеет только с 16-разрядной шиной работать. Данные в NES-файлах хранятся именно постранично.
Круто. А вот нельзя ли сделать наоборот? Например: В офис программеров-олдфагов, выросших на денди, покупается теплая ламповая приставка. Но где брать картриджи? В сети полно дампов. Может ли быть некое устройство, с одной стороны которого втыкается флешка с дампами, а другой стороной устройство вставляется в приставку?
Да, можно. Я хотел сделать что-то подобное, да что уж там, до сих пор хочу. Приставка, пусть и китайский клон всё же как-то теплее и ламповее эмуляторов. Но вот со временем плохо.

Само устройство-то не сложное — считываешь файл рома, по запросу приставки отдаёшь ей данные.
Есть нюанс с мапперами, которые необходимо эмулировать. Впрочем, если ром играется на эмуляторе, значит, маппер известен как минимум этому эмулятору. Т.е. информацию найти можно.

Ещё нюанс — выбор игры. Не скажу, что не решаемая проблема, но нужно написать как-минимум авто-генератор меню со списком файлов. А для этого уже требуются более глубокие знания, чем «протокол обмена информацией картриджа с приставкой».

Хотя это всё теория.
да, что-то с ценами у них беда прям. И список поддерживаемых мапперов небольшой
Ну, 135 мапперов поддерживается, 86 — нет. Не так и мало. (плюс, говорят, мапперы реализованы в софте => могут добавляться)
Курс вырос же.
Брал в прошлом году там версии для Famicom и для Sega Genesis — пока на данный момент это самые функциональные картриджи.
Для NES еще есть российская разработка: ramfactory.com/
Ну и на их форуме можно почитать по поддержке мапперов.
Ценник немного меньше, но все равно не маленький.
Что-то не вижу у них для NES, только для SNES и Megadrive
У меня значительно дешевле по деталям получается, если без мультирома. Хотя зачем мультиром на домашней консоли — я не знаю.
Вся прелесть в поддержке довольно большого количества мапперов.
И удобстве использования.
Залил на карту ромы, вставил в консоль и играешь.
Поддержку нужного маппера самому сделать не сложно, они все отлично документированы.
Мультиром удобен для посиделок с друзьями. Если играть самому, то обычно достаточно записать какую-то одну игру.
«Все» — имеется в виду нумерные, конечно.
И я не спорю, что мультиром и возможность использовать SD карту — это очень удобно. Но при такой цене и нынешнем положении в экономике многие задумаются — нужно ли оно.
Всё будет. Нам же ещё много серий для шоу снимать, а вы хотите всё и сразу :)
UFO just landed and posted this here
Можно и аппаратно. Иногда разбираешь картридж и видишь, что на нем, кроме «капель-ПЗУ», стоит микросхема — регистр. Можно бывает проследить связи регистра с сигналами и понять, как он управляется. Но в общем случае маппер может быть встроен в ту же каплю, где находится ПЗУ. Такое аппаратному реверсу тоже подлежит, но гораздо более затратно и трудоемко, чем дизассемблер.
Отлично. Очень хорошо выдержан баланс глубины изложения, при высоком уровне технической грамотности. Невозможно даже представить, что бы в современных СМИ появилось бы нечто подобное. Вам точно стоит развивать направление технического видеоблоггинга.
А возможно ли подключить картридж не к USB, а к LPT-порту? Это позволило бы сэкономить на микроконтроллерах и не связываться с разводкой платы.
Ног не хватит. Но можно попробовать использовать несколько логических схем.
Sign up to leave a comment.

Articles