DC-SWAT Forum - VMU Hack

Страниц: 1 2

Итак, удалось получить код этого дампера, спасибо SI{AY за это.
Кстати автор кода упомянул, что есть шанс брикнуть VMU, мне кажется это означает присутствие потенциальной возможности записи в область памяти биоса.
Вот основная выдержка из кода, которая производит дамп:

PHP код:

    ; read fw addr trh,trl => vrmad1
fwread:
    mov #<$0123,vrmad1
    push vrmad1
    mov #>$0123,vrmad1
    push vrmad1
    push acc
    push trh
    push trl
    push b
    push c
    mov #<vrmad1,2
    mov #0,acc
    mov #1,b
    push acc
    not1 ext,0
    jmpf $0ef5

readpage:
    mov #$80,1
.loop:    push 1
    call fwread
    pop 1
    ld vrmad1
    st @R1
    inc trl
    inc 1
    ld 1
    bnz .loop
    ret 

Похоже $0ef5 это промежуточная функция в биосе, для сискола чтения памяти. А ведь есть вектор и на функцию записи. Хотя здесь я могу ошибаться конечно, пока просто предположение.
Все бы ничего только вот нету у меня японской VMU Sad

У меня вообще никакой нету Sad

Придется заказать разные версии и отложить это дело на время, если желающих больше нет.

(16.08.2013 08:36)SWAT писал(а): [ -> ]Придется заказать разные версии и отложить это дело на время, если желающих больше нет.

SWAT, сделай образ диска или подробную инструкцию для запуска через DreamShell, я думаю на этом форуме, да и не только на нём найдутся люди которые смогут сдампить биос Smile

есть у меня vmu карточки пару штук.

shadow, так а смысл его дампить, они все есть в инете. Сейчас надо методом тыка искать дырку для записи в биос.
LEUMAS, а какого региона они у тебя?

До кучи прикрепляю к сообщению все имеющиеся VMU биосы.
В архиве 4 разных версии + один девелоперский.

все три карты HKT-7000

К сожалению это не говорит о ее региональной принадлежности...
Вот список всех типов:

HKT-7000 - Standard VMU
HKT-7001 - Godzilla VMU (possibly VMS)
HKT-7002 - VMS (Memory card, no screen)
HKT-7005 - MOSURADORIMUBATORU (software with Visual Memory)?
HKT-7006 - Gamera VMS (LE VMS)
HKT-7007 - VMU
HKT-7007 - '-03' Aqua Blue VMU
HKT-7007 - '-16' Clear VMU
HKT-7007 - '-18' SGGG LE VMU
HKT-7008 - '-01' "BOY super invention kit, crab break ASON" ?
HKT-7008 - '-02' "Giant Gram VMU"
HKT-7009 - '-01' US Blue VMU

Поговорил я с Маркусом, в общем ничего нового он мне не выдал. Я хотел узнать у него на счет возможности записи в биос, он сказал что там скорее всего либо защита от записи, либо вообще нет возможности для этого. Комментарий он свой объяснил просто предосторожностью, мало ли кто закосячит себе VMU, чтобы его потом не винили Smile

Как пример обеих ситуаций можно сопоставить bios rom дрима, где отсутствует возможность записи, а так же его же flash rom, с защищенным блоком от записи только у фабричных данных. В первом случае поможет только замена или прошивка на программаторе, а во втором небольшой хардварный хак.
Но я думаю не стоит пока сбрасывать со счетов то, что там нет защиты на запись и есть хардварные возможность у чипа. Так как в принципе в ту область не пускают из программы, в нее попасть можно только вот с помощью хитрости описанной выше, так что есть шанс что Sega понадеялась только на одну защиту, хотя любит она конечно хардварно все запрещать, но здесь может быть не тот случай, так как это не DC, а периферия.

а ка крегион определить к карты?
на всех мейд ин чайна написано.
елсли нада то вером разберу, так как бегу на работу уже.

(16.08.2013 07:55)SWAT писал(а): [ -> ]MetalliC, я более развернуто описал процесс обмена по DMA, я даже немного ошибся здесь пока писал, там правильней написано.

да, там более-менее верно описано.
но смысл в том, что мапля это не тупое ДМА, которому дали данные от сих до сих и оно их куда-то отправило, мапля это простенький командный процессор.
т.е. цикл работы после старта ДМА таков -
- считал 4байта команды, взял оттуда номер порта и длину отсылаемых данных
- считал 4байта указателя куда писать принимаемые данные
- отправил по шине данные (через DDT DMA SH4)
- принял данные (тоже через DDT DMA SH4), если данные не пришли - записал FFFFFF (флажок что устройство не ответило)
- если в коде команды не был взведен битик "последняя" процесс повторяется с начала

таким макаром за один запуск maple опрашиваются все имеющиеся устройства, но по сути запусков SH4 ДМА при этом Holly делает хренову кучу)
и само по-себе мапле-дма не стартует, биос/игры запускают его с частотой кадров.

(16.08.2013 07:55)SWAT писал(а): [ -> ]Кстати с какой целью ~~ел корейскую кухню~~ изучал Maple и по каким исходникам/докам?

реверсил управление в Naomi, вплоть до года три назад у всех оно эмулировалось кривым и оч глючным HLE, и меня оно сильно вымораживало, вот я и занялся исследованиями, а т.к. оно работает через maple и его выштудировал Smile

само собой разумеется ни док ни тем более исходников на эту тему тогда не было, всё выяснялось отладкой и изучением кода биоса/игр и логов доступа к maple.
в последствии оказалось, что в наоми на первой мапле-шине висит MCU, который выполняет функции maple-JVS моста (JVS это шина/стандарт плат ввода-вывода в аркадах)
более того, оказалось что в этом MCU внутреннего рома почти нет, биос/игры загружают прошивку сами в RAM MCU, и система команд оказалась от Z80, представьте мое удивление, когда я в биосе наоми увидел до боли знакомые опкоды зилога Smile

так или иначе я это дело раскурил, как в плане устройства железяки для LLE эмуляции, так и алгоритма работы его кода для HLE, так что щас оно работает перфектно, и в Demul и в MAME, да и оказалось что в Hikaru этот чип тоже есть.

ну а по поводу практического применения VMU для хака дрима...
тут первая проблема - при подключении его к контроллеру он выпадает из пользовательской программы в биос, если это не обойти то дальше заморачиваться смысла нет.
модифицировать сам биос даже не думайте, как я уже говорил там mask-rom, это не EEPROM или FLASH которые (пере)программируются, это кусок чипа, данные в котором намертво закладываются при его производстве, и "перезаписать" их не возможно, не та технология, грубо говоря это тупо матрица с перемычками в чипе.

Я так и думал что ты мне хардварную составляющую описываешь, так как там именно все так как ты сказал, а я имел ввиду софт. Как бы то ни было, отправить небольшой кусок кода все-же возможно.
Хак биоса VMU для того и нужен, чтобы можно было при подключении к дриму использовать свой код, понятно дело что без этого, остальное не имеет смысла.
Откуда такая уверенность про mask-rom? Есть доказательства этого?
Если это действительно так, то без своего девайса похоже не обойтись...

(19.08.2013 07:36)SWAT писал(а): [ -> ]Откуда такая уверенность про mask-rom? Есть доказательства этого?
Если это действительно так, то без своего девайса похоже не обойтись...

VMU.pdf из Katana R11b, стр. 142
хех, люди вон до сих пор биос с европейских VMU даже считать не смогли, а вы раскатали губу их записать/модифицировать, оптимисты Big Grin

вообще всё не так плохо, дока говорит что пользовательская программа не прерывается автоматом при подключении к контролеру, ей генерится прерывание мол заканчивай свои дела и выпрыгивай в биос, так что если положить болт на INT0 то софтинка по-идее так и останется работать.
другой вопрос как SIO переключить в режим Maple (или оно само ?), какие там регистры и биты, и доступны ли вообще эти регистры не биосу а программе в флеше Huh

Мда печаль, пропустил я как то эту запись в табличке про Mask-ROM Sad

В остальных местах она упоминается просто как ROM.
Значит нужно думать что-то другое.
К примеру VMU определяет подключена ли она к DC одним из своих контактов (я думаю там просто хэндлер на прерывании весит), возможно его достаточно просто отключить, чтобы VMU не выходила из режима игры и продолжала работать. На сколько я понял, регистры для работы с maple просто не документированы были в официальных доках, но использовать их можно и в игре, пользуясь доступной о них инфой со стороны. Может это прокатит?
Главное чтобы при отключенном контакте, сама шина заработала.

P.S.
Блин не до конца прочитал и начал писать ответ Smile

))) Написал то же самое...
В общем если это так, тогда вообще хорошо, описание регистров есть здесь http://web.archive.org/web/2010042618114...otato.html

Код:

0x160-0x162 Not (officially) Used 

The BIOS clears bits 2 and 4, and sets bits 0 and 1.

These registers seem to write data to the Maple bus from the Work RAM. 

One little routine does this series of operations:

1. Write 3 to VLREG 

2. Clears VSEL.0 

3. sets VRMAD1 to 0 (zeros address) 

4. writes 32 bytes to VTRBF 

5. Sets VSEL.0 

6. Sets SFR161.1 

7.Waits for SFR161.0 to be set 

8. loop lines 2-7

Т.е. тупо складываем фрейм в Work RAM и отсылаем его с помощью этих регистров.

(20.08.2013 13:04)SWAT писал(а): [ -> ]В общем если это так, тогда вообще хорошо, описание регистров есть здесь http://web.archive.org/web/2010042618114...otato.html
Т.е. тупо складываем фрейм в Work RAM и отсылаем его с помощью этих регистров.

там можно сказать ничего не описано толком, биты в регистрах 160-162 должны быть те же что в регистре CFLAG MCU джойстика, т.к. в MCU наоми они те же, только расположены в другом порядке, не думаю что сега персонально для чипа ВМУ изобретала что-то эксклюзивное.

описаны они (да и весь алгоритм приема/передачи по мапле) начиная с 61стр. MAPLE82E.doc
вообще по логике вещей там не может быть так всё просто как описано у того чела, там как минимум при передаче данных должны играться битами TXB (первые 32байт ответа, перед которыми SIO сгенерит паттерн старта на шине), CTXB (вторые и последующие 32байт ответа), ENDP (последние 32байт ответа, после которых SIO сгенерит стоп-паттерн)

короче это надо садиться и полностью "раскуривать" прошивку VMU (хех, где только столько времени найти Wink

), я надеюсь IDA Pro умеет такой тип процессоров ?

Это не SIO переключаются в режим Maple, там для Maple отдельный интерфейс, на сколько я помню, а внутречиповый SIO только для обмена между VMU, у них и скорость мелкая.
Ты вот опять в дебри полез, не надо там дергать ни за какие TXB и т.п. это хардварно все делается само. Так же как и со стороны дрима тоже не надо париться ни с чем, там сама шина все делает, ты же только инициализируешь DMA один раз для отправки/приемки всего и вся.
Зачем им нагружать и без того еле шевелящийся проц всякими протоколами (если они даже основной дримовский этим не стали грузить), там все реализовано хардварно, а из проца уже это управляется всего парой регистров, типа - отправь данные, а оно там само пошло колбасить. Так же и прием, там железка складывает тупо в Work RAM уже готовый фрейм и все, а проц уже только парсит полученные данные.
IDA Pro скорее всего стандартный чип поддерживает, но в VMU он кастомный, т.е. с кучей доп. инструкций, которых нет в оригинале. Но дисассемблер для него написали уже сами умельцы, так что с разбором особых проблем быть не должно.

Сват, а на сам Maple есть офф. дока\спецификация?

(03.09.2013 16:51)Rio писал(а): [ -> ]Сват, а на сам Maple есть офф. дока\спецификация?

(20.08.2013 20:56)MetalliC писал(а): [ -> ]описаны они (да и весь алгоритм приема/передачи по мапле) начиная с 61стр. MAPLE82E.doc

(03.09.2013 16:51)Rio писал(а): [ -> ]Сват, а на сам Maple есть офф. дока\спецификация?

если еще актуально
ссылка раз это вся внутренняя Сеговская дока по Дриму на инглише (не сомневаюсь, что где-то есть еще более подробная на японском, но ее увы нету), тебе оттуда могут быть интересны папки E_MapleBus_FT_Spec и E_MapleBus_Peri_HW_Spec
ссылка два дока на VMU из Katana-SDK

(07.09.2013 15:04)MetalliC писал(а): [ -> ]
(03.09.2013 16:51)Rio писал(а): [ -> ]Сват, а на сам Maple есть офф. дока\спецификация?
если еще актуально
ссылка раз это вся внутренняя Сеговская дока по Дриму на инглише (не сомневаюсь, что где-то есть еще более подробная на японском, но ее увы нету), тебе оттуда могут быть интересны папки E_MapleBus_FT_Spec и E_MapleBus_Peri_HW_Spec
ссылка два дока на VMU из Katana-SDK

Большое спасибо.

Страниц: 1 2