Asure
Grand Master
Should. (It's only gonna leak some day eventually.)
Raiden II Backup battery/ Hi-Score Save
- Thread starter twistedsymphony
- Start date
alamone
Professional
Raiden II / DX high-score saving — RE findings
Sorry for the necro, but everything I've seen from RE analysis points to high score saving being an urban legend.
TL/DR: I reverse-engineered the high-score path in Raiden II and Raiden DX and tested rtw's "magic value in the custom" idea directly. Across every ROM revision I could run, the main CPU performs zero reads from the battery-backed custom at boot. That means it's impossible for the main CPU to be checking any "magic word" read from the battery backed custom. There is also no save/restore code in any of them.
More details:
What the code does (both games, confirmed by disassembly + live MAME tracing):
- At every power-on the boot routine unconditionally zero-fills all work RAM, then builds the high-score table from hardcoded ROM defaults (R2: a compute loop; DX: copied from per-course ROM tables, initials hardcoded to "***"). It reads no saved data. The display/name-entry code only ever touches that volatile work-RAM table. Nothing writes saved scores into it — I tapped every write to the table region and only the wipe and the default-builder ever fire.
Testing rtw's hypothesis (could the SEI252 hold a magic value the CPU checks?):
- This was the right place to look, and it's the one thing MAME-side traces miss, because MAME doesn't map the SEI252's interface — so any CPU access to it shows up as *unmapped*. I logged unmapped accesses across a full boot. Result: 92 unmapped writes (COP microcode / sprite setup), zero unmapped reads. The CPU programs the customs but never reads a value back from them. I also traced the COP (SEI1000) itself — it only does the per-frame sprite DMA and standard math macros; it never touches the score region or reads the SEI252.
The variant sweep (the interesting part):
- Since the difficulty tiers are genuinely different builds, I ran the same unmapped-read test on ~20 sets: raiden2j, raiden2 (US Fabtek — turns out it's 2 bytes from raiden2j, both a region tag), raiden2u, the *easier* family (raiden2e/eu/ea/eua/eub/es/i/nl/sw — including the different-RAM-layout builds), the *harder* (raiden2k, raiden2dx), the 4-ROM prototype (raiden2eup), and Raiden DX in every region I have. All of them: 0 custom reads. (raiden2g/hk were the only outliers — both fail romset verification and crash, and they're single-ROM region clones of raiden2 anyway.)
On the battery: it powers only the SEI252 (matches twistedsymphony's trace; I confirmed it on my own board — work RAM runs on plain +5V, not backed). That's the sprite-key suicide cell, and it's redundant on Raiden 2/DX because the keys are reprogrammed from ROM every boot — which is why boards run perfectly with it dead or removed.
The one thing software analysis can't settle: the SEI252's internal SRAM is a battery-backed, undocumented black box that MAME doesn't emulate. I can't see inside it. But it's a sprite-decryption chip with no path to the score RAM, and no revision ever reads it for that purpose — so every piece of evidence we *can* inspect says the feature doesn't exist.
Credit to twistedsymphony's earlier teardown for the battery trace and the first look at the default-table builder — this lines up with and extends it.
Sorry for the necro, but everything I've seen from RE analysis points to high score saving being an urban legend.
TL/DR: I reverse-engineered the high-score path in Raiden II and Raiden DX and tested rtw's "magic value in the custom" idea directly. Across every ROM revision I could run, the main CPU performs zero reads from the battery-backed custom at boot. That means it's impossible for the main CPU to be checking any "magic word" read from the battery backed custom. There is also no save/restore code in any of them.
More details:
What the code does (both games, confirmed by disassembly + live MAME tracing):
- At every power-on the boot routine unconditionally zero-fills all work RAM, then builds the high-score table from hardcoded ROM defaults (R2: a compute loop; DX: copied from per-course ROM tables, initials hardcoded to "***"). It reads no saved data. The display/name-entry code only ever touches that volatile work-RAM table. Nothing writes saved scores into it — I tapped every write to the table region and only the wipe and the default-builder ever fire.
Testing rtw's hypothesis (could the SEI252 hold a magic value the CPU checks?):
- This was the right place to look, and it's the one thing MAME-side traces miss, because MAME doesn't map the SEI252's interface — so any CPU access to it shows up as *unmapped*. I logged unmapped accesses across a full boot. Result: 92 unmapped writes (COP microcode / sprite setup), zero unmapped reads. The CPU programs the customs but never reads a value back from them. I also traced the COP (SEI1000) itself — it only does the per-frame sprite DMA and standard math macros; it never touches the score region or reads the SEI252.
The variant sweep (the interesting part):
- Since the difficulty tiers are genuinely different builds, I ran the same unmapped-read test on ~20 sets: raiden2j, raiden2 (US Fabtek — turns out it's 2 bytes from raiden2j, both a region tag), raiden2u, the *easier* family (raiden2e/eu/ea/eua/eub/es/i/nl/sw — including the different-RAM-layout builds), the *harder* (raiden2k, raiden2dx), the 4-ROM prototype (raiden2eup), and Raiden DX in every region I have. All of them: 0 custom reads. (raiden2g/hk were the only outliers — both fail romset verification and crash, and they're single-ROM region clones of raiden2 anyway.)
On the battery: it powers only the SEI252 (matches twistedsymphony's trace; I confirmed it on my own board — work RAM runs on plain +5V, not backed). That's the sprite-key suicide cell, and it's redundant on Raiden 2/DX because the keys are reprogrammed from ROM every boot — which is why boards run perfectly with it dead or removed.
The one thing software analysis can't settle: the SEI252's internal SRAM is a battery-backed, undocumented black box that MAME doesn't emulate. I can't see inside it. But it's a sprite-decryption chip with no path to the score RAM, and no revision ever reads it for that purpose — so every piece of evidence we *can* inspect says the feature doesn't exist.
Credit to twistedsymphony's earlier teardown for the battery trace and the first look at the default-table builder — this lines up with and extends it.
, we should be able to lay this issue to rest now.CamoYoshi
Professional
Was going to add on that I have both a Raiden II and DX boards, one with a good battery and one without a battery and I have never noticed a difference between the two with/without, even with swapping the battery between the boards. I always assumed it was intended for some sort of use during the hardware design phase during development but then never ended up getting used. Nice to know the more intricate details.
