The Uzebox is a minimalistic open source hardware game console which at it’s simplest incarnation consist of a few discrete components and a single ATmega644 micro-controller chip (SCART version). For NTSC output an additional AD723 video encoder is needed which still makes it only two ICs for a working game console.
Since there is no graphic chip, no video controller, and no timer-driven DMA on the ATmega644 the CPU has to constantly generate the video signal in real time. Not that this is an issue, just a bit of an extra challenge ( One that I was already familiar with ).
Both the Arduboy and Uzebox uses an ATmega CPU which meant I didn’t have to rewrite the few assembly routines and compared to the Arduboy the Uzebox is a beast:
That is until you take into account it has no video circuitry:
|RAM (including display)||3.5KB||4KB|
|Approximate equivalent speed after|
cost of display refresh/update
|~14.6Mhz||~5.86Mhz (for 224 lines)|
Cutting the CPU some slack
The Arduboy has a 128×64 OLED display and since I need 2 video buffers (one to render, one to display) there isn’t enough memory anyway to increase the rendering resolution.
So I created 3 video modes:
The very slow doubled lines (128 lines total):
The default “fullscreen” without the line doubling:
And a tiny green mode that gives an extra 2 to 4 fps:
This last one isn’t in black & white as duplicating a bit to an entire register takes more cycles.
The memory format is also different requiring a copy routine rather than a pointer swap but as the drawing load becomes higher the display CPU savings start to really pay off.
The good news is I got a whole extra 512 bytes of RAM and lots of ROM space to implement the vertex cache I couldn’t on Arduboy due to space constraints. I just need 192+2 bytes (12 bytes * 16 vertices + 16 “valid” bits)
A Tight Fit
The blue space on the right represent the space between the top of the variables and the stack. Each square is a byte. That’s a little less than 64 bytes of RAM left.
Things have kept happening over the last 3 years, including moving to a new house, and finally I found enough time to polish and release the Uzebox port.
That was quite the long back-burner project delay.
It gave me the chance to improve performance on the tiny video mode and make it black-and-white.
The game runs identically with some last minute cosmetic changes the dithering to avoid NTSC chroma carrier clashes and judging by the emulator’s RAM display with that change I am now under 16 bytes of RAM free.
Starduino™ © 2019-2022 Stephane Hockenhull
All rights reserved.
Not for redistribution or commercial use, including but not limited to installation on devices by sellers, resellers, and manufacturers. Contact for licensing.