> Some digital data streams, especially high-speed serial data streams (such as the raw stream of data from the magnetic head of a disk drive and serial communication networks such as Ethernet) are sent without an accompanying clock signal. The receiver generates a clock from an approximate frequency reference, and then phase-aligns the clock to the transitions in the data stream with a phase-locked loop (PLL).
> In order for this scheme to work, a data stream must transition frequently enough to correct for any drift in the PLL's oscillator. The limit for how long a clock-recovery unit can operate without a transition is known as its maximum consecutive identical digits (CID) specification.
Then we just moved to things like 64/66b which takes a giant chunk of bits, adds a short header to guarantee a clock transition, then runs everything through a pseudorandom scrambler.
Even if you have a perfectly synchronized clock, all-or-mostly-1's will be the same as all-or-mostly-0's in the long run.
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.
[1]: https://patdavid.net/2013/05/noise-removal-in-photos-with-me...
You have to counteract this by actually putting the noise back when you're done.
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.
My iPhone will regularly forgot what I was listening to moments ago after I press pause. Insane.
And yet my phone gets a bit chilly and gives up the ghost.
I use Bluetooth otherwise I'd have dug out the 3rd gen for the next ski day.
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?"
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.
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.
You can use the bx instruction to jump to any address stored in a register.
> Additionally, what would happen if one of TheZZAZZGlitch's incorrectly reconstructed ROMs was run on a real GameBoy?
It would crash, and eventually start playing the ROM on the speaker, the whole point of the video :)
I tip my hat sir. Reminded that I’m a mere mortal in the presence of greatness. The absurdity of recreating a game based on audio crashes sounds like something a mental patient would say but no, here we are in 2024.
Bootleggers will write per-game patches which flush the save contents to writeable flash depending on a small amount of reverse engineering work to discover where in the code the game saves. However, since all official GBA games always save data using functions from the Nintendo SDK, it's fairly straightforward to hook those functions and make a generic patch for any GBA game to save on a batteryless bootleg cartridge.
I have written a patcher to do this which you can find here. https://github.com/metroid-maniac/gba-auto-batteryless-patch...
The original NES had a sample generator that could do arbitrary waveforms and could be driven in two modes: one mode is you gave it a memory address and it'd start reading the bits in and treat them as an incredibly simple waveform (1 means 'go up one value', 0 means 'go down one value'... So to do a flat wave you'd do a run of 10101010etc.).
But you could also direct-drive the chip by continuously feeding it an "initial value" directly from the CPU, which was actually faster than the audio driver would read the bits from RAM itself... Problem is that doing so ate up all your CPU cycles, so you could only do it if you weren't doing anything else.
There were some games that took advantage of that: Battletoads had higher-fidelity drum-hits that they could play when action was paused, and they used it for the title screen, the extra-"crunchy" final hits on enemies (where all the action paused for a moment for dramatic effect), and the memorable pause music.
Here's a demo of the game switching between direct-drive and let-chip-read-samples mode to demonstrate (credit to Retro Game Audio for uploading the emulator-doctored video to show when the game is in the direct-drive subroutine). https://www.youtube.com/watch?v=JGT0FM3yh-w
