Why would this happen in the first place? Is it common for these games to dump state to audio? Is it a deliberate debugging tool for the game devs?
Basically the way GBA sound works is there is a buffer in RAM that the audio is streamed from, and an interrupt is supposed to signal the hardware to begin reading data from the beginning of the buffer again. However, if the interrupt is never fired (such as when the game crashes), the audio stream will go beyond the buffer and read other parts of memory.
Now if this was a hack where the thought was, "What if we dumped the whole ROM to the audio buffer, could we recover the complete ROM through audio analysis?"
- run the function to fetch the next batch of audio to audio working RAM
- reset the audio read pointer to the beginning of audio working RAM
When interrupts are disabled (because the game has crashed), that "reset pointer" code never runs and the audio circuit keeps reading way past the end of its buffer, incrementing forever. Eventually it would increment into the 0x08000000 range in which case the sounds it's emitting map directly to the bits in the ROM.
remember that it’s not like the music is just there as raw audio, the raw audio is just the sounds of the different instruments
Here's what's going on:
- reading from ROM is slow, relative to working RAM; the ROM is mapped to the same memory address space as the RAM, but reading a ROM address takes (I think 8?) clock ticks.
- so to do audio playback, the GBA "stripes" a chunk of data into RAM, sets a pointer to the beginning of that stripe, and then lets the audio chip pull data and update that pointer. When the pointer reaches the end of the stripe, an interrupt triggers that is supposed to pull in the next chunk of audio into the stripe (overwriting the current stripe contents) and reset the pointer.
... but if interrupts are disabled, then that doesn't happen, and the simpler logic in the audio chip just keeps incrementing the pointer forever and reading more data. It'll eventually get to the ROM addresses and pull directly from those (it's slow, but fast enough that it doesn't starve the chip; you just wouldn't run your audio this way in the game normally because you'd have 1/8th the amount of time to do everything else every frame of animation if the audio system were reading directly from ROM all the time. Also, reading from RAM lets you edit the samples to do audio effects).
02000000-0203FFFF EWRAM (256 KBytes)
03000000-03007FFF IWRAM (32 KBytes)
06000000-06017FFF VRAM - Video RAM (96 KBytes)
08000000-09FFFFFF Game Cartridge ROM (max 32MB)
Simply because it costs more to do those things, the GBA doesn't (Nintendo instead opting for the time-worn approach of the great game cart manufacturers of old, "if our games don't have bugs we don't have to worry about the behavior of the hardware in undefined state!"). So when a GBA game gets into some crash states (infinite loop with interrupts disabled, for example), the audio chip doesn't know the system is crashed and keeps doing its very simple job: reading sequential bits in RAM and converting them to sounds. Without the housekeeping that normally runs when the game is in good working order shepherding that read operation, it just keeps reading and eventually gets to the bits representing values in the cartridge ROM.
https://gbadev.net/gbadoc/interrupts.html
> It is possible to switch cartridges and have the routine resume execution on a completely different ROM.
That would have been a heck of a game mechanic back in the early 2000s! Maybe I never saw it because game developers were tired of the “please insert disk 2” of the Playstation era. But it feels like a gimmick a Metal Gear Solid game could have used.