Author here. This is actually a fairly old project of mine by now, but I just recently submitted it to Hackaday, which is probably why it's surfaced here.
The original video demo has been taken down by the author (not me) due to some concerns of his, but he is reportedly planning to reshoot it soon.
That's correct. I realize my parent comment was ambiguous. I'm the author of the port; the video is by a different developer who's since taken it down.
> "7325 is prime whenever taken modulo a power of two. This somehow (I’m actually not sure exactly how) leads to the sound mixing code being passed a one-sample array, triggering the corner case and freeze.
Resolving that bug took quite a bit of serendipity. The break came when I was on the verge of giving up on the assembly rewrite and reverting back to C. I'd left my "frozen" iPod sitting around for a while. ~15 minutes later, I came back, and everything was back to normal -- this was evidence that I was not seeing a true lockup, but rather an extremely long delay (consistent with an integer wraparound).
There are virtually no good ways to debug code on-device with Rockbox, short of adding in a bunch of function calls to print variable values to the device's screen. This usual method, though slow, works surprisingly well with most bugs -- but this assumes that the code is in a sane enough state to be able to write to the screen properly (stack corruption, for example, would render it unusable).
There were a few bugs which were not debuggable with this "trace all the things" method, and those were the ones which required the most ingenuity. I remember having to root out a few bugs which absolutely trashed the processor state and made complex things (like function calls to print things) fail miserably.
One such class of bug was the unaligned read (this is ARM, remember). Thankfully, ARM has a way to set an "alignment trap" to trigger an interrupt when an invalid unaligned read happens. The only problem was that, of course, I couldn't figure out what code was responsible for the unaligned read.
My solution to this was quite the gem -- I modified the ARM exception handler to use the iPod's internal piezo buzzer to beep out the faulting PC address in a sequence of 32 high/low pitched beeps. The piezo, driven by a single memory-mapped register, could be controlled with minimal code (and most importantly, no function calls).
Thanks for your added comments, Im intruiqued! If you ever do a screencast of anything like this, make sure you post it on HN - I'd be super interested in following along for a few hours of ARM debugging :)
Oh hell yeah. I ran Rockbox on my Sansa Fuze from the ages of 14-18 because my parents restricted my computer time. There were tons of games on that thing. I spent hundreds of hours playing Doom and Gameboy/Gameboy Color games on road trips and in my bedroom. So much so that I ground down the middle button with my thumb to the point where it stopped working... did I mention how hard it is to play Doom on a 2.5 inch screen?
Rockbox is a really, really cool project, and it's unfortunate that the age of MP3 players is basically over. I guess the spirit sort of lives on in the Android ecosystem but there was something so incredible about getting half of the functionality on a device a tenth as powerful.
> I guess the spirit sort of lives on in the Android ecosystem but there was something so incredible about getting half of the functionality on a device a tenth as powerful.
I feel like the true successor to that ecosystem is the Chinese "emulation portables" market. I have a BittBoy (PocketGo), and it's a perfect "hobbyist homebrew" platform; it's got a nice screen, takes SDXC cards, and has "enough" RAM to have a pixel-addressable framebuffer; but otherwise it's just slightly more powerful than a Nintendo DS, and that "enough" RAM is still only 32MB (and it's probably taking up some of that memory running Linux, unless you've compiled your own unikernel for it.) So it's not like you can get away with un-optimized code.
I feel like those are an evolution of devices like the GP2X. Interestingly, by virtue of being vastly more "hacker-friendly" than iPods, many things that are _really_ cool (like a Quake port) feel kind of mundane on those.
I think what lwb means is how cool it is to get something running on a device you're technically not supposed to do that to.
I love when people port software onto hardware you wouldn't expect. Takes a certain kind of mind to approach it and maintain the motivation to stick through it. Great writeup.
I really enjoyed that little diversion too, wonderful project. Just enough detail in the article that you get a nice little taste of the complexity without getting lost in the detail. Bravo all round.
I wonder why he switched it to private. Is there fear from Apple, or other device manufacturers for side-loading software? You’d think they wouldn’t really care for a discontinued product.
The iPod Video and lower had some pretty incredible tools and firmwares available looking back. I was part of the iPod Wizard team (mostly helped with mapping hex locations on new firmware releases and created a handful of themes, including backporting the color themes to the 4-tone generations) and contributed a bit to the iPodLinux project. At one point, I had a bootloader that let me switch between the normal firmware, Rockbox, iPodLinux, and iPod Wiki (all of Wikipedia viewable offline on your iPod) available just be restarting my iPod. It was a dumb smart phone half a decade before the iPhone.
The devs on those teams really pushed that little MP3 player to do things it was never intended to do.
The original video demo has been taken down by the author (not me) due to some concerns of his, but he is reportedly planning to reshoot it soon.
In the meantime, though, a Duke3D demo (running on the same software stack) is available here: https://www.youtube.com/watch?v=OV8etSGH86M
EDIT: I've gotten a quick recording up: https://www.youtube.com/watch?v=r6V-4AZ7pkA (apologies for the mirrored video)