GBoost: Game Boy Overclocking Firmware Workbench

A Game Boy overclock module with a browser workbench for developing and testing its firmware.

Comment

Inspiration

Retro gaming is fun, but my time is limited. I wanted to play on original hardware, just a bit faster. Existing overclock mods typically support only fixed speeds, even though each Game Boy and display combination can tolerate a different maximum speed.

That inspired me to develop GBoost: a tiny programmable replacement for the original oscillator in classic Game Boy consoles. It lets players speed games up, slow them down, and calibrate the maximum stable overclock speed for their individual console.

What began as a small hardware idea eventually became a complete hardware-to-web project.

How I built it

GBoost is a compact module installed inside a Game Boy. It uses three existing console buttons and visual feedback to control overclocking, underclocking, calibration, persistent settings, recovery behavior, and power-aware operation.

The project is split across several specialized repositories:

  • Hardware: KiCad designs for multiple iterations of the module.
  • Firmware: Resource-conscious embedded C++ for the MCU, including target builds, host tests, self-tests, and size tracking.
  • Programmer/tester: A Raspberry Pi fixture and Python software for programming modules, exercising controls, checking outputs, and reporting results.
  • Documentation: A public MkDocs Material wiki covering installation, operation, calibration, compatibility, recovery, and troubleshooting.
  • Product site: A self-contained Hugo shop and waitlist experience for GBoost RGB.
  • Management: A Markdown-first repository connecting plans, risks, validation evidence, alpha readiness, and public claims across the other repositories.

For Build Week, I focused on one of the project’s hardest recurring problems: the firmware-development loop. Testing normally meant editing C++, compiling it, flashing a module installed inside a Game Boy, and manually checking the result.

I built the GBoost Firmware Workbench to run the real shared production firmware logic on macOS and in WebAssembly. It is not a separate JavaScript reimplementation of the firmware.

The browser interface lets developers operate the module’s controls and observe its expected clock and status behavior. A private judge profile provides detailed engineering evidence, while controlled fault inputs exercise production recovery paths.

The same engine also runs deterministic scenarios covering boot, mode switching, timing boundaries, calibration, persistence, faults, sleep, wake, and recovery. Native and WebAssembly results are checked for agreement, and manually reproduced behavior can be retained as a regression test.

Shared production C++ remains the single source of truth. JavaScript only forwards inputs and displays results; it does not recreate firmware decisions.

Codex, powered by GPT-5.6 Sol, developed most of the Firmware Workbench during a single long-running goal session. It completed 13 milestones - from tracing production call paths and creating the shared-code host boundary to WebAssembly delivery, browser UI, deterministic testing, and release packaging - resulting in a working product. I defined the product direction, architecture constraints, and safety boundaries, while the checked-in tests and generated evidence provide the basis for trust.

Challenges

The main challenge was reusing real embedded logic without changing its behavior on the physical module or adding host-tooling overhead to a resource-constrained microcontroller.

Another challenge was defining an honest fidelity boundary. The workbench validates firmware-visible digital behavior, but it does not emulate a Game Boy CPU or commercial games. It also cannot prove electrical timing, oscillator accuracy, signal integrity, power consumption, LED output, physical wake latency, or stability on a real console. The displayed MHz value is decoded from the firmware’s digital request, not measured from physical hardware.

Making failures reproducible was also difficult. Timing boundaries, persistence, sleep, wake, and recovery paths are slow to test manually and easy to describe imprecisely. Deterministic scenarios and detailed evidence made those behaviors easier to inspect and retain as regressions.

What I learned

I learned that sharing production logic is much more reliable than maintaining a simulator that merely looks like the firmware. A clear platform boundary allowed the embedded target to perform real hardware operations while the host recorded deterministic evidence from the same decisions.

Finally, I learned how effective AI-assisted development can be when paired with narrow milestones, explicit safety boundaries, reproducible tests, and human ownership of product decisions. Codex accelerated work across firmware, testing, WebAssembly, UI, documentation, and review, while the project’s verification gates kept the results auditable.

The next step is to combine the workbench evidence with physical module validation, expand console and game compatibility coverage, and prepare the first controlled production batch of the overclock mod.

Built With

Share this project:

Updates