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.
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.
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
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.
Interesting. I’m check those out, thanks!
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 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.