What's new
good explanation, I'd only like to add: it might be 2 way, and ARM side expecting to see some magic values written from M68K side too, and if it's not - ARM will crash/reset game or smth like that.
In most cases we have the code dump from the ARM and we know what to do.
sadly, in most cases we have NO dumps of internal ARM firmwares...
 
I've completely removed the ARM in MAME and was still able to play the game to the end so problem is elsewhere.
 
Thank you all for your explanations, that cleared up my understanding a lot :)

I've spent the better part of today searching the net / debugging in MAME trying to set a breakpoint for NVRAM access, but so far, no success...
My idea was to clear kovsh nvram, set a score and upon entry of the 3rd letter, repeatedly step through the instructions with hard resets in between, trying to discover a saving routine (if such a thing exists). Maybe there's a better way to do it...

For reading nvram, I have even less of a starting point at the moment.

I still have some more ideas like compiling MAME myself with adjustments, that I'd like to try when I have the time.
 
Alright, just going to bluntly state what I've tried and found out (or rather, mostly didn't) so far. Maybe it's useful for somebody, maybe not. I may have been looking in spots far away from the actual cause of the error.

So what I first had to sort out was that the ROM_REGION 0x20000 sram / ROM_LOAD section in pgm.cpp (see) is a fallback, and only effectively loaded when ~/.mame/nvram/[romset_id]/sram doesn't exist. Otherwise, the latter file is loaded into sram instead.

That file's size is 128K = 0x20000 (corresponding to the above), but if you fill it with, for instance, FE*0x20000, start the emulation and look into the program space memory, you can see that this is somehow spread out between 0x800000 and 0x8FFFFF (meaning everything in-between is FEFE... and so on).
In pgm.cpp, L315, the "sram" region is mapped to 0x800000..0x81ffff, and I'm not sure yet where that discrepancy comes from.

That line, conveniently, is marked with the comment "Main Ram", which is, well, true :D
If you let the emulation run, you'll very quickly see that all sorts of stuff happens here, it's not that just data that one would casually identify as non-volatile (scores etc.) is hold there, as I had previously assumed.

So you can't just e.g. wpset 0x800000,0x100000,rw (or wpset 0x800000,0x20000,rw, for that matter) and call it a day, it will just be hit all the time. Instead, you actually have to get at least some sense about where things are stored (who would've thought).

Therefore, what I came up with next was
1. I deleted ~/.mame/nvram/kovsh/sram, and re-created it, filling it completely with 0xFE bytes only so I could recognize it later
2. booted into WL, waiting until the scoreboard comes up, and then creating a dump of the 0x800000..0x8FFFFF memory region
3. hard-reset, booted into BL, waiting for the scoreboard to come up, leading to the default scores being saved to sram
4. hard-reset again, booted into WL and created a second dump, at the same spot where I did the first

Then I compared the two dumps. There are many, many differences. It's not that BL just saves some score info and maybe some additional miscellaneous stuff. I don't know what it all entails, but it's definitely more than that.

I wrote a Python script that identifies all differing, contiguous regions between the two dumps and generates code that produces a log message if an incoming address lies within one of the regions (saying which region it was etc.). I shoved that code into all the high-level read/write functions in the 68k emulator in MAME, hoping to get a lead on an imagined "saving routine" that way. Will gladly share a MAME fork in case somebody's interested, but it's nothing special, really.

What I can see this way is certainly interesting, but doesn't help, because A) none of the regions are hit when playing through the neuralgic spot in stage 5, and more importantly, B) none of the memory regions are hit when a new score is reached. I guess I must have overlooked something. :(

At this point I'm not sure if going down this route further will bring about any new insight that's useful for the problem at hand.
In fact if pressed I'd say no, other things increasingly lead me to believe that a nvram/sram interaction is not the cause.


Isn't it curious that the exact debug information (program counter etc.) is different each time, but the hang still occurs in the exact same spot as far as the gameplay is concerned?
Btw, I've looked up the instruction at the PC in MAME that was displayed on my real PGM one time the address error happened.
The PC is 0x13D07E; assuming one can just reference between real HW and MAME 1:1, the instruction is "move.b $80380b.l, D1". How can that be an invalid address, I wonder?

I've taken a few other stabs in the dark. If it's of any use at all, at least nobody else has to try:
  • Could reproduce that the game still runs splendidly after completely removing the ARM. This also increased performance massively. The fast forward feature could accelerate to ~130% on my setup before, after to ~500%. I don't think the ARM really ran that many more instructions :D I'd attribute that to some inefficiencies in MAME coding. Of course, the freeze still doesn't happen.
  • Under- & overclocked the 68k emulator to various frequencies (19.9, 20.1, 40, and 16Mhz, each w/ and w/o the ARM). Everything works fine with the expected effects on slowdown. No freeze. My thought was that maybe real HW could have some slightly divergent oscillators, leading to some obscure illegal interaction. The results of course don't say much on how this would behave on real HW.
  • In MAME, the PGM emulation's video refresh rate is hardcoded to 60hz. It set it to 59.17hz, according to this thread, this is the refresh rate output by original HW. No freeze.
  • One thing I still want to try is, running the modified kovsh set on Finalburn Neo/-Alpha and see how it's digested there. Checksums don't match so it doesn't start (on MAME the -debug switch circumvents that). So far I didn't have the motivation to dig further on this end.
That we don't get the bug in MAME certainly has to do with inaccurate emulation. Some comments in the 68k code don't exactly raise confidence in it, also the boss explosions don't glitch out in WL on MAME as they do on real hardware.
But then again, WL obviously doesn't hang on the original WL hardware. Maybe arcademodbios has changed something in the WL code? Speaking of which, do we have an update on the AMB dual cart @twistedsymphony?
 
From memory he never had it listed, you had to specifically request it.
 
outside of Ketsui, DDPDOJBL, and Espgaluda none of the PGM games have been patched to allow for conversion.
 
That we don't get the bug in MAME certainly has to do with inaccurate emulation. Some comments in the 68k code don't exactly raise confidence in it, also the boss explosions don't glitch out in WL on MAME as they do on real hardware.

But then again, WL obviously doesn't hang on the original WL hardware. Maybe arcademodbios has changed something in the WL code? Speaking of which, do we have an update on the AMB dual cart @twistedsymphony?
So, when you've got odd bugs like this in "real" game development it's (often) one of three things:
- cache
- dma
- threads
I don't think the m68k used in PGM has a data cache that needs to be flushed/invalidated, and I don't think the game is multithreaded, though you can get problems like this from interrupt handlers as well.
There is possibility that one of the undocumented pins on the cartridge interface is for DMA from the ASIC. The emulation in Mame may not implement this, and produce a different result from the hardware. My PCBs definitely don't implement DMA, so if the DMA controller sits on the motherboard and expects to transfer usable data it may transfer whatever is on the bus instead.

I assume the boss explosion glitch is a limit on the sprite hardware. I bootstrapped an m68k cross compiler last week to write some tests, but so far didn't get around to... (I used the script from http://www.aaldert.com/outrun/gcc-auto.html with MingW)
 
Last edited:
There is possibility that one of the undocumented pins on the cartridge interface is for DMA from the ASIC. The emulation in Mame may not implement this, and produce a different result from the hardware. My PCBs definitely don't implement DMA, so if the DMA controller sits on the motherboard and expects to transfer usable data it may transfer whatever is on the bus instead.
Interesting suggestion - do we know if the freeze happens on your ROM PCBs?

(quicky went through the respective thread; this user wanted to check but apparently dropped the subject)
 
hi,

i recently purchased 3 conversions and opened my DDPDOJ.

it appears it’s made with a 257 Pcb such as these

*IGS PCB No-0257-1 (PRG) - Knights of Valour Super Heroes *DDP DOJ conversion 1 conversion 2


However on mine pin 1 of U4 isn’t lifted and connected to 3.3v
What’s the purpose of doing so?

Another difference is that on my conversion the VCC is taken from U5 trough 2 diodes.

I’m wondering about fixing this according to the previously mentioned conversions. (VCC straight from the regulator instead of diodes, lifting pin 1 of U4 and connect to VCC).
 
Last edited:
However on mine pin 1 of U4 isn’t lifted and connected to 3.3v
What’s the purpose of doing so?
It has to do with the chip being used. the on the U4s where we replaced it with a MX29L3211, pin 1 is used for write enable. If your conversion used a different chip that used pin 1 for a different function then it might not need to be lifted.
 
Hi All,
Does anyone know if a cartridge conversion of the game "spectral vs Generation" has already been made ?
 
Hi All,
Does anyone know if a cartridge conversion of the game "spectral vs Generation" has already been made ?
I think that already had an official cart release so no special conversion stuff should be needed like for cave games.

Might have other stuff in the cart as well though making bootlegs hard to build.
 
Confirmed there's an official cart release for Spectral Vs Generation. It's my rarest cart by a good bit.
 
do we know if the freeze happens on your ROM PCBs?
I asked @ekorz if he could check and he kindly did so :)
He could indeed play through the first WL loop just fine! Here's a short video of the ending sequence he recorded: click

Could there be a relatively easy way to circumvent the bug on Knights of Valor conversions, maybe even without further modification of the ROM file?
 



Here's a conversion of DDPDOJ PCB 0256 and 0257

PRG :
U1 : M27C322
U11 : MX26L6420
GFX/Samples:
U1, U3, U6 : MX26L6420
U4 : m59PW1282 (therefore pin 1 is not lifted)


It seems to me there's a design flaw regarding the VCC on the GFX/SAMPLE board.

2 rectifier diodes are used (1N4001), which have 0.7V forward voltage drop each, so 1.4V total I presume.

5V-1.4V=3.6VCC


I think it would be better to have everything getting VCC from U12 or U13 right ?
 
Confirmed there's an official cart release for Spectral Vs Generation. It's my rarest cart by a good bit.
Yes very hard to find, searching one for 2 years now.
The only one i've seen was at 800€... Like it but not a t this price
So if someone could do a convert...
 
Back
Top