Corne Arcane OLED

At a glance

• Outcome — A deterministic spell-duel mini-game runs on the OLEDs of a Corne split keyboard, inside real firmware constraints: no allocation, fixed flash/RAM budgets, and a versioned wire protocol between halves.
• Status — Accepted on physical hardware, v0.4.
• Role — Solo. I own the design, constraints, acceptance gates, physical diagnostics, and validation; implementation is AI-assisted and reviewed.
• Stack — C11 project-owned simulation and protocol code, on top of separately pinned QMK/Vial firmware; host-side tooling for testing.
• Source — Private until licensing and QMK/Vial attribution are resolved.
• What works today — The deterministic, allocation-free simulation; fixed, versioned CRC-checked protocols; host tooling; and the v0.4 firmware running on the physical keyboard.
• Validation — Sanitizer-backed native tests, exact-frame golden framebuffer checks, no-allocation checks, flash/RAM budget gates, CI, and acceptance on the physical device with rollback artifacts kept.
• Limitations — Visual/demo material is thin so far, and the code is C, not C++ — it’s constrained-systems proof, not gameplay-engine proof.

Overview

The Corne is a split keyboard with two small OLED screens and an RP2040 in each half. Corne Arcane turns those screens into a spell-duel simulation that runs inside the leftover headroom of working keyboard firmware — which is the actual point of the project. The game is small; the constraints are not.

Everything project-owned is C11, kept strictly separate from the pinned QMK/Vial dependencies it builds against. The simulation is deterministic and allocation-free, the two halves talk over fixed, versioned, CRC-checked protocols, and every change has to fit the flash and RAM budgets before it’s allowed near the hardware.

How it’s validated

This project is where I hold the strictest engineering discipline, because a bad flash is a physical inconvenience, not a stack trace:

• Native first. The simulation runs on the host under sanitizers, with exact-frame golden framebuffer tests, so logic bugs die before firmware builds.
• Budgets as gates. No-allocation checks and flash/RAM budget checks run in CI; exceeding them fails the build.
• Hardware acceptance. A release is only “done” when it’s been flashed and exercised on the physical keyboard, with the previous known-good firmware kept as a rollback artifact. v0.4 is the current accepted release.

Limitations

There’s little to watch yet — screenshots and a short video of the duel running on-device are the obvious missing artifact. The repository stays private until the licensing and attribution story around the QMK/Vial dependencies is resolved properly.