11–20 of 89 posts
Glad to see this getting more attention here, it was posted a few days ago but drowned ( https://news.ycombinator.com/item?id=39037104 ). The original video has a lot not mentioned in this brief article, including a custom adapter that the hacker had to cut together manually to get the right audio quality out of the DS.
I imagine the 0xFF might be converted to 0x00 due to DC blocking capacitors/high-pass filtering, audio circuits aren't really suited for non-audible content. He might get better capture accuracy with a digital oscilloscope hooked directly at the chip's audio outputs if he's lucky, but it's still pretty impressive he got a bootable image out of that.
Yeah, you want to generate a signal with no DC bias, something as simple as Manchester encoding will go a long way. If that's not good enough, there's NRZ or even a convolutional encoding. You also want to make sure you either send a sin wave, or if you can't do that, at least make sure your square wave frequency is high enough that it doesn't get eaten by the AC coupling capacitors.
Coincidentally one of the things this facilitated was playing GBA games on the iPod, though I was happy enough just to play Doom a with the click wheel and watch monochrome videos.
I imagine the 0xFF might be converted to 0x00 due to DC blocking capacitors/high-pass filtering, audio circuits aren't really suited for non-audible content. He might get better capture accuracy with a digital oscilloscope hooked directly at the chip's audio outputs if he's lucky, but it's still pretty impressive he got a bootable image out of that.
> I imagine the 0xFF might be converted to 0x00 due to DC blocking capacitors/high-pass filtering, audio circuits aren't really suited for non-audible content. Yeah, you want to generate a signal with no DC bias, something as simple as Manchester encoding will go a long way. If that's not good enough, there's NRZ or even a convolutional encoding. You also want to make sure you either send a sin wave, or if you can't…
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.
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?
The author's previous video[1] explains the technical details regarding this behavior. 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 rea…
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?"
Earlier quoted context omitted.
The author's previous video[1] explains the technical details regarding this behavior. 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 rea…
Would this be dependent on the audio file that was being played during the crash to start at address 0 of the ROM? It seems like it'd be highly unlikely you'd be able to get 100% of the ROM. 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?"
Earlier quoted context omitted.
The author's previous video[1] explains the technical details regarding this behavior. 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 rea…
Would this be dependent on the audio file that was being played during the crash to start at address 0 of the ROM? It seems like it'd be highly unlikely you'd be able to get 100% of the ROM. 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?"
This is insanely impressive. I'm sure many of the techniques used like the "majority vote" algorithm cited are underutilized across many industries.
Magnetic storage media operates on the principal of this hack at baseline! https://en.wikipedia.org/wiki/Partial-response_maximum-likel...
The same idea can apply here as GBA ROM material would be highly biased. Majority vote wastes a lot of information.