What's new
I'm slowly taking apart the AMB black label version of ddpdoj.
There's been a lot of patching. At first i thought a few simple NOPs were all that was done, but there's a bunch of subroutines as well.
It's really quite extensive. To give you an idea this is the code _just_ after the stage selection.
You can get there with a 'wpset 500000,ff,rw' in Mame's debug function.
The game expects some magic to happen when writing data into 500000, and wants to read it back from 50000.
It will only continue to run properly if magic is returned. This trick can be used to offload stuff into the ARM but also as protection.
0x246960comp.jpg
At first i thought they were just waiting one tick (4e71/nop) but there's that JSR into 247152 which is were the roms (boot vs. original) differ a whole lot.

0x247152comp.jpg

Honestly, this is a bit above my 68k skill, and i think we'll sooner have a dump of a black/white eprom from one of the carts than i end up hacking this into white label. There's a whole busload of read/write operations into 500000 expecting values back which obviously fails on real hardware, the kovsh cart has nothing there.

Done:
Decode/Re-Encode games program for other cart pcb's
If we can run unencrypted code, anything is possible. (Thanks AMB dumpers!)

Conclusion:
DDP bootleg on KOVSH is only using the decryption function of the asic.
DDP bootleg is heavily patched to go to black label mode (see the 146AA6: movea.l #$23b7b8, A0 and 146AAC: jmp (A0) thing..)
DDP bootleg could be decrypted easily and run on that killing blade pcb (Any testers? I can re-encode one for you to check..)
Seems to me the boots out there are all based on AMB's work.

I'll wait and see for a white/black selector version to appear. We know they are out there. Sooner or later someone will dump it anyway :)

In Europe? Send me the 27c322 and i'll dump it.
 
There's a whole busload of read/write operations into 500000 expecting values back which obviously fails on real hardware, the kovsh cart has nothing there.
The mame driver contains some hints there. For KOV they don't have a dump of the internal ROM, so they do a high level emulation. For later games with external ROM they actually have dumps for some versions.
For games that just offload some minor functions to the ASIC you'll probably have to port the ARM routines to M68k, then patch jump or trap instructions into the original game. (Are the trap instructions used for anything?) I assume this was already done for the bootleg versions, especially those that run without ASIC.

Apparently later games run the whole game on the ARM cpu and just pass a display list to the M68k...
 
@Asure - I'll test it on my Killing Blade, would be very interesting to find out if KB is also a candidate for DDPDOJ, that would mean KB is basically the universal donor board for Cave conversions

Still need to figure out the PAL though.
 
Last edited:
Is that wire from smd rom to PAL marked in picture present in previous KB conversion pictures posted here?
Nope, that wire isn't present on either of the KB conversions people posted pictures of. Could be a test wire that was put in to try and solve the graphics glitching

I would suggest that initially wires to the PAL were used as in other conversions to achieve it, then the functions were converted into a custom version of the PAL so that bodge wires aren't required and that the method of conversion isn't known
 
DDP bootleg could be decrypted easily and run on that killing blade pcb (Any testers? I can re-encode one for you to check..)
I'll check it if you want. I have 2 versions of the KB PCB that I can use to test but I'm not confident that it will work until we determine what the PAL is doing/how to properly modify it.
 
For games that just offload some minor functions to the ASIC you'll probably have to port the ARM routines to M68k, then patch jump or trap instructions into the original game. (Are the trap instructions used for anything?) I assume this was already done for the bootleg versions, especially those that run without ASIC.
The actual simulation for the cave pgm hardware consists of the decryption and this:

(you can see the AND FFFF D0 action ( & FFFF) in the first bit of the code at 247152.
Code:
READ16_MEMBER(pgm_arm_type1_state::pgm_arm7_type1_sim_r )
{
if (offset == 0)
{
uint16_t d = m_valueresponse & 0xffff;
uint16_t realkey = m_valuekey >> 8;
realkey |= m_valuekey;
d ^= realkey;

return d;

}
else if (offset == 1)
{
uint16_t d = m_valueresponse >> 16;
uint16_t realkey = m_valuekey >> 8;
realkey |= m_valuekey;
d ^= realkey;
return d;

}
return 0xffff;
}

I think this is simulated in the subroutine the patch jumps to.
I don't know what this exactly does (& 0xffff "and the value with 0xffff" ? ) as i'm not a Cpp expert.
|= no idea. >> no idea (NOT? what is ^= ?)

Also it would seem fair to say this bit of code eats cpu cycles, so the cartridge may never run 100% as the original. Maybe 99.9%, i'm not sure how much cpu power each opcode takes :)
 
| = bitwise or
^ = bitwise xor
>> = right shift

When you have an operator followed by an = like "|=" it will apply the operator and then set the value to the left item.
 
Hello all,

Just registered so I could contribute.

I can confirm that same sprite glitch on Espgaluda when you do a large bullet cancel.

I have the same issue with the Backgrounds disappearing on Ketsui and Espgaluda, Sheep Nova was super fast in response and is sending out the two replacement chips, so I'll report back once installed.


And, I have the DDP DOJ pgm cart with both black/white, both versions work perfectly, I received it about a year ago from arcademodbios.
 
Also it would seem fair to say this bit of code eats cpu cycles, so the cartridge may never run 100% as the original. Maybe 99.9%, i'm not sure how much cpu power each opcode takes :)
Very little. :) The logical operations are usually very fast and you can probably optimise the shifts by 8 or 16 out.

Update: https://wiki.neogeodev.org/index.php?title=68k_instructions_timings
Disclaimer: I didn't check if the core used for PGM has different instruction timings, but this should give you a general idea. And the clock speed is 20Mhz and not 12Mhz. So in short, compared to, say, the collision or sprite update code it's probably negligible.
 
Last edited:
Hello

Sorry to change subject a bit,

Can someone post photos of the ddp2 prog pcb ? ( 0354-01-FN )

I have a defective one, and I'd like to check visually if all components are OK (I'm surprise to see no clock / crystal on mine)

Thank you
 
Is there anyone who know how to fix these kov2 nine dragons game pcb?(If u know or can fix it,pls contact us directly^+^)
 

Attachments

  • 57.jpg
    57.jpg
    278.1 KB · Views: 167
  • 58.jpg
    58.jpg
    278.5 KB · Views: 184
  • 59.jpg
    59.jpg
    221.4 KB · Views: 189
  • 60.jpg
    60.jpg
    328.2 KB · Views: 181
Is there anyone who know how to fix these kov2 nine dragons game pcb?(If u know or can fix it,pls contact us directly^+^)
It looks like the security ASiC is sending back wrong responses.
It might be possible to disable ASIC and patch the main program rom. This game uses external ASIC program in the 16M chip.

A kind request: Can you please save the V205-32M eprom and not recycle it? If you can dump it with EPROM reader and post here, even better.

I can look at the main program and see what it's doing. (We have no dump of V205-32 code, only V204-32, so please read/dump the IC and upload somewhere!)
 
Bee Storm is the same as the kov2nd carts used for the conversions. It just uses a 27c160 instead of a 27c322 at U8. The jumper is set accordingly.
 
Hello all,

Just registered so I could contribute.

I can confirm that same sprite glitch on Espgaluda when you do a large bullet cancel.

I have the same issue with the Backgrounds disappearing on Ketsui and Espgaluda, Sheep Nova was super fast in response and is sending out the two replacement chips, so I'll report back once installed.


And, I have the DDP DOJ pgm cart with both black/white, both versions work perfectly, I received it about a year ago from arcademodbios.
Just to chime in here, Sheep_Nova did the same for me. I have both an Espgaluda and Ketsui with the backgrounds disapearing, and already have been told I have replacement chips in the mail.
I also have a Ketsui done from KOV2:9D, that works perfectly with no issues.
 
a customer tell me that the dodonpachi dai ou jou 's game card (convert game card) should has 2 kind of version,one is ddp black version,the other one is normal version.^+^Anyone who knows how to change the version,
 
Back
Top