Game Bub: an open-source FPGA handheld for the Game Boy family

A handheld whose hardware design is published too

Game Bub is an FPGA retro emulation handheld with support for Game Boy, Game Boy Color and Game Boy Advance games, and the phrase that matters is open-source. The repository does not contain only the software for a device someone else designed. It contains the FPGA source, the firmware, the scripts, and the license files for the PCB schematics and layout, the mechanical files and the hardware design. That makes it a hardware project in the open hardware sense, where the board files are part of the deliverable. The audience is a specific kind of person: a maker who wants a physical handheld with real cartridge support, who is comfortable with a soldering iron and a 3D printer, and who would rather own the design than rent it from a vendor. A prebuilt unit can be bought from Crowd Supply if the manufacturing route is not what you want.

The XC7A100T does the emulation, the ESP32-S3 does everything around it

The architecture splits the work across two chips, and the division is clean enough to explain in one sentence each. The Xilinx XC7A100T FPGA handles the main emulation and the I/O, which means the console logic and the Game Boy hardware are implemented in the fabric. The ESP32-S3 microcontroller handles the auxiliary tasks: configuring the FPGA, rendering the user interface, loading ROM files from a microSD card and sending them over to the FPGA. That division is why the repository has two top-level source directories. The fpga directory holds the HDL source, written in Chisel, which is a Scala-embedded hardware description language, and it is where the cores live. The firmware directory holds the microcontroller firmware, which is what the ESP32-S3 runs. The project also documents an architecture description for revision 2 in the docs, and an announcement blog post that walks through the development process.

From-scratch cores, written in Chisel rather than Verilog

The cores are custom, from-scratch Game Boy and Game Boy Advance FPGA cores, and the README's claim about them is game compatibility. What makes them interesting to a hardware engineer is how they are written. Chisel is a way of describing hardware in Scala, and using it means the cores are built from composable Scala structures that generate the HDL underneath, rather than from hand-written Verilog. The primary language of the repository is Scala for exactly that reason. A consequence worth naming is that the two halves of the project are reviewed differently: the FPGA side needs a firmware-free way to check that a change still behaves like the original console, while the firmware side has the usual embedded concerns of memory, timing and update paths. The tree also carries a scripts directory, which is licensed with the firmware rather than with the hardware design, and a CONTRIBUTING.md at the root.

Cartridges, microSD ROMs and the accessories the emulated hardware expects

Two input paths are supported. Physical Game Boy, Color and Advance cartridges work, and the device emulates the systems closely enough that the peripheral behaviour of those machines is part of the feature list. ROM files from a microSD card are the second path, and the README calls out the built-in support for rumble, the clock, the accelerometer and the gyroscope, which are the accessories that define what a Game Boy Advance session feels like. Multiplayer link cable functionality is there as well, so two units can be linked for the games that support it. On the output side, video goes to a TV or monitor through the Game Bub Dock, which is what turns the handheld into a console when you want a bigger screen, and the hardware is described as extensible and designed for future improvements, which matters if you are the kind of person who intends to add something to it.

Two licences, and a trademark you cannot reuse

The licensing is where a hardware project has to be precise, and Game Bub splits its files across two licences. The firmware in the firmware directory and the scripts in the scripts directory are licensed under GPLv3, specifically GPL-3.0-only. The FPGA source in the fpga directory is licensed under the CERN Open Hardware License Version 2 Strongly Reciprocal, CERN-OHL-S-2.0, and the same licence covers the PCB schematic and layout along with the mechanical and hardware design files. The README summarises the effect: you can copy, share and modify the source code as long as you give proper attribution and share your source code or design files under the same licence. Two cautions sit on top of that. The obligation to share design files applies to hardware, not just code, so anyone who builds a derivative board inherits a distribution requirement. And the Game Bub name and logo are trademarked, so you cannot put them on your own product without permission.

Manufacturing your own means PCBs, printed shells and parts from several sources

The building documentation is honest about what the project involves. Building a Game Bub handheld requires manufacturing PCBs, 3D printing the shell and buttons, and assembling components from a variety of sources. That is not a weekend kit with a single bill of materials, it is a procurement and assembly project, and anyone budgeting time for it should plan for the parts hunt as the main cost. The README also flags a documentation gap you should know about before you order anything: the building instructions it links to cover the older, vertical revision 2, and updated building information is due in the Game Bub Docs soon. The architecture document has the same caveat, describing the project as of revision 2. In other words, the published documents may not match the current hardware, which is the single most important thing to check if you intend to build rather than buy. For questions there is a support address, and for the community a Discord server, so the gap is at least visible to the people who can answer it.

Firmware releases move faster than the hardware revisions

The release history is worth reading next to the branch name, because it shows where changes actually land. The published releases are firmware versions: v1.0 on 2026-08-26, v1.0.1 later the same day, and v1.0.2 on 2026-09-10. The default branch is called handheld, and the last push was on 2026-09-27. So the released artefacts are the microcontroller side, which is where changes are safe to make without asking anyone to re-spin a board, and the FPGA cores and hardware files move in the same repository but are a different kind of commitment. That is the natural shape for an open hardware project, and it is also the reason to read the version numbers carefully: a user flashing firmware wants the newest stable build, while someone building a board needs to know which core revision pairs with which board revision. The README does not publish a compatibility matrix, so that pairing is a question for the maintainers rather than something you can look up in the repository, and the documentation for the current revision is still on its way.

Editorial conclusion

Game Bub fits a maker who wants an open handheld with real cartridge support, link cable play and video output, and who is either willing to assemble a board or willing to buy one from Crowd Supply. It is the wrong choice if you want a device that runs whatever emulator you like, since the supported system list is limited to what has an FPGA core, and it is the wrong choice if you need to ship the design under your own brand. Before building, read the architecture and building documents and check that they cover the revision you have, and separate the firmware licence from the hardware licence before you redistribute anything you derive from it.

Frequently asked questions

Official sources

1. elipsitz/gamebub on GitHub
2. Issues
3. License: CERN-OHL-S-2.0
4. README
5. Releases