MicroPython is fast enough to make games.

System story

What this thing is

It is a small desktop console. A Fruit Jam board sits next to a 15-inch monitor and drives it directly over DVI. A gamepad breakout plugs into the STEMMA QT header and talks I2C, not USB. Power is a single USB-C cable. There is no case fan, no storage beyond onboard flash, and nothing between the game code and the hardware.

Games are written in MicroPython and copied onto the board as .py files. A launcher (menu.py) lists whatever is in /apps and starts the one you pick. Turning it on takes about a second.

Why it is worth documenting

The usual advice is that Python is too slow for real-time graphics on a microcontroller. That is true of Python written the usual way. It stops being true once allocation is pushed out of the main loop, hot pixel work is compiled rather than interpreted, and the frame is treated as a hard budget instead of a hope.

The current build backs that up at scale rather than in a single demo: thirteen arcade ports share one launcher and one DVI/audio driver stack, plus a fourteenth — a dual-core wireframe renderer in the style of Battlezone — still mid-build.

Architecture

How the system holds together

Six things have to happen every frame: read input, advance the world, clear the framebuffer, draw it, keep audio fed, and hand the finished frame to the display at the moment it is wanted. Each one is handled by a different part of the chip.

The shape of a game

Every game follows the same skeleton. Allocate everything up front — framebuffers, sprite tables, particle pools, sound buffers — then enter a loop that allocates nothing at all. Once the loop is running, the garbage collector has no reason to wake up, and frame times stop jittering.

# set up once, outside the loop
fb = bytearray(SCREEN_W * SCREEN_H * 2)
display = DVI_RP2_HSTX()
display.begin(fb, rv_colors.COLOR_MODE_BGR565, height=SCREEN_H, width=SCREEN_W, bytes_per_pixel=2)
gamepad = Gamepad()                                     # I2C breakout, not USB
spr = array('i', [0] * (MAX_SPRITES * 6))   # x, y, dx, dy, frame, flags
ctl = array('i', [0] * 8)                    # packed args for the asm blitter

while running:
    gamepad.read()                 # one I2C transaction, no allocation
    update(spr, gamepad)           # viper, no allocation
    display.wait_frame()           # spin on the frame-boundary flag
    fill_asm(fb, 0)                 # asm_thumb clear
    draw_sprites(fb, spr, ctl)     # asm_thumb inner loop
    mixer.service()                # tops up the I2S double buffer

Everything above the loop is allowed to be slow and readable. Everything inside it is not.

How the two cores split the frame

All 13 games (plus the in-progress Battlezone) start core 1 with _thread.start_new_thread(core1, ()) and run their own loop as core 0. But what each core does splits three distinct ways, not one.

Read directly from each game's core0()/core1() functions. Scramble is the one outlier: its core0 draw step and its core1 copy step each independently call display.wait_frame() — the two aren't coordinated, which method 2's other three titles avoid.

Games

What runs on it

Mostly arcade remakes, because arcade games are honest tests: fixed frame rate, many moving objects, and an audience that notices a dropped frame immediately.

Thirteen titles, one per launcher slot — each name above links to its source. Two more sit on the flash outside that rotation: a voxel-landscape flyover is on the board but has no menu slot pointing at it, and a dual-core wireframe renderer in the style of Battlezone is mid-build — main.py refuses to launch it until its top-level script is wrapped in a proper main().

Gravitar and Star Castle are two-stage — the links above go straight to the real game, in apps/Gravitar/ and apps/Starcastle/. What's actually in /apps on the launcher (gravitar_boot.py, starcastle_boot.py) is a thin loader that sets up the framebuffer first, then imports the module linked here.

Deep dive

Where the time actually goes

Three tiers of code do the work, and knowing which tier a function belongs in is most of the performance story.

Rules that came out of the measurements

• The main loop allocates nothing. Pre-allocate flat array objects and index into them; do not build tuples or lists per frame.
• Pass one packed int32 control array into an assembly primitive rather than several arguments — argument marshalling costs more than the work in short calls.
• Clip once against the screen bounds before entering the loops, then run unsigned-only coordinates inside.
• Write two pixels at a time with a 32-bit str, using strh only for an odd leading or trailing pixel.
• Wait on the video DMA's frame flag before clearing, so the clear never overtakes scan-out and tears.
• Keep the framebuffer in SRAM if it fits. PSRAM works, but the write cost shows up in every fill.

How much of each game is native code

No per-stage timing has been logged yet — time.ticks_us() instrumentation hasn't been added. What's countable today is how much of each game's own code has already been pushed down a tier, by function count.

Counted directly from each game's source (grep -c '@micropython.viper' / '@micropython.asm_thumb'). Defender carries the most Viper functions of any title — its scrolling terrain and enemy-wave logic is almost entirely off the interpreter.

Video, in more detail

The HSTX peripheral pulls pixel data from three chained DMA channels rather than a single ping-pong pair. A dispatcher channel feeds four-register control blocks into a 16-byte ring buffer that continuously re-arms an executer channel; the executer alternates between sending HSTX timing commands and a row of framebuffer pixels to the HSTX FIFO, chaining back to the dispatcher after each. (A third streamer channel exists for framebuffers that live in PSRAM, pulling one scanline at a time through the XIP interface — none of this build's games use it.) Once a frame's worth of control blocks has been consumed, a nested "restart frame" block re-triggers the dispatcher and fires a hard IRQ that sets a one-word frame-boundary flag. Games never touch DMA registers directly; they just call display.wait_frame(), which spins on that flag.

Video timing is fixed at 640×480 (16/96/48 front-porch/sync/back-porch horizontally, 10/2/33 vertically — standard 640×480 timing, ~60 Hz) — the driver only supports that one mode. Games with a smaller framebuffer, like the 320×240 titles, don't get their own timing; the driver pixel- and line-doubles their buffer up to fill the full 640×480 output.

Audio, in more detail

Sound goes out over I2S to a TLV320DAC3100 codec. The mixer allocates two interleaved stereo buffers up front — BUF_A and BUF_B, each chunk × 4 bytes (256-sample chunks × 2 channels × 16-bit samples = 1,024 bytes) — and alternates between them. Up to 8 voices can play at once; each is a plain PCM bytearray with its own position, volume and loop flag. Refilling a buffer is one Viper method, _fill_into(), that walks every active voice, sums into an accumulator, clamps, and duplicates the result into both stereo channels — a single native pass with no per-voice Python calls and no allocation, safe to run from the I2S write-complete IRQ. Default sample rate is 22,050 Hz; the codec itself supports 8,000–192,000 Hz.

Mixer.load() decodes a whole .wav into a PCM bytearray up front, not streamed — and these add up. Arkanoid alone carries roughly 745 KB across its sound set (its xlife.wav and warp.wav are each over 80 KB), well past what fits in an RP2350's internal SRAM alongside a framebuffer and game state. In practice that means sound data is usually the thing that ends up pushed out into the board's 8 MB of PSRAM. That's not a playback problem, unlike the framebuffer case above: at 8 voices × 22,050 Hz × 16-bit, the mixer's worst-case read rate is around 350 KB/s, under 1% of PSRAM's roughly 37.5 MB/s throughput — and those reads are sequential and paced by the I2S DMA, not the 16.67 ms frame clock, so PSRAM's higher per-access latency never has anywhere to show up.

Build guide

Making one

The parts list is short and nothing needs to be soldered.

Index

Files and references

Everything on the console, and what it is for.

Further reading

• RP2350 datasheet — HSTX chapter
• MicroPython speed guide — Viper and the inline Thumb-2 assembler
• Adafruit Fruit Jam product page and learning-system pinout guide