You guys are totally awesome for helping me!
I got the Saturn's CD BIOS working. Now MAME does this:
OK~... at least we know that we can't use MAME for this. We've cleared that from our mind, and we know the score, now. It's Yabause and Mednafen, all the way.
So, looking at the contents of the VRAM in the Saturn is quite confusing. The Saturn has not one, but two - count them, TWO
- video hardware chips, and they're both 512KB each.
But~! All is not lost, because Yabause has some Saturn-specific debugging features that might help us.
The first video chip in the Saturn, called 'VDP1' is used for foreground drawing. 'VDP2', though, is the 'Big Daddeh', which draws the background.
VDP2 has several fixed 'screens', apparently, and a game can turn them on and off, depending on intended usage. There are four 'Normal Scroll' screens, called NBG0, NBG1, NBG2, and NBG 3. Now, Yabause lets you view those screens independent of each other. The buttons only appear on one of these screens - NBG1:Bigger link
Look at dis juicy information, right here, about NBG1:
Bitmap Address = 20000
Bitmap Palette Address = 30
Screen Scroll x = BLAH BLAH BLAH
It tells us an address - '20000'. The address in VRAM? Well, probably yeah. And we know it's in VDP2, because that's where NBG1 lives.
Because of how awesome Yabause is, we've managed to narrow our search for the treasure quite narrowly.
(At this point, I did lots of fiddling with the game in the emulator)
So, VDP2's RAM has lots of blank space ('00'), with numerous 88-byte blocks of similar data, at regularly-spaced intervals.
OK, I found where the button is:Bigger link
We did it! I do declare the top bit of the 'BEGINNER' blue button to start at 05E2687B, and stop at 05E268CC.
Step one completed
(At this point, I continued fiddling, and started to lose my ****)
Yabause has a really nasty bug. If you set a write breakpoint in the CPU debugger, open the Memory Editor from within the CPU debugger window, 'Goto' that address, it will reach the breakpoint and try to open a second CPU debugger window (with the first one still open), and crash.
Mednafen is totally crazy. I can't make head nor tails of what it's doing. It ignores my breakpoint, the addresses are different, the address watch in the CPU debugger doesn't refresh correctly, it's all crazy as hell. I'm done with you, Mednafen.
(More investigation takes place, and I eventually start shouting at the computer, and accuse it of ignoring my breakpoint out of malevolence.)
So, I've got a working write-breakpoint at the address where the button is drawn in VRAM.
It makes three trips, there. The first two appear to be for filling the area with zeroes, presumably in readiness for drawing. I'm no Michael Abrash, but even I can tell it's putting the contents of R0 into the de-referenced address in R1.Bigger link
But the third and final time it hits the breakpoint looks like the real deal:Bigger link
Unfortunately~... well... I think I need some advice on what I should be looking for, here. Could anyone tip me-off on how to spot... where the text comes from? Am I just looking for a filename, somewhere, or... ?
I'm not even sure where, in that instruction, it's writing to 05E2687C:
The instruction: 'mov.l r2, @(0x00C, r3)'
equates to(?): 'mov.l 00005A01, @(12, FFFFFF80)'
It doesn't even make sense. FFFFFF80 + 12 is beyond the bounds of the entire RAM. And how does '@(12, FFFFFF80)' somehow equal 05E2687C
The manual for the Hitachi SH-2 is drier than reading MSDN.
I need to go simmer down, some, because I've spent all day looking at this and not making any actual progress