[HN Gopher] Modder re-creates Game Boy Advance games using the a...
___________________________________________________________________
Modder re-creates Game Boy Advance games using the audio from crash
sounds
Author : dagenix
Score : 264 points
Date : 2024-01-22 17:39 UTC (5 hours ago)
(HTM) web link (arstechnica.com)
(TXT) w3m dump (arstechnica.com)
| 2024throwaway wrote:
| This is insanely impressive. I'm sure many of the techniques used
| like the "majority vote" algorithm cited are underutilized across
| many industries.
| epcoa wrote:
| If one is interested there is nearly 100 years now of
| sophisticated noisy signal recovery techniques.
|
| 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.
| mikepurvis wrote:
| I wondered about it for film scanning, specifically with a fan
| project like 4K77 where they're dealing with potentially
| damaged theatre prints rather than pristine masters-- having
| multiple of them and being able to use that to eliminate
| scratches and so on would potentially save a ton of time on
| manual fixing in post.
| guyomes wrote:
| One interesting application of taking the value appearing in
| majority, or more generally taking the median, is to remove
| noise or people from a sequence of several photos taken from
| the same point of view. This idea is to superimpose all the
| photos, and for each pixel, you simply keep the median [1].
|
| [1]: https://patdavid.net/2013/05/noise-removal-in-photos-with-
| me...
| brokensegue wrote:
| 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
| reactordev wrote:
| 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.
|
| 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.
| da768 wrote:
| 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.
| Frenchgeek wrote:
| From what I remember reading in the comments of his youtube
| video, the point of the exercise was to do it with as basic
| equipment as possible.Hence the hours of multiples passes to
| average the error out instead of a proper data-logging
| oscilloscope.
| arcticbull wrote:
| > 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 do that, at least make sure your square wave
| frequency is high enough that it doesn't get eaten by the AC
| coupling capacitors.
| freeqaz wrote:
| Would it be possible to get a higher quality read from using
| something like an Arduino's I/O pins and some bit-banged C
| code? I'd be curious to see what would be possible using
| cheap, off-the-shelf tools since a lot of people don't
| necessarily have an oscilloscope laying around. :P
| fodkodrasz wrote:
| Without looking up datasheets, just form the top of my
| head: the Arduino DAC most likely has 12 bits resolution
| (as common for cheap uCs), and maybe even slower sampling
| than a soundcard. A sound card was probably better than
| that even in the 1990s (say a Sound Blaster).
| aidenn0 wrote:
| The original Sound Blaster could only record at 8-bit
| resolution at up to 12 kHz. The 2.0 could record at up to
| 15kHz, still 8-bit.
|
| The second generation of Sound Blaster was the first that
| could record at 44kHz (mono) sampling rate, but was still
| only 8-bits of resolution.
|
| It wasn't until the 3rd generation Sound Blaster 16 that
| 16-bit audio could be recorded.
| fodkodrasz wrote:
| Hmm, I had (false) memories of better capabilities.
| Though my first soundcard was an SB Pro clone, later an
| SB16, both almost capable :)
| skeaker wrote:
| 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.
| taftster wrote:
| Link to "original video":
|
| https://www.youtube.com/watch?v=0-7PSmYYHF0
| hifikuno wrote:
| The video was great. I think my favourite part is where he
| dumps the Chinese knock off version and finds the random ARM
| code and reverse engineers it. So much cool stuff in there.
| taftster wrote:
| Right? This kind of stuff just makes me look silly in what
| I'm able to achieve. I can only accomplish watching a video
| of some guy doing bad ass stuff and maybe holding onto a
| few notional details. People are just super smart
| sometimes.
| peddling-brink wrote:
| 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?
| 0xC0ncord wrote:
| 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 read other parts of memory.
|
| [1] https://www.youtube.com/watch?v=wSWNkpqjtQY&t=361s
| jboy55 wrote:
| 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?"
| ordu wrote:
| I think hardware starts from 0 after reaching 0xfff..ffff
| address. The article mentions that you need to wait before
| starting to record, I assume it is a pause needed for
| hardware to overflow address.
| lelandbatey wrote:
| That video seems to imply that the audio hardware
| automatically wraps back to address 0 when it reaches the
| end of RAM. That may not be true, but it's implied by the
| animation in that video. And since they were apparently
| able to dump the entire ROM via audio, I suppose there's
| _some_ way to get the entire memory contents.
| shadowgovt wrote:
| The ROM on the GBA is mapped into memory at high memory
| addresses (0x08000000 and above). The audio "working"
| buffer is in low memory (I think somewhere near
| 0x02000000?). An interrupt fires when the audio chip reads
| to the end of the working buffer that looks something like
| this:
|
| - run the function to fetch the next batch of audio to
| audio working RAM
|
| - reset the audio read pointer to the beginning of audio
| working RAM
|
| When interrupts are disabled (because the game has
| crashed), that "reset pointer" code never runs and the
| audio circuit keeps reading way past the end of its buffer,
| incrementing forever. Eventually it would increment into
| the 0x08000000 range in which case the sounds it's emitting
| map directly to the bits in the ROM.
| shadowgovt wrote:
| It's pretty uncommon and it's not a deliberate debugging tool.
| In this case, the GBA could, hypothetically, have had a way to
| "park" the architecture on a game crash, or "watchdog" the
| system (by tying state update somewhere that should run
| periodically to a non-maskable interrupt that reboots the
| machine if that state update stops happening).
|
| 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.
| thewakalix wrote:
| The issue with long runs of 0x00 is related to "clock recovery".
|
| > 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.
|
| https://en.wikipedia.org/wiki/Clock_recovery
| akira2501 wrote:
| I love how we used to use a bunch of very clever "code book"
| systems like 8b/10b which did a lot of careful work with small
| runs of bits to ensure the clock was recoverable and to avoid
| line capacitance issues.
|
| 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.
| dwattttt wrote:
| A sprinkle of entropy improves everything
| Y_Y wrote:
| This reminds me of the original iPodLinux hack almost twenty
| years ago where the fourth-gen firmware was dumped via the piezo
| speaker -
| https://web.archive.org/web/20140810083116/http://www.newsci...
|
| 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.
| nathancahill wrote:
| Good memories. I still have my iPod Classic, I upgraded the
| battery and added 4 256GB MicroSD cards. I saw a mod recently
| for adding Bluetooth but it involves swapping the rear case and
| I don't think I'll go that far. There's something timeless
| about the design (and about owning copies of music files).
| Solvency wrote:
| I feel like this article is so painfully and poorly written it
| obfuscates exactly what's going on here when it could be so much
| clearer.
| seabass-labrax wrote:
| 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?
| cosarara wrote:
| > I can't imagine how it would be possible to construct a jump
| call with an invalid value
|
| 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 :)
___________________________________________________________________
(page generated 2024-01-22 23:00 UTC)