What's new
Hey I'm converting a Knights of Valor Plus to DDP and I have based everything on the pictures in this post. (bottom three pics)

I now need the pal files for U7 and U8, I know its a long shot can anyone help?
DDP should run with the default PAL. PAL modifications are required to change the boot address for Espgaluda and Ketsui.
 
Bump on this... anyone?

@Apocalypse

Any chance of a Bee Storm conversion?
I believe the Bee Storm cart has a graphics chip not on any other cart? Keep checkin' eBay for Yaton listings, you'll eventually get one at your price, or hit up @sheep_nova -- he gets them from time-to-time also!
Bee storm uses the ARM CPU and external ROM:
https://github.com/mamedev/mame/blo...495549ee9a77bb/src/mame/drivers/pgm.cpp#L2766

So the good news is that the ASIC-internal ROM is dumped and can be analysed, and it may be possible to patch another game to run it, or to port it to an off-the-shelf ARM-based micro controller. One person is looking at that. (Not me.)

Another option is that according to the Mame source some people used Bee Storm as a basis for other cave conversions, so at some point it may be profitable to convert them back into Bee Storm.
https://github.com/mamedev/mame/blo...495549ee9a77bb/src/mame/drivers/pgm.cpp#L4393
https://github.com/mamedev/mame/blo...495549ee9a77bb/src/mame/drivers/pgm.cpp#L4404
https://github.com/mamedev/mame/blo...495549ee9a77bb/src/mame/drivers/pgm.cpp#L4457
 
So no easy fix there then.

Though if i remember, the ARM CPU is part of the protection, and not used for running game code?

It could therefore the patched out, theoretically?
 
So no easy fix there then.

Though if i remember, the ARM CPU is part of the protection, and not used for running game code?

It could therefore the patched out, theoretically?
In this case it seems to be running game code, which is why it has the external ROM:
https://github.com/mamedev/mame/blo...495549ee9a77bb/src/mame/drivers/pgm.cpp#L2796

This is less than the external ROM for games like Demon Front, but more than the internal ROM. It doesn't mean it can't be patched out, it is just not an straightforward. I think Mame does a high-level emulation for games where it doesn't have the internal ROM, and does some patching of the external ROM. If the game is patched to only require the internal ROM to boot the game then it should be possible to convert other carts.

Someone will have to dig through the code to be sure...
 
I have Ketsui Dodon and ESPGALUDA conversion, everything is really cool (DD only have some graphics missing :() someone know if it will possible to have other games converted in the future? :)
 
I would love to see Bee storm methods aswell!

One further still open question in that thread is if Killing Blade could be used as donor. Not sure if there were any progress till yet or even anyone has looked into that within last time.
 
I would love to see Bee storm methods aswell!

One further still open question in that thread is if Killing Blade could be used as donor. Not sure if there were any progress till yet or even anyone has looked into that within last time.
I thought Bee Storm uses the ASIC aswell. So you would need a donnor with a compatable ASIC and enough SRAM.

In theory my Demon Front Repoduction/conversion cart may work... But there are heaps of other "Cheap" games you should be able to convert from. You only need 256kbit of sram. Not the larger 1mbit of SRAM.

T.
 
has this been dumped? I was under the impression that Demon front couldn't be converted due to it's reliance on the ASIC
Both external ROMs are dumped, the internal ROM isn't:
https://github.com/mamedev/mame/blo...3ca05232b0dba4/src/mame/drivers/pgm.cpp#L3391

Apparently they bypass the internal ROM for Demon Front completely because the code never jumps back:
https://github.com/mamedev/mame/blo...rc/mame/machine/pgmprot_igs027a_type3.cpp#L18

So if you can get internal ROM to accept and jump into the external ROM it should work... Someone with more time than me could look at the internal ROM dumps the Mame team managed to extract on other games to see if there are any common factors what the protection code is looking for.

So while you can't patch it in the same was as the Cave shooters it may be possible to get it to run on other carts with a similar ASIC.
 
Both external ROMs are dumped, the internal ROM isn't:
github.com/mamedev/mame/blob/d…ame/drivers/pgm.cpp#L3391
I know the official release has been dumped, I was asking specifically about his bootleg because presumably it would have that bypass patch already done.
 
my Demon Front Repoduction/conversion cart may work
has this been dumped? I was under the impression that Demon front couldn't be converted due to it's reliance on the ASIC
I'm doing a conversion TO "Demon Front".. not FROM DF. The hardest part is re-encypting the ARM Code/ROM to match the donners ASIC/ARM7 ROM. The rest is just re-writing the eproms and Changing the CHAR board roms. PLus adding / making sure the cart has enough SRAM for the double buffering and SRAM for the ASIC/ARM7.

T.
 
would be nice to build a tool to do this.
I originally thought the encryption takes the data as part of the key generation, but it looks like the xor key depends only on the address. That way you can just run the same decryption code to encrypt the ROM. My DDP3 code from a previous post should do it for KOV-SH, and you can just copy+paste the data tables and logic from the MAME code to make it work for other games.

The problem is that there still seem to be a bit of magic. I wrote a script for vaughan14 above to do it for Kov-Plus, which generates a ROM that works fine in MAME for me, but fails on actual hardware... so I assume there is still some check that the internal ROM does before starting the game.
 
If anyone else wants to try, I attached decrypt.py.
- unzip the python script attached
- put ddojbl.bin from the pgm program files zip into the same directory
- run decrypt.py

This should produce ddojbl_raw.bin and ddojbl_kovplus.bin

If you have MAME and the kovplus roms, please unzip and replace p0600.119 with ddojbl_kovplus.bin. If you run it you should get DoDonPachi DOJ, just with corrupted graphics and weird sound. You can copy over the tile and sprite roms from ddp3 (renaming them to the corresponding files, of course) to fix the graphics.

If that works for you, you can try burning ddojbl_kovplus.bin into an EPROM and see if that runs on the kovplus board... The program ROM should be socketed, so you can just try it and reverse it back later.

If you have a hex editor you can open ddojbl_raw.bin to examine the unencrypted game.

This is probably all I can do without some kind of logic analyser.
 

Attachments

  • decrypt.zip
    1.5 KB · Views: 262
If anyone else wants to try, I attached decrypt.py.
- unzip the python script attached
- put ddojbl.bin from the pgm program files zip into the same directory
- run decrypt.py

This should produce ddojbl_raw.bin and ddojbl_kovplus.bin

If you have MAME and the kovplus roms, please unzip and replace p0600.119 with ddojbl_kovplus.bin. If you run it you should get DoDonPachi DOJ, just with corrupted graphics and weird sound. You can copy over the tile and sprite roms from ddp3 (renaming them to the corresponding files, of course) to fix the graphics.

If that works for you, you can try burning ddojbl_kovplus.bin into an EPROM and see if that runs on the kovplus board... The program ROM should be socketed, so you can just try it and reverse it back later.

If you have a hex editor you can open ddojbl_raw.bin to examine the unencrypted game.

This is probably all I can do without some kind of logic analyser.
So, we just tried this again, and it doesn't boot on hardware.

Now considering that you can patch and re-encrypt a game (like the DDP3 dual boot) I don't think it is a full checksum, so it may be more a header check.
 
So, we just tried this again, and it doesn't boot on hardware.

Now considering that you can patch and re-encrypt a game (like the DDP3 dual boot) I don't think it is a full checksum, so it may be more a header check.
usually it is full checksum, using custom algo, different in each game. at least it was like that in all PGM 1/2 ARM's internal firmwares I've seen.
 
So, we just tried this again, and it doesn't boot on hardware.

Now considering that you can patch and re-encrypt a game (like the DDP3 dual boot) I don't think it is a full checksum, so it may be more a header check.
usually it is full checksum, using custom algo, different in each game. at least it was like that in all PGM 1/2 ARM's internal firmwares I've seen.
There is a few games that use the same encryption. I know at least 2 games that share the same. Plus the ASIC doesn't seam to be locked to eigher game....

D.
 
Last edited:
@GC8TECH right, but encryption is not the only problem. there is also checksum, which is different in different games.

well, basically it is the same - routine which does data block 16bit sum or 16bit xor, then add block sum to whole sum, then compare result with value located somewhere in ROM.
but, the table which defines how many datalocks, data offsets, sizes, add or xor mode switches; final checksum offset in ROM - is inside of ASIC firmware and different.

so, to convert some game to run on PGM with ASIC cart you'll need to know both encryption key and how checksum is performed.
 
Back
Top