Series: An Arduous Endeavor

I recently picked up a low-powered handheld gaming device which has gotten me excited about playing retro games again. Part of the fun of such devices (for me, anyway) is tweaking them and getting them set up just right, and doing that has involved exploring the various discords related to handheld gaming. Which led me to discovering a new-ish handheld system that I hadn’t heard of before: the Arduboy.

There are a variety of components that need to be emulated to fully emulate the Arduboy. I decided to start with the display, since without that I wouldn’t be able to see much of anything.

Next up was to emulate the CPU: an ATmega32U4 for standard Arduboy units. I started to implement this in a similar fashion to how I implemented the display because “It’s an 8-bit RISC processor, how hard can it be?” And then I saw how many opcodes there were – or rather, how many opcodes there might be, because it’s not totally clear what differentiates one opcode from the other – and I decided that maybe I should rely on someone else’s work for this part.

Then I discovered there were a number of AVR emulators, written with some degree of intended integration into other projects. simavr seemed the most promising for my intended use – I just had to figure out how to integrate it. So I figured it was time to learn a little bit more about CMake.

Playing games usually requires pressing buttons. I thought this part would take longer, but it turned out to be almost too simple.

Sound generation is probably the aspect of emulation that I am least familiar with. As part of my undergrad, I wrote simulators of simple computer architectures and interacted directly with framebuffers to display 2D graphics. But when it came to sound stuff, my experience was strictly at a high level, buffering WAV/MP3 files and relying on some mixing libraries written by others.

Sound emulation in Libretro, though, appears to require passing through integers at the “sample” level. In other words, the raw amplitude values for whatever sample rate we’re running the emulator at.

Two emulator features that have made my gaming experience much more comfortable are save states and rewind functionality. Save states let you take a snapshot of a game at any point in time, and then come back to it – whether that is after attempting and failing to complete some task, or maybe after leaving the game for a bit to take care of things in real life. Rewind takes that feature to the extreme, essentially performing a snapshot after every video frame, making it very convenient to “undo” a misstep or bad random number generator without even having to plan for it.

Libretro enables both of these features via the retro_serialize and retro_deserialize functions. Once you have these functions implemented, a Libretro frontend is capable of saving/loading any number of save files.