Conference Badge Turned Game Boy Color: A Gemini-Assisted Hardware Hack

One Badge, Two Identities

At the GitHub Universe conference, the badge attendees receive isn't a plastic card with a name printed on it—it's a miniature computer with a color screen. According to Simon Willison's blog post, this isn't his first time tinkering with this hardware—last year he already tried to do something with the badge, and this year he went further.

The person who really brought this to a head was Steve Francia. With the help of Gemini, he first got a full NES emulator running on the badge, then moved on to older platforms, porting Game Boy and Game Boy Color emulators onto it as well. This means that as long as you have legal ROMs on hand, you can play The Legend of Zelda: Link's Awakening on a device hanging around your neck.

The Technical Path of the Hardware Hack

From NES to Game Boy Color

Emulator porting itself is not a new topic, but compressing it onto a conference badge presents the challenge of resource constraints. The badge's performance is far below that of a dedicated handheld, with quite limited memory and processor headroom. Francia's path was to first tackle NES emulation, verify feasibility, and then extend to the Game Boy series—although the latter is from an earlier era, the Game Boy Color's color display and power management logic have their own set of considerations, and it's not something that can be reused through a simple downgrade.

Based on publicly available information, AI plays a supporting role here. According to the original description, Francia collaborated with Gemini to complete the emulator adaptation work. This is more like using the LLM as a debugging partner: understanding hardware documentation, troubleshooting compatibility issues, and generating or adjusting low-level code snippets. It does not replace the developer's judgment about how emulators work, but it can significantly shorten the trial-and-error cycle.

An emulator is essentially a high-fidelity reconstruction of the target hardware's behavior, and the instruction set and timing are the two most critical dimensions. The instruction set determines which operations the CPU can execute—for example, the NES uses a variant of the 6502, while the Game Boy uses the Sharp LR35902, and the two have completely different instruction encodings and execution semantics. Timing is more subtle: game code often relies on precise cycle counts to synchronize graphics, audio, and input, and once the emulator's estimate of the clock cycles consumed by each instruction is off, you get screen tearing, detuned audio, or even infinite loops. On performance-constrained badge hardware, the emulator also needs additional dynamic recompilation or interpreter optimization to leave limited CPU cycles for rendering and input response—this is also the most time-consuming part when porting to embedded devices.

The auxiliary role of LLMs in hardware reverse engineering usually shows up in several specific steps. When facing a custom motherboard without a complete datasheet, developers can hand register read/write logs or disassembly fragments to the model and ask it to infer whether a certain address might correspond to a display controller or a power management unit; the model can also generate minimal reproduction tests based on error messages, or rewrite scattered C code snippets into a form adapted to a specific compiler. The limitations of this kind of collaboration are equally obvious: the model cannot actually run code, lacks intuition about timing constraints and hardware side effects, and its suggestions still need to be verified one by one by the developer. So it's more like an always-on pair-debugging partner that compresses the time spent looking up information and trying things out, rather than replacing an understanding of the architecture.

The Overlooked Interaction Design

There's an easily overlooked detail about the badge: it can be held upside down. After flipping it over, the touch buttons built into the badge body land exactly where fingers naturally rest, turning it into a simple gamepad. This design might originally have been just for show, but combined with an emulator it takes on practical use—screen on top, buttons below, with an operation logic close to that of a handheld.

The fun of this kind of hardware hack often isn't in the performance specs, but in discovering the redundancy the designers left behind. Touch buttons, a color screen, a flippable structure—viewed individually, they're all showcase features, but combined they support a complete use case.

Capacitive touch buttons differ noticeably from mechanical buttons in game operation. Touch buttons have no physical travel and lack the tactile feedback of pressing and releasing, making missed or accidental touches likely during rapid repeated presses or simultaneous multi-button operations. For an emulator to be playable, it usually needs debouncing, hold detection, and input buffering at the software layer to convert touch signals into a stable state approximating a gamepad. In addition, when the badge is inverted the screen orientation flips as well, so the display driver needs to support 180-degree rotation; otherwise the image and button positions won't line up. These details show that turning a showcase interaction into an input device is difficult not because of the hardware itself, but because of the remapping of input semantics at the software layer.

AI's Real Place in Hardware Hacking

Reducing this to "AI wrote an emulator" is not accurate. The core of an emulator is precise modeling of the target platform's instruction set and timing, and this part depends on long-accumulated engineering knowledge. AI's value shows up on the periphery: when facing custom hardware without complete documentation, it can help developers quickly understand register behavior, generate test code, and explain error messages.

According to the public records of both Willison and Francia, this hack was the result of collaboration between a human and a model, not something the model completed independently. This distinction matters—it shows that the current positioning of LLMs in embedded and hardware reverse engineering scenarios is that of an accelerator, not a replacement. For developers who want to reproduce similar projects, this means the barrier to entry is lower, but a basic understanding still cannot be skipped.

The Evolution Direction of Conference Swag

Conference badges evolving from identity markers into programmable devices is a line that has continued for several years. GitHub Universe's badge has maintained the form of a color-screen computer for two consecutive editions, indicating that the organizers intentionally treat it as a vehicle for technical showcase. What attendees take home isn't just a souvenir, but a platform they can keep tinkering with.

For hardware enthusiasts, the appeal of this kind of device lies in its clear constraints and community sharing. A badge's performance boundaries are known, everyone faces the same limitations, and thus modification approaches can be borrowed from one another. When someone gets an emulator running, others can follow that path and try other possibilities.

The original article does not disclose the badge's specific hardware specifications, nor does it state the emulator's frame rate or compatibility range. What is certain is that a device hanging around one's neck can now run games that thirty years ago required a dedicated handheld to play—and in the workflow behind this, AI models have earned a place.