Could you post some better pictures of this PCB? are there any added wires?
- Thread starter 98pacecar
- Start date
I've just received my copies of KOV SH and Killing Blade (x2) today.
Killing Blade pcbs have the same reference as posted in this thread as elegible for a suitable Ketsui/Espgaluda conversion:
PGR cart 1 (179-2):
GFX cart 1 (17
:
PGR cart 2 (179-2):
GFX cart 2 (17:
KOV SH gfx pcb is the same as the one documented in this thread, however pgr pcb is a variant (257 instead of 257-1) but seems similar except protection chip, mine is H6 and the one posted here is H8:
PGR cart (257):
GFX cart (256-1):
At first, I will try to perform the conversion using the kov cartridge, as it is properly documented (thanks @Apocalypse) as I am not an expert in this.
Killing Blade pcbs have the same reference as posted in this thread as elegible for a suitable Ketsui/Espgaluda conversion:
PGR cart 1 (179-2):
GFX cart 1 (17
:
PGR cart 2 (179-2):
GFX cart 2 (17
:
KOV SH gfx pcb is the same as the one documented in this thread, however pgr pcb is a variant (257 instead of 257-1) but seems similar except protection chip, mine is H6 and the one posted here is H8:
PGR cart (257):
GFX cart (256-1):
At first, I will try to perform the conversion using the kov cartridge, as it is properly documented (thanks @Apocalypse) as I am not an expert in this.
FWIW I socketed the program ROM on my Killing Blade (179-2) and installed the patched program ROM for Espgaluda in there. It wouldn't boot, the PGM acted as if no cart was inserted at all. though, looking at the pictures of lydz conversion he pulled a few chips and I left all of mine in so I'm going to try pulling those tonight
Seeing pictures from lydz, it seems that the protection chip is pulled out, aswell as small eprom. I also noticed that pal next to program eprom has not label on it, so it's maybe a replaced one.
PD. @twistedsymphony maybe you want to update your first post to add board PGR board 257 for KOV SH as suitable (not tested) for ddpdojbl conversion
Last edited:
done, thanks.
we don't know that. he could be soldering jumper wires on the back side of the PCB in place of the PAL that was removed.
xodaraP
Legendary
Except he's got photos of both sides of both PCBs
Where? I only saw the one photo of his Killing Blade (pcb no-0179-2) Conversion.
xodaraP
Legendary
No, there's 4
Edit: no I'm an idiot, that's KoV2.
Still, no wires modified on KoV2 conversion either. And a PAL with no writing on it in place of the usual PAL that gets pins removed and rerouted
Edit: no I'm an idiot, that's KoV2.
Still, no wires modified on KoV2 conversion either. And a PAL with no writing on it in place of the usual PAL that gets pins removed and rerouted
So pulling the ASIC the small EPROM and the PAL like in the photo results in the system booting to a static image of artifacts all over the screen (at least it's better than it not recognizing the cart at all).
the PAL looks to be an AMD PALCE22V10H, I can't read it so I'm assuming the security bit has been flipped.
the PAL looks to be an AMD PALCE22V10H, I can't read it so I'm assuming the security bit has been flipped.
with the program ROM in place it should run you'll just get garbled graphics and sound
I tested my DDPDOJ conversion this way too, just swap in the program ROM and try booting to confirm it will run, then go through the effort of swapping the rest of the ROMs.
where it's not running it definitely needs something else, be it the PAL, some hidden jumper wires, or even additional patching? it's unclear.
I tested my DDPDOJ conversion this way too, just swap in the program ROM and try booting to confirm it will run, then go through the effort of swapping the rest of the ROMs.
where it's not running it definitely needs something else, be it the PAL, some hidden jumper wires, or even additional patching? it's unclear.
Everybody missed that pin 5 of the LS138 adres decoder on the board from lydz appears cut. (G2 enable)?
If these boards just run unencrypted code, we can get rid of the protection and any memory ram/rom it can appear at and interfere with.
I assume the cartridge can just map the prot device somewhere in the memory and values can be written to it, and a result will appear at some memory address.
Anyway I really need some of this hardware to play with and boatloads of free time to finish my projects, but life is too busy atm
If these boards just run unencrypted code, we can get rid of the protection and any memory ram/rom it can appear at and interfere with.
I assume the cartridge can just map the prot device somewhere in the memory and values can be written to it, and a result will appear at some memory address.
Anyway I really need some of this hardware to play with and boatloads of free time to finish my projects, but life is too busy atm
I did some more research.
To me it seems all the dumps that are public are encrypted and the versions by mr. hotglue are either re-encrypted or patched so that they don't care about the ARM. (They use init_ket or init_ddp2 for example)
The process would be something like
- Modify MAME so that the rom is decrypted and the decrypted region can be saved.
- Modify MAME so that the read/writes to shared ram are logged, or dig thru the code. Patch them out.
- Set up a new machine in mame which is PGM + no encryption + no shared ram, test the game to the death..
I'm not sure if the protection is _just_ startup protection, i didn't have enough time to dig into it. Others may comment. Games can read/write to the arm at any point? Not sure..
Once the protection is patched you can just stick the unencrypted code on a 27C322 or 160 and run on a cart without arm/prot device, i think the main pgm unit can run unencrypted code as-is. Others pls. comment
As for the carts out there, probably they are re-encrypted to match whatever pcb they need to run on, which also sort-of protects the work done by others.
Obviously this is not the case with the version from @lydz as it seems unprotected and unencrypted code as no arm is present.
Edit: Yep, all is in src/mame/machine/pgmcrypt.cpp and to re-encrypt we just apply it all in reverse order i'd say.
DDP3, KET and ESPGAL all use the same arm type handler 1, (DDPDOJ is an unknown at this point.) (See pgmprot_igs027a_type1.cpp)
I did not look close enough to confirm if this is just using decryption and nothing else.
Seems there was(is?) at least one emulator called "CAVEUI" which runs unencrypted program roms for some cave titles.
"CAVEUI Is An Emulator With Cave/SH3 & Other Cave Shooters Of PGM/IGS Board."
To me it seems all the dumps that are public are encrypted and the versions by mr. hotglue are either re-encrypted or patched so that they don't care about the ARM. (They use init_ket or init_ddp2 for example)
The process would be something like
- Modify MAME so that the rom is decrypted and the decrypted region can be saved.
- Modify MAME so that the read/writes to shared ram are logged, or dig thru the code. Patch them out.
- Set up a new machine in mame which is PGM + no encryption + no shared ram, test the game to the death..
I'm not sure if the protection is _just_ startup protection, i didn't have enough time to dig into it. Others may comment. Games can read/write to the arm at any point? Not sure..
Once the protection is patched you can just stick the unencrypted code on a 27C322 or 160 and run on a cart without arm/prot device, i think the main pgm unit can run unencrypted code as-is. Others pls. comment
As for the carts out there, probably they are re-encrypted to match whatever pcb they need to run on, which also sort-of protects the work done by others.
Obviously this is not the case with the version from @lydz as it seems unprotected and unencrypted code as no arm is present.
Edit: Yep, all is in src/mame/machine/pgmcrypt.cpp and to re-encrypt we just apply it all in reverse order i'd say.
DDP3, KET and ESPGAL all use the same arm type handler 1, (DDPDOJ is an unknown at this point.) (See pgmprot_igs027a_type1.cpp)
I did not look close enough to confirm if this is just using decryption and nothing else.
Seems there was(is?) at least one emulator called "CAVEUI" which runs unencrypted program roms for some cave titles.
"CAVEUI Is An Emulator With Cave/SH3 & Other Cave Shooters Of PGM/IGS Board."
Last edited:
DDP3 is DDPDOJ and it looks like the DDPDOJ "bootleg" is setup to use the KOVSH protection/encryption. Honestly this is the only one that makes sense to me, it's patched to be a straight drop in ROM swap with KOVSH.
in MAME KET and ESPGAL bootlegs are setup to use the DDP2 protection/encryption, which is pgmprot_igs027a_type2.cpp
Type 2 is used by
KOV2, KOV2 9 Dragons, DDP2, Martial Masters, Dragon World 2001, and Dragon World Pretty Chance. I've looked at the DW2001 and DWPC ROM boards and they use 27c4096 EPROMs for the text ROM which isn't big enough for KET or ESPGAL, so I'm assuming that's why those carts aren't on the acceptable donors list.
According to pgmprot_igs027a_type2.cpp the encryption is in the external ARM ROM, so if that's the only thing that's encrypted and it's being left in place with the program ROM patched to use it as-is then it makes sense that there are several potential donors. What doesn't make sense to me is why Gladiator and Demon Front are both listed as potential donors in MAME as well, as those use the Type 3 protection which is a bit different than type 2 and does not have an external ARM ROM. (unless of course the ARM code is simply patched out entirely). Killing Blade seems to make even less sense since it doesn't use Type 2 or Type 3 protection (though based on lydz photo it seems that they've likely disabled the security/encryption entirely).
A
Apocalypse
MAME generates a ready to use file by dumping the decrypted area.
oneleaf86
Grand Master
KalessinDB
Grand Master
Very interesting. I would pick it up, but don't wanna bid against you guys...
