Any PGM Conversion info out there?

[Apocalypse]

I needed a slightly different jig to read the 22V10:

This uses a 32kb EPROM pinout as a base, and I had to read them in two passes to get all 10 output bits.

My computer then spent the rest of the day crunching the data and generating the pld files.

I might learn something new here but I doubt it will work. I've got an adapter to brute dump 22V10 devices but it generates a 16MB file...

 

[Fluffy]

I might learn something new here but I doubt it will work. I've got an adapter to brute dump 22V10 devices but it generates a 16MB file...

Well, the pld files do make sense related to what I expected... This will probably not work for any possible 22V10 in the wild, but you can guess what are inputs and outputs based on the schematic.
(There are still enough ways for this to go wrong, though... )

 

[Apocalypse]

Well, the pld files do make sense related to what I expected... This will probably not work for any possible 22V10 in the wild, but you can guess what are inputs and outputs based on the schematic.(There are still enough ways for this to go wrong, though... )

Oh yes, if you can determine which pins are inputs, outputs or unused it simplifies things a lot.
Unfortunately I own only 1 PGM cart, it's a DDP conversion made by Joerg, judging by the handcraftship.

 

[Fluffy]

Reading through the pld file for u15:

TO_J2_27 = (PA22 # PA20 # PA23 # PA21);

This could be the OE for the internal bios ROM. The hack makes this permanently 1, so it will never be enabled, otherwise it'll enable it when A20-A23 are 0.

After a bit more tinkering:

Pin 15 = M68K_LATCH_ENABLE;
Pin 14 = SRAM_ENABLE;

M68K_LATCH_ENABLE = AS # !PA16 # !PA20 # PA21 # !PA22 # !PA23; /* 0xD1 */
SRAM_ENABLE = AS # PA16 # !PA20 # PA21 # !PA22  # !PA23; /* 0xD0 */

Both will be permanently disabled by the hack as well. (PA21=1, or'ed together with the other terms will always result in 1)

The remaining expressions seem to be SRAM related as well, though I'll have to see where the connections are going.

 

[Asure]

With things moving along like this, i finally got some free time to make this prog rom.

@twistedsymphony attached is a DDPDOJ Black Label (without selection menu) for Killing Blade.
It works in MAME but no guarantee it will work on a Killing Blade prog board. Perhaps you can confirm

 

[twistedsymphony]

I can test that later tonight.

 

[yosai]

With things moving along like this, i finally got some free time to make this prog rom.

@twistedsymphony attached is a DDPDOJ Black Label (without selection menu) for Killing Blade.
It works in MAME but no guarantee it will work on a Killing Blade prog board. Perhaps you can confirm

Any more progress with the selection menu?

 

[edwin128]

I am selling some PGM carts, they may be useful for some testing...

 

[twistedsymphony]

@twistedsymphony attached is a DDPDOJ Black Label (without selection menu) for Killing Blade.
It works in MAME but no guarantee it will work on a Killing Blade prog board. Perhaps you can confirm

So I first tested this with the ASIC, security ROM, and security PAL removed and the PAL jumper wires installed

in this configuration it shows the PGM boot logo and then displays the current date and freezes on that screen.

Reinstalling the ASIC, security ROM and security PAL and removing the PAL jumper wires (so it's essentially an unmodified Killing Blade) it shows the PGM boot logo then goes to this:

 

[Asure]

That's unexpected and wierd.

The rom is unprotected, all the protection routines are inside it, noting is done with the asic.
The code is 'scrambled' and has to be descrambled by the asic. This is basically what happens on the DDP DOJ carts, the code is descrambled by the KOV2 asic and after that it doesn't use any function(s) of the asic anymore.

I did cheat: I had assume that the Killing Blade asic enc/dec function was a two-way function as well like DDP DOJ and my testing confirmed this.

Obviously MAME does not emulate the ASIC or expected functions correctly at this point. (It runs this DDP on KB with scrambled GFX and wrong audio. But at least it runs.)

 

[Fluffy]

Which start address does the ROM expect? The default PAL maps it to 0x100000, the PAL mod on other cartridges maps it to 0x000000.

 

[xodaraP]

I'm going to guess 0x100000 - since TS pointed out with the jumpers on the PAL it booted, but froze which would suggest it read the bootstrap ok then froze up when it got to the next step

@twistedsymphony - out of pure interest, what happens if you run the modified code with removing the ASIC and NOT installing jumpers on the PAL?

 

[Asure]

I'm going to guess 0x100000 - since TS pointed out with the jumpers on the PAL it booted, but froze which would suggest it read the bootstrap ok then froze up when it got to the next step

@twistedsymphony - out of pure interest, what happens if you run the modified code with removing the ASIC and NOT installing jumpers on the PAL?

0x100000 is correct, and you need the ASIC present on board to 'unwrap' the code.
We already tried running unencrypted code, but i don't think this dump was tested.
(The three dumps i posted before still offloaded protection calculations to the ASIC.)

I.E. the unencrypted code i posted before wasn't patched like this one.
The rom i posted yesterday is the AMB version which has ASIC dependencies removed and is encrypted for the KBD asic.
When i get back home i can make an unencrypted version of this rom if it's needed as well.

I'll try to explain a bit of the ASIC functions for clearness, simplified
The DDP DOJ Asic on the real board has two functions. MAME does the following:
- It 'unpacks' the encrypted rom on startup (A)
- It can be used for calculations, but the ASIC contains some secret parts of the formula, and the answers must be correctly returned. (B)

A) The unpacking we can work around by loading data and having it packed by Mame and swapping the correct bytes say with UCON.
B) The calculating protections were patched in the AMB roms. (I don't have any dumps of other sources, so this is all based on his work as far as i can see.)

So for the rom i posted yesterday, this is the AMB version (no protection anymore) decrypted, and then re-encrypted for use with the killing blade ASIC.
If it is booted on a Killing Blade board, it should decrypt itself and work. For some reason we (at least i) don't get yet, it doesn't work.

That being said, it would be cool if someone shared dump(s) of other carts they got from China to get an idea what is really going on.

 

[Fluffy]

Ok, just throwing ideas at the wall:
- Can you find at which address the BIOS jumps into the game? Is there a header at the start that gets checked by the BIOS?
- what about poking some invalid instruction at that address. This should trigger the invalid instruction exception both in mame and on the real hardware, and should confirm the rom gets decrypted correctly.
- overwrite the rom with with a dummy program that fills the registers with known values, for example move d0, pc, move d1, #5555, move d2, #aaaa, repeated to the end of the ROM. Make the last instruction in the ROM is an invalid instruction. Based on the exception screen you can see at which point the ROM failed, or if it reached the end.

The decryption is still a mystery to me... there is not enough RAM in the pgm to store a decryted copy of the ROM so it must be done on the fly, but the CPU data and address bus are directly connected to the ROM. I originally thought the PAL has a way to de-couple the ROM while the ASIC responds with the decrypted value, but the ROM's OE only depends on the incoming address lines.

 

[Fluffy]

[align=center]PROGRESS!!
[/align]

This is Do Don Pachi, using the custom char board and the program board from KOVSH:

AND:

This is my KOV2 board with U15 replaced with my custom PAL. (I ordered some used Lattice 22V10 from eBay.) Unfortunately my U14 PAL doesn't work, which could be a dodgy GAL, or the equations need a tweak.

 

[Asure]

Awesome man!. That's '322 eproms on the top board? The custom pal is for mapping rom on the top board only right?

Guess we'll need to cross the bridge to running unencrypted soon now. And like you said it's a mystery how they get decrypted (not enough ram, must be on the fly, are they doing pure bit manipulation?)

 

[Fluffy]

Awesome man!. That's '322 eproms on the top board? The custom pal is for mapping rom on the top board only right?

Yes, they are 322 eproms on the char board and on the prog board.

That's two different top boards: I used my KOVSH board with DDP, as that doesn't require mods to the board, and just replaced the program ROM. The graphics are corrupted because the bottom and top tile layers are still from KOVSH.

The KOV2 board with the PAL is running KOV2 at the moment, as I don't have enough eproms left. (Quite a few failed to verify, so I'm erasing them again.) This is only to verify that the PAL equations are correct. I'll order a few more 322 to burn Ketsui and Espagluda, then I can test if the modified PAL will boot them without hacks to the wiring.

The PAL subtracts "1" from the address lines, to remap the start address of the EPROM, and generates the enable line for the ROM, the RAM shared with the ASIC and the latch register used to communicate with the ASIC. It generates a few other signals that seem to be related to the SRAM as well.

Guess we'll need to cross the bridge to running unencrypted soon now. And like you said it's a mystery how they get decrypted (not enough ram, must be on the fly, are they doing pure bit manipulation?)

There are 4 or 5 pins on the cartridge connector left to decode. 3 go to the PALs, which I guess are UDS, LDS and R/W, as they are used for RAM-related equations. The other two go directly to the ASIC.

 

[Flinnster]

Loving your work guys!

 

[Asure]

I tried to repair the menu of DOJBL rom ,and the rom works in mame fine. However , the rom doesn't work on kovsh cart.


Here is the rom:
http://www.filedropper.com/p0600

I went thru the debugger with this, and the code/menu is reading/writing to the DDP3 style ASIC mapped at 0x500000. This is an illegal write on kovsh board, there is no ASIC mapped to that memory area. I assume it causes illegal instruction errors as a result.

I cracked it further and bypassed all the ASIC calls to 0x500000, NOP'ing out as we go.
Seems the code doesn't really check that hard if it's patched, or even care about the answer of the ASIC.
Maybe it's just an init command.

And with that in place, it works on real hardware as there's no more illegal rw actions
Not 100% tested, i didn't play it all the way to the end yet, i wanted to release this asap

I couldn't upload the file here as it's over 1MB, but here's a link:

ddpdojbl_fixed.zip

Thanks to @huluhala for putting the menu code back where it belongs!
Seems white label was already fully patched to not use the ASIC (thanks AMB!)
Unrelated: Sorry to @Trol for waiting more on me to return his PAL's (will do asap!)

 

[kuze]

Good stuff @Asure!