schmelczer-dev/src/content/work/ad-astra-attiny85-game-engine.md

title	description	date	period	thumbnail	links	article	project
A 50 FPS Game Engine on an 8-Bit Microcontroller	A handheld game built from the PCB up: ATtiny85V, OLED, IR receiver, EEPROM, 8 MHz 8-bit ALU. 50 FPS floor.	2026-05-06	Spring 2020	src alt ./_assets/ad-astra.jpg The Ad Astra game running on a small OLED display.	label url Source https://github.com/schmelczer/ad_astra	tags role stack scale outcome audience media embedded games systems Hardware and firmware author C ATtiny85V SPI OLED IR receiver EEPROM KiCad 8 MHz, 8-bit ALU, ~31 mW at full brightness, ~1.5 mA standby, 15–20 ms frame budget A handheld built from schematic to firmware, with a 50 FPS game on it technical type poster webm mp4 captions alt caption transcript video ./_assets/ad-astra.jpg /media/video/ad_astra.webm /media/video/ad_astra.mp4 /media/video/ad_astra.vtt Video demonstration of the embedded game running on a small OLED display. The whole thing, from board and firmware to sprites and game loop, runs on a single ATtiny85V at 8 MHz. No spoken dialogue. The handheld board runs its OLED game; the player moves through the small display while the IR input controls gameplay.	title description selected technologies thumbnail Ad Astra A handheld game built from a custom PCB up: ATtiny85V, OLED, IR, EEPROM. 8-bit ALU at 8 MHz, 50 FPS floor. true C ATtiny85V OLED EEPROM PCB design alt The Ad Astra handheld game running on its OLED display.

I'd done microcontroller work on dev boards before and it always felt like I was renting the hardware. As soon as I had a real board with my own soldering on it, bugs stopped feeling like software inconveniences and started feeling like consequences of choices I'd made in KiCad. That shift was most of the value of doing it this way. Four years on from my first hardware project, the lesson was that owning the whole stack down to the copper changes how you debug.

This one is a handheld game built from the PCB up around an ATtiny85V: 8-bit ALU at 8 MHz, no FPU, no SIMD, 8 KB of flash. Anything I built had to fit inside that, or I'd be staring at a brick.

The bits worth showing

• SIMD-on-an-8-bit-ALU display driver. The OLED is 128×64 monochrome, 1024 bytes per frame. The driver packs four pixels into a byte and processes them with bit-parallel tricks. That's how the frame budget stayed under 20 ms with room for game logic.
• Prototype-based inheritance, in C. Entities share behaviour by pointing at a struct of function pointers. No vtable, no class, no allocator. Cheap dispatch and the whole object model fits on one screen.
• Atomic EEPROM commits. Sprite data and save state both live in EEPROM. The commit path writes a new region, then swaps a tiny header pointer. Pull the battery mid-write and the previous version is intact.
• PNG-to-C sprite pipeline. A Python script turns PNG artwork into static C arrays the firmware can include directly. Asset workflow without ever leaving the source tree.

What I'd change

• A host-side emulator. Debugging firmware directly on hardware was character-building and slow. A small SDL-based simulator linking the same C code would have shortened the iteration loop from "reflash and hope" to "rebuild and run."
• Power numbers I'd actually trust. I have peak and standby draw. I don't have a curve over a real gameplay session, so I honestly can't say how long the battery lasts under load. I can only say it outlasted my patience.
• A development log for the driver. The display driver and the EEPROM commit protocol are the parts I'd still defend. They deserved diagrams and measurements at the time, not the half page of comments I left them with.