The issue with long runs of 0x00 is related to "clock recovery".<p>> 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).<p>> 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.<p><a href="https://en.wikipedia.org/wiki/Clock_recovery" rel="nofollow">https://en.wikipedia.org/wiki/Clock_recovery</a>
This reminds me of the original iPodLinux hack almost twenty years ago where the fourth-gen firmware was dumped via the piezo speaker - <a href="https://web.archive.org/web/20140810083116/http://www.newscientist.com/article/dn7085" rel="nofollow">https://web.archive.org/web/20140810083116/http://www.newsci...</a><p>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.
Glad to see this getting more attention here, it was posted a few days ago but drowned (<a href="https://news.ycombinator.com/item?id=39037104">https://news.ycombinator.com/item?id=39037104</a>). 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.
Zzazz (the subject of the article) runs a yearly April fools competition/event that usually involves some amount of retro hacking/reverse engineering. I recommend participating. Previous years competitions are on their GitHub
I've always found Nintendo's audio architectures to be fascinating.<p>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.).<p>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.<p>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.<p>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). <a href="https://www.youtube.com/watch?v=JGT0FM3yh-w" rel="nofollow">https://www.youtube.com/watch?v=JGT0FM3yh-w</a>
This is insanely impressive. I'm sure many of the techniques used like the "majority vote" algorithm cited are underutilized across many industries.
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.<p>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.
The most impressive part of all this is, IMHO, how the code was modified by the bootleggers to run the game off writable flash vs ROM plus volatile save memory haha.
Does anyone know what's going on when the TheZZAZZGlitch's emulator reports that the game tries to jump to an invalid address? I'm not so familiar with the ARM7 processor used in the GameBoy Advance, but I can't imagine how it would be possible to construct a jump call with an invalid value. Additionally, what would happen if one of TheZZAZZGlitch's incorrectly reconstructed ROMs was run on a real GameBoy?
This reminds me of an attempt made by RGMechEx to retrieve game code for an Atari game where the code itself was used to generate a visual effect similar to TV static on the screen [1].<p>[1] <a href="https://www.youtube.com/watch?v=5HSjJU562e8" rel="nofollow">https://www.youtube.com/watch?v=5HSjJU562e8</a>
The diffing of the real-world cartridge was the most interesting part. Requires a goofy amount of unnecessary knowledge to just jump in to reversing that and figuring out what its meaning is lol
That is extremely clever. The persistence alone is impressive but to get it to the point where it works well enough that you can actually extract the ROM contents with high fidelity is next level.
I've done this using GoldWave opening game files to extract their audio because I like the menu song or something, but nothing this sophisticated and cool.
It’s stories like these that remind me I’m stupid and have a lot still to learn. My goodness this is amazing. Up there with audio key logging and things I read about but could never dream would be a real thing.<p>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.