If none one has the AMB cart, maybe we do a little donations drive to get the cart and have it dumped? Maybe have it go to whomever is closest to AMB that can dumpy it? I’ll chip in $30 towards it.
- Thread starter 98pacecar
- Start date
A
Apocalypse
Seems you were right, it can't...
Agree, but no one that frequents here seems to have it or if they do, can confirm if it does or does not crash, etc...so didn’t want this to get stagnant and fall off. So I don’t mind putting some $$ towards getting the cart to find out if it works and dump it or towards compensating someone for their time to make a 2 in 1 version that works.
PASTBLASTER
Grand Master
I'm down to drop $20 into the fund.
I'm shocked no one here has the AMB one.
I'm shocked no one here has the AMB one.
dr_myslihiiri
Student
His Cave conversions cost 200 € (~$220) a piece. I tried buying an Espgaluda cart off him before sheep_nova’s conversions were a thing, but never heard back from him, so IDK whether they’re actually available or not.
He quoted me 200 Euro for the dual cart about a year ago, but you have to specifially ask him for it on e-mail.
I asked if it had the bug specifically because I know of other patched games he's sold with game breaking bugs.
Unaware, I recently got me a DDP DOJ DUAL cart as well - I've now read the whole thread because I wanted to know why WL (old ver.) crashes ~every 2nd time after the copyright screen with the error screen reported on post 941. It calmed my curiosity to know it's most certainly related to VRAM and the high score data.
The workaround explained on post 1047/1071 does not work for me. DIP 8 has to stay off, else BL consistently crashes with "ADDRESS ERROR" after copyright warning, and WL consistently crashes with error screen shown in post 941. After some random twiddling, and with DIP 8 off, both WL and BL boot consistently for me now, and as I don't need to save scores, this bug it not a big deal for me.
BUT, sigh....
it too hard-freezes on stage 5 (the exact same spot as reported on post 1006) with only the music still playing. It happens every time and only on WL. I have a V3 system board with the coin-cell battery in case it's relevant. So far I get slightly different behavior: one time it just freezed with no error/debug info displayed whatsoever, one time it freezed with "ADDRESS ERROR" instead of "OPCODE ...". I can provide screenshots if it somehow helps.
It's awesome that the game can run on the PGM. I thank all involved for your hard work making this possible. Still, when you go the extra mile of not going with one of the ports of the game but with a PGM cart instead, where it should on paper run without any compromises... it really bogs me and I think we must do better! WL cannot be played until the end (not even a 1-ALL is possible).
I got my cart from eBay, meanig AMB probably didn't manufacture it. I suspect it has the same ROM on it that can be found in this thread. Still, if I can be of help somehow, let me know. I too want a proper version and don't want this to fade away.
The workaround explained on post 1047/1071 does not work for me. DIP 8 has to stay off, else BL consistently crashes with "ADDRESS ERROR" after copyright warning, and WL consistently crashes with error screen shown in post 941. After some random twiddling, and with DIP 8 off, both WL and BL boot consistently for me now, and as I don't need to save scores, this bug it not a big deal for me.
BUT, sigh....
it too hard-freezes on stage 5 (the exact same spot as reported on post 1006) with only the music still playing. It happens every time and only on WL. I have a V3 system board with the coin-cell battery in case it's relevant. So far I get slightly different behavior: one time it just freezed with no error/debug info displayed whatsoever, one time it freezed with "ADDRESS ERROR" instead of "OPCODE ...". I can provide screenshots if it somehow helps.
It's awesome that the game can run on the PGM. I thank all involved for your hard work making this possible. Still, when you go the extra mile of not going with one of the ports of the game but with a PGM cart instead, where it should on paper run without any compromises... it really bogs me and I think we must do better! WL cannot be played until the end (not even a 1-ALL is possible).
I got my cart from eBay, meanig AMB probably didn't manufacture it. I suspect it has the same ROM on it that can be found in this thread. Still, if I can be of help somehow, let me know. I too want a proper version and don't want this to fade away.
Last edited:
I got DOJDUAL.bin running on the MAME debugger (0.214) through the kovsh driver. I can't reproduce the WL Stage 5 freeze bug. (initially still got the error screen reported on post 941, as expected)
For reference, I set it up is like this (replace "ddp_doj_u1.bin" with "DOJDUAL.bin").
Unzip official kovsh.zip, replace as above (the other *.u* files are from official ddp3.zip);
sha1sums are thus:
and then re-zip. Then
Played until Stage 5 and made a savestate maybe a screen before the spot in question. It doesn't freeze, regardless of what I do afterwards. Also did another run (hard-reset, played until there again), same result.
I'll compare game/machine settings MAME vs. my PGM and see if theres any differences that could provide a lead (though I doubt it).
Otherwise... where does that leave me? I can manage higher level programming, but when it comes to 68k asm, I may have already hit a wall here (despite my nick haha, just so happens that many of my favorite games run on this CPU).
Will try some things and report if I find something, otherwise I'll pass from here. Would also throw a few $$ into the pot for the AMB cart so we can dump it, provided it's free of the bug.
Maybe a very stupid question ahead, kinda lost the overview already:
The reason why we don't go from a "fresh" arcade black label romset (having both BL&WL) to have a blank slate, and work towards getting that to boot on PGM was, that we don't know (yet) what it entails to get that to boot, right?
For reference, I set it up is like this (replace "ddp_doj_u1.bin" with "DOJDUAL.bin").
Unzip official kovsh.zip, replace as above (the other *.u* files are from official ddp3.zip);
sha1sums are thus:
$ sha1sum *
1cf1863495a18c7c7d277a9be43ec116b00960b0 a0600.rom
c33c3398dd8e479c9d5bd348924958a6aecbf0fc a0601.rom
3d0ed684dc5b269238890836b2ce7ef46aa5265b a0602.rom
ee526655369bae63b0ef0730e9768b765c9950fc a0603.rom
53219376056f4766dc5236735599d982ceb56b84 a0604.rom
eef1cd566bc70ebf45f047e56026803d5c1dac43 b0600.rom
0542348c6e27779e0a98de16f04f9c18158f2b28 b0601.rom
99a3fe337c13702c9aa2373bcd1bb1befd0e2a13 b0602.rom
621b38c05f33277608d58b49822aebc930ae4870 kovsh_v100_china.asic
06ab202f6bd5ebfb35b9d8cc7a8fb83ec8840659 m0600.rom
5613a5bbbb9b9ad5438680e1c9bf43fe8f4dd5ed p0600.322
fd3c47cf0b8b1e20c6bec4be68a089fc8bbf4dbe t0600.rom
1cf1863495a18c7c7d277a9be43ec116b00960b0 a0600.rom
c33c3398dd8e479c9d5bd348924958a6aecbf0fc a0601.rom
3d0ed684dc5b269238890836b2ce7ef46aa5265b a0602.rom
ee526655369bae63b0ef0730e9768b765c9950fc a0603.rom
53219376056f4766dc5236735599d982ceb56b84 a0604.rom
eef1cd566bc70ebf45f047e56026803d5c1dac43 b0600.rom
0542348c6e27779e0a98de16f04f9c18158f2b28 b0601.rom
99a3fe337c13702c9aa2373bcd1bb1befd0e2a13 b0602.rom
621b38c05f33277608d58b49822aebc930ae4870 kovsh_v100_china.asic
06ab202f6bd5ebfb35b9d8cc7a8fb83ec8840659 m0600.rom
5613a5bbbb9b9ad5438680e1c9bf43fe8f4dd5ed p0600.322
fd3c47cf0b8b1e20c6bec4be68a089fc8bbf4dbe t0600.rom
and then re-zip. Then
$ mame kovsh.zip -debugPlayed until Stage 5 and made a savestate maybe a screen before the spot in question. It doesn't freeze, regardless of what I do afterwards. Also did another run (hard-reset, played until there again), same result.
I'll compare game/machine settings MAME vs. my PGM and see if theres any differences that could provide a lead (though I doubt it).
Otherwise... where does that leave me? I can manage higher level programming, but when it comes to 68k asm, I may have already hit a wall here (despite my nick haha, just so happens that many of my favorite games run on this CPU).
Will try some things and report if I find something, otherwise I'll pass from here. Would also throw a few $$ into the pot for the AMB cart so we can dump it, provided it's free of the bug.
Maybe a very stupid question ahead, kinda lost the overview already:
The reason why we don't go from a "fresh" arcade black label romset (having both BL&WL) to have a blank slate, and work towards getting that to boot on PGM was, that we don't know (yet) what it entails to get that to boot, right?
Last edited:
You could set a breakpoint in MAME in the code that emulates the ASIC (it is high-level emulated, even in cases where they have the dump of the ARM code) and see if it is hit, then look at which code the M68k is executing at that point.
Yes, I had your post 1021 in mind, however there are some things I still don't understand about it (probably making an idiot out of myself here 
).
If you already did it then I guess I don't have to dig deeper here, but out of pure interest, where did you get/calculate that address from (0x50000)? Do I have to set a breakpoint or a watchpoint? In your post it looks like a range to me, and only watchpoints allow for ranges... I need to read up on arcade debugging.
By the way, if I press F6 "Run to Next CPU", I see that ARM7 (little) ':prot' is doing stuff all the time, and the program counter for it is all over the place! If this the ASIC we're talking about, these must be other "normal", non-protection related routines that are offloaded from the CPU, no? But if I'm not mistaken I've read that the conversions are freed of the ASIC dependency... call me confused.
On a similar note, would it be possible to set a breakpoint to check for NVRAM access then? Where would I look for the address in question?
).If you already did it then I guess I don't have to dig deeper here, but out of pure interest, where did you get/calculate that address from (0x50000)? Do I have to set a breakpoint or a watchpoint? In your post it looks like a range to me, and only watchpoints allow for ranges... I need to read up on arcade debugging.
By the way, if I press F6 "Run to Next CPU", I see that ARM7 (little) ':prot' is doing stuff all the time, and the program counter for it is all over the place! If this the ASIC we're talking about, these must be other "normal", non-protection related routines that are offloaded from the CPU, no? But if I'm not mistaken I've read that the conversions are freed of the ASIC dependency... call me confused.
On a similar note, would it be possible to set a breakpoint to check for NVRAM access then? Where would I look for the address in question?
I remember debugging these games with older MAME version 0.160. There was no emulation of the ARM, AT ALL.
There is still a region called :prot which is probably being checked by the game, but that was it, so sd we already know in these cases, the ARM is not needed at all. You just need to patch or integrate into the PROM code whatever that :prot region had.
I have several of these conversions and I saw the following ones:
* ddpdoj running on Knights of Valour Super Heroes
* Espgaluda running on Knights of Valour 2 (KOV2)
* Espgaluda running on Demon Front
* Ketsui running on Knights of Valour 2 (KOV2)
* Ketsui running on Demon Front
From my initial work, the main CPU can read/write to 0x50000 (to 0x50000,FF) and the ARM will do some magic on whatever is written there.
You can see the magic in the simulation that is done (for example) in
https://github.com/mamedev/mame/blob/master/src/mame/machine/pgmprot_igs027a_type1.cpp
So, when you run the original ddpdoj black/white label (not patched, not the bootleg) in MAME with the debugger, add a watchpoint:
Code:
wpset 50000,ff,rwThere's a magic black box sharing this region. It's a window into the ARM cpu. In most cases we have the code dump from the ARM and we know what to do. Let's say the black box will do square root times 2 and if higher than 4 XOR that number. Game writes "0x05" to 0x50000-01 and a few cycles later reads back this value.. it must match the square root times 2 + XOR function. If not.. game crashes or shows no enemies etc.
Anyway take a look at the original black/white label and see what they do with MOV into that area. There's a whole busload of functions.
(And on the hacked one, all of those are patched into a set of routines in the normal region, with the 68K cpu getting a correct answer.)
So when i knew where the game crashed, i made a state, set my WP and watched what happens. Nothing :/
On DDPDOJ you can see it when you selected the ship, the game will freeze on your WP after the door of the bay opens and it zooms the ship down
It's in the machine i linked earlier:
Check the readwrite_handler:
Code:
void pgm_arm_type1_state::init_ddp3()
{
pgm_basic_init(false);
pgm_py2k2_decrypt(machine()); // yes, it's the same as photo y2k2
arm_sim_handler = &pgm_arm_type1_state::command_handler_ddp3;
m_maincpu->space(AS_PROGRAM).install_readwrite_handler(0x500000, 0x500005, read16_delegate(FUNC(pgm_arm_type1_state::arm7_type1_sim_r),this), write16_delegate(FUNC(pgm_arm_type1_state::arm7_type1_sim_w),this));
}
Last edited:
