What's new
Here is Espgaluda - Will get to Ketsui later tonight.
My ESPGaluda board showed up tonight, same boards as EVAWINGZERO (killing blade), here is a link to the the 27c322 U9 rom. I have not had time to compare it to what is currently out there, but im sure you guys can clue us all in. Also in case it wasn't answered this graphics board revision is No 0213
ESPGaluda_u9 *Link removed, confirmed that dump matches MAME espgaluda_u8.bin*
Sorry to resurrect an older post, but just to confirm:
- this is from a board with the ASIC removed?
- this matches this rom from romset "espgalb"?

The mame driver clearly decrypts this ROM with "pgm_ddp2_decrypt" during start, which makes me think that part of this happens on the motherboard. But how is the ddp2 method selected if this is normally controlled by the ARM?

(And what is the secret sauce if twistedsymphony can't reproduce it on his Killing Blade cart?)
 
Last edited:
Sorry to resurrect an older post, but just to confirm:
- this is from a board with the ASIC removed?
- this matches this rom from romset "espgalb"?
Both of those things were confirmed several times in this thread.


he mame driver clearly decrypts this ROM with "pgm_ddp2_decrypt" during start, which makes me think that part of this happens on the motherboard. But how is the ddp2 method selected if this is normally controlled by the ARM?
despite the fact that the MAME driver does this, the games are known running on other boards with other encryption schemes using the same program rom.

so despite with the MAME drvier is doing, the decryption isn't being used at all. with these ROMs.
 
The mame driver clearly decrypts this ROM with "pgm_ddp2_decrypt" during start, which makes me think that part of this happens on the motherboard. But how is the ddp2 method selected if this is normally controlled by the ARM?
I wouldn't take that to mean anything.

Download the ESPGaluda cartridge ROM file and look at it in a hex editor. It is clearly already decrypted, see attached.

Left is the cart ROM, right is the PCB ROM.
ss.png
 
And here is my mistake...
Code:
uint16_t *src = (uint16_t *)(machine.root_device().memregion("user1")->base());
So I'm always thinking that this is the program ROM. But guess what region "user1" is?

C:
ROM_REGION32_LE( 0x400000, "user1", 0 ) /* Protection Data (encrypted external ARM data) */ // leftover from original game
ROM_LOAD( "v100.u23", 0x000000, 0x20000, CRC(06c3dd29) SHA1(20c9479f158467fc2037dcf162b6c6be18c91d46) )
Doh!

So the program ROM doesn't go through the ASIC on the cart at all!

Edit, for completeness sake:

Code:
uint16_t *src = (uint16_t *) (machine.root_device().memregion("maincpu")->base()+0x100000);
This is the code for the kovsh board, which clearly decrypts the cartridge ROM space. But on that board the ROM is not directly connected to the CPU bus.
 
Last edited:
So I spent a few hours playing this in both black and white, no crashing at all. For those of you with issues, you guys need to make sure you have a working battery on the mobo, and run black edition, set free play and other options and save the settings from the game's test mode. Per AMBs steps for the original conversion, dip 8 on and the rest off. It works.
 
You either have obvious nvram damages
Or the game settings were never saver there in the first place.

Try this

Dip 8 on rest off.
Boot to black label.
Enter test mode by holding test button.
Set the game to free play in the menus.
Exit the menus and exit test mode.
(Game saves to nvram at this point)
Note this mode is not the BIOS test mode.
Selection menu pops up.
Boot to black label to confirm free play works.

From this point on you should be able to select white and black label with no problems.
I'll give that a try. I only set Freeplay on the mobile dips. I forgot about the in-game setting
 
Will be trying this out over the weekend! Thanks for all of your work guys!
 
Is it possible that the AMB version used for the hack is based on this (already hacked version):

DoDonPachi DOJ Black Label Save hack : Add save functionality to your DOJ WL PCB with this simple ROM swap. Do not use on an original DOJ BL PCB. It might work, but it will stop the original EPROM from booting.

There are a couple of known issues with this ROM. Obviosly it will not save without the battery. Also, if the NVRAM contains data that that the high score table does not understand it will crash. The brown switch on the PCB should not be used. Whilst it should clear the NVRAM, the 'clear' state cannot be verified and my leave spurious data which will crash the PCB. Factory resetting the PCB from within the test menu *may* return the NVRAM to a usable state but cannot be guaranteed.

Note; If the PCB is powered off whilst the game is saving the NVRAM contenets may get corrupted.

If the NVRAM does get corrupted the modified DOJ BL EPROMs or original WL EPROMs will still work without issue.
Maybe it is possible to use this version instead:
http://ikotsu.blogspot.com/2012/01/dodonpachi-white-label-black-label.html

This "white label" to "black label" conversion rom seems to be cleaner than the "high score saving" hacked rom (at least closer to the original black label code, just without the suicide battery protection).
 
More stuff! I got a bunch of ROMs burned for Ketsui and Espgaluda. (And looked at the program ROMs in a hex editor. Doh!)
IMG_20190208_214141.jpg

IMG_20190208_215218.jpg

And I tried out my "hacked" version of U15 for KOV2:
IMG_20190208_214219.jpg

This allows Ketsui and Espgaluda to boot on the KOV2 board without adding jumper wires or lifting pins on the U15 rom.

Problem: I soldered a speaker back onto my Jamma connector (I ripped a cable previously) and found that I don't have sound on either board. :( I'll have to debug the M-ROM decoder and the high/low byte decoding before I can think about sharing the char board.

The fact that the program ROM is unencrypted (Doh again!) simplifies the problem a lot. I've got a few things to test, and maybe I can make a start on designing the program board over the weekend.
 
This allows Ketsui and Espgaluda to boot on the KOV2 board without adding jumper wires or lifting pins on the U15 rom
Nice work!

though you should note that this is specifically for the 0333-03-FI board, as the different KOV2 revision PCBs have different pin mappings on the PAL.
 
Nice work!
though you should note that this is specifically for the 0333-03-FI board, as the different KOV2 revision PCBs have different pin mappings on the PAL.
Sure, though people should be able to use your general instructions and the source code to adjust it to any board they want. (Though hopefully if I manage to get the prog board working it will be easier to just get a new PCB instead of hacking an existing cartridge...)
 
You either have obvious nvram damages
Or the game settings were never saver there in the first place.

Try this

Dip 8 on rest off.
Boot to black label.
Enter test mode by holding test button.
Set the game to free play in the menus.
Exit the menus and exit test mode.
(Game saves to nvram at this point)
Note this mode is not the BIOS test mode.
Selection menu pops up.
Boot to black label to confirm free play works.

From this point on you should be able to select white and black label with no problems.
I have tried all these step multiple times but get constant address errors directly after selecting version and the warning screen when trying to load either white label or black label unfortunately ;(. The original patched ROM works no problem for me. Have tried quite a few different thing. uploading vid for you now.
 
Last edited:
here is vid for you sir. please let me know if there is some step you are unhappy with.
 
Bonus:
IMG_20190209_002720.jpg

I decrypted the DDPDOJ white/black label ROM, burned it onto an EPROM, and put it onto my KOV2 board with the original mapping PAL:
IMG_20190209_002729.jpg
I only had a quick test of the start as it is quite late by now... So you'll be able to have a program board supporting all three games, you just need a different PAL for DDP3 to get the different mapping. (Or the same PAL, but then you'll need to include the BIOS in a second EPROM. :) )
 
I have tried all these step multiple times but get constant address errors directly after selecting version and the warning screen when trying to load either white label or black label unfortunately ;(. The original patched ROM works no problem for me. Have tried quite a few different thing. uploading vid for you now.
Which board are you using? I noticed the PAL can limit the address range of the ROM, and the dual version fills the whole EPROM instead of half.
(There is of course the chance of a dodgy EPROM as well.)
 
I have tried all these step multiple times but get constant address errors directly after selecting version and the warning screen when trying to load either white label or black label unfortunately ;(. The original patched ROM works no problem for me. Have tried quite a few different thing. uploading vid for you now.
Which board are you using? I noticed the PAL can limit the address range of the ROM, and the dual version fills the whole EPROM instead of half.(There is of course the chance of a dodgy EPROM as well.)
0256 and 0257. It is possible eprom is no good but is verifying and I see others having similar issue (i also get same error pictured above).
 
So you'll be able to have a program board supporting all three games, you just need a different PAL for DDP3 to get the different mapping. (Or the same PAL, but then you'll need to include the BIOS in a second EPROM. :) )
Good work @Fluffy but we already knew that. Same goes for the decrypted ROMs, It's been mentioned several times.
In fact all games can be supported on the same board but some require patching to circumvent the ARM.
 
Good work @Fluffy but we already knew that. Same goes for the decrypted ROMs, It's been mentioned several times.In fact all games can be supported on the same board but some require patching to circumvent the ARM.
Yeah, as I said above: I was confused by the decompression in MAME, so thought unencrypted ROMs needed some extra hack of the board... though as far as I can tell we still haven't worked out how to boot the killing blade board with the ASIC removed?
 
I didn't think we'd worked out how to boot conversions based on Killing Blade at all yet
 
Back
Top