Starduino for Uzebox

Download Starduino for Uzebox (zip file) (uze file)

Shortly after releasing Starduino on Arduboy, Andrew (AKA CunningFellow) offered me one of his Uzebox DTV units (Big thanks).

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 ).

Performance

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:

OUCH!

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.

Memory

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)

Audio

But I don’t have any extra RAM! I need 262 bytes for the audio buffer and I need two of them to double-buffer it all.

On Arduboy I calculated every audio sample on the fly in the interrupt routine to save on RAM but on Uzebox the CPU is already very busy, too busy to afford .

I had to cut the buffer in half and recalculate the audio mid-frame using recursive interrupts so the display could keep updating. The cost of recursive interrupts on the stack was less than the 262 bytes saved, an overall gain.

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.

2022 Release

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.

Enjoy.

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.