For some reason, when a GBA game crashes, the GBA will output the content of the game cartridge as audio over the headphone jack. This person noticed it and created a script that can re-create the ROM file (content of the cartridge) from the audio that the GBA outputs.
Sending data over audio was how dial up Internet worked. My guess here is that the audio playing hardware loses the ability to come to a stopping point at the end of the audio file after a crash and starts playing the data in the memory after the audio file ends as if it were audio.
The guy who uploaded the video that corporate content farm is “reporting” on actually covers exactly why this happens. In short, the gba plays sound from a certain part of ram, which a cpu interrupt continously refreshes. In the event of a crash, it keeps playing sound, but doesn’t get the interrupt to keep it playing the proper data from ram. If you let it cycle through all of ram, it eventually leaks out and just starts playing, well, everything else, eventually getting to the game rom.
RelevantVideos
A signal is a signal. For system hardware developers it might have been a quick and dirty way to debug the hardware. It could also be an abandoned feature for low level developers and cartridge development teams. We may never know the real answer but it’s not an unreasonable thing to use the thing designed to output waves as a quick hookup point for logic analyzers / oscilloscopes.
I had a major brain fart and forgot you can connect audio over a cable too. Yeah, now that I’m thinking about it more it wasn’t that uncommon to transfer data over aux back in the day. I was imagining using a microphone which would have been silly.
If I had to guess possible reasons off the top of my head:
1: the aux cable and port are a very common for factor for electronics of all sorts, especially computers. So you could probably transfer that data to non-Gameboy devices and not have to manufacturer more proprietary GB ports which you may also have to write drivers for on your non-GB hardware. And your customers would also go through the hustle, if you require them to use your proprietary debugging hardware and drivers, when they inevitably test and debug their own games for your console.
2: in the event of a crash, the kernel might better be able to handle the aux than the proprietary port. Pure speculation by me.
Regardless of any possible reasons or strangeness, it just seems much more probable to me that the behavior of dumping the rom over the audio port is a design choice rather than a coincidence.
Could be that their audio playback is done by hardware reading from a low address buffer in parallel to the rest of the logic and just relies on that logic to update pointers otherwise it will run through the entire address space.
Or it could be their way of implementing a full address space dump on a crash without large amounts of storage available and that just includes the ROM because it’s a part of that address space. But in the video, they were able to get a 100% match for the ROM using an emulator, so this isn’t it unless they didn’t mention chopping off a RAM section.
I assume the game was playing an audio sample while it crashed, and the hardware never stopped playing, meaning it just kept playing through the entire address space.
I’m more confused than anything. What?
For some reason, when a GBA game crashes, the GBA will output the content of the game cartridge as audio over the headphone jack. This person noticed it and created a script that can re-create the ROM file (content of the cartridge) from the audio that the GBA outputs.
When I read shit like this I realize I don’t know a damn thing about computers
Sending data over audio was how dial up Internet worked. My guess here is that the audio playing hardware loses the ability to come to a stopping point at the end of the audio file after a crash and starts playing the data in the memory after the audio file ends as if it were audio.
It might also be a debugging behavior built into the device
That’s my guess as well.
The guy who uploaded the video that corporate content farm is “reporting” on actually covers exactly why this happens. In short, the gba plays sound from a certain part of ram, which a cpu interrupt continously refreshes. In the event of a crash, it keeps playing sound, but doesn’t get the interrupt to keep it playing the proper data from ram. If you let it cycle through all of ram, it eventually leaks out and just starts playing, well, everything else, eventually getting to the game rom. Relevant Videos
Interesting. I’m check those out, thanks!
Here is an alternative Piped link(s):
Relevant
Videos
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.
Why would you debug over audio when you can use a cable?
A signal is a signal. For system hardware developers it might have been a quick and dirty way to debug the hardware. It could also be an abandoned feature for low level developers and cartridge development teams. We may never know the real answer but it’s not an unreasonable thing to use the thing designed to output waves as a quick hookup point for logic analyzers / oscilloscopes.
I had a major brain fart and forgot you can connect audio over a cable too. Yeah, now that I’m thinking about it more it wasn’t that uncommon to transfer data over aux back in the day. I was imagining using a microphone which would have been silly.
I really don’t know.
If I had to guess possible reasons off the top of my head:
1: the aux cable and port are a very common for factor for electronics of all sorts, especially computers. So you could probably transfer that data to non-Gameboy devices and not have to manufacturer more proprietary GB ports which you may also have to write drivers for on your non-GB hardware. And your customers would also go through the hustle, if you require them to use your proprietary debugging hardware and drivers, when they inevitably test and debug their own games for your console.
2: in the event of a crash, the kernel might better be able to handle the aux than the proprietary port. Pure speculation by me.
Regardless of any possible reasons or strangeness, it just seems much more probable to me that the behavior of dumping the rom over the audio port is a design choice rather than a coincidence.
Program code for a Gameboy game wouldn’t normally be sent through an audio port so this is pretty weird.
Could be that their audio playback is done by hardware reading from a low address buffer in parallel to the rest of the logic and just relies on that logic to update pointers otherwise it will run through the entire address space.
Or it could be their way of implementing a full address space dump on a crash without large amounts of storage available and that just includes the ROM because it’s a part of that address space. But in the video, they were able to get a 100% match for the ROM using an emulator, so this isn’t it unless they didn’t mention chopping off a RAM section.
So he more or less brought a game back to life from it’s death rattle?
That’s fuckin badass.
I assume the game was playing an audio sample while it crashed, and the hardware never stopped playing, meaning it just kept playing through the entire address space.