RISCBoy is a handheld games console whose design files are published in full: a RISC-V compatible CPU, a raster graphics pipeline, a display and memory controller, and a complete PCB layout in KiCad. Most projects that call themselves open-source consoles stop at firmware or an emulator running on closed silicon. The RISCBoy repository publishes the hardware too, which is the part that changes who can manufacture one.
What is RISCBoy, and what does “designed from scratch” actually cover?
RISCBoy is a portable console whose entire computing stack (CPU, graphics, memory subsystem, and physical board) was written from scratch rather than ported or emulated on top of existing silicon. The design includes a RISC-V compatible processor implementing the RV32IMC instruction set, a raster graphics pipeline, a display controller, a bus fabric, memory controllers, UART, and GPIO, with the full PCB laid out in KiCad. Nothing in that list is inherited from a vendor reference design.
The project frames itself in deliberately retro terms, describing the result as “a Gameboy Advance from a parallel universe where RISC-V existed in 2001,” according to the repository. RISCBoy occupies that same design space: a 32-bit handheld with modest memory and a fixed-function graphics pipeline, rebuilt around an open instruction set instead of a licensed one. The hardware is new even though the form factor and ambition are familiar.
Why does open hardware matter when open firmware is already common?
The distinction that matters is the layer. A firmware or emulator release leaves the silicon sealed and the board undocumented; a hardware release lets someone else fabricate the device without asking the original designer. Most coverage filed under “open-source console” sits on the software side: emulators, firmware dumps, and retro handhelds that run on proprietary SoCs whose schematics never leave the vendor.
RISCBoy sits differently because it publishes both the Verilog gateware and the KiCad PCB files, so the barrier to producing a working board is fabrication access rather than a license negotiation. The repository is explicit that the open-source claim rests on the hardware files being present, not on the software being permissive.
The second-order effect lands on preservation and right-to-repair: when the design files are complete and public, keeping a console manufacturable no longer depends on the original vendor.
How do you fit a 32-bit console into 7,680 logic elements?
RISCBoy targets the iCE40-HX8k FPGA, a LUT4-based part with 7,680 logic elements, per the repository. That is a genuinely tight budget for a 32-bit machine with a CPU, a graphics pipeline, and a set of controllers, and it is the central engineering constraint of the project. The design is written in synthesisable Verilog 2005, and the toolchain is fully open: Yosys for synthesis, nextpnr for place and route, and Project Icestorm for bitstream generation, per community discussion.
On smaller iCE40 parts such as the UP5K, RISCBoy can be configured with a reduced RV32I variant, which in turn requires multilib standard libraries matched to the target instruction set, per the repository. The design is therefore not a single fixed target; it is parameterised across the iCE40 family, trading features for capacity depending on which part a builder has on hand.
Can anyone actually manufacture a board?
The KiCad PCB files are published in the repository, which is the part that matters for whether this is real open hardware or just a schematic on GitHub: the board design is open, not merely described. Whether an individual builder can turn those files into a working unit depends on access to a PCB fabrication service; the repository points to its own documentation for the practical detail a builder would need.
How is the CPU verified?
The RISC-V core is held to a higher verification standard than most hobby FPGA CPU projects. It passes the official RISC-V compliance suite for RV32IMC instructions, the riscv-formal formal verification suite, and a set of custom formal property checks covering instruction frontend consistency and basic bus compliance, according to the repository. Formal verification is the relevant detail: riscv-formal proves properties about the core’s behaviour across all reachable states rather than sampling test vectors, which is a stronger claim than “it boots.”
The testing infrastructure has its own constraints. HDL-level simulation uses Xilinx ISIM 14.x, tested only on Linux, and running the RISC-V compliance suite requires checking out the test suite via git submodules with specific flags to avoid conflicts with the KiCad directory layout, per the repository. Building software for the core requires the RV32IMC toolchain, again with multilib libraries for the smaller RV32I configuration. None of this is unusual for an FPGA soft-core project, but it does mean “open” describes the files, not a turnkey build environment.
What state is the project in right now?
Active development, not a finished product. The repository presents RISCBoy as a work in progress rather than a console you buy to play, and the design was discussed on Hacker News, per analysis coverage.
The honest framing is design transparency and educational value. The interesting artifact is the published design, not a shipping product.
What does an open console mean for preservation and repair?
The structural shift is straightforward. A console whose only open artifact is firmware is preservable only as long as someone stocks the original silicon; a console whose gateware and PCB are published is preservable as long as someone can manufacture a board. RISCBoy raises the bar for what counts as an open console precisely because the released files are intended to be synthesised and fabricated, not merely read. The repository publishes enough to build the FPGA image and the physical board, which is what separates a reproducible design from a documented one.
The unresolved question is durability over time. An open design published today is open in the present tense; whether it becomes a maintained platform or a snapshot depends on the author keeping it alive, and the repository has not answered that yet. What RISCBoy does demonstrate is that a complete, formally verified handheld console can be published in full.
Frequently Asked Questions
How much does it cost to manufacture a RISCBoy board?
The Rev A PCB design targets iTead’s 4-layer 5x5 cm prototyping service, which produces 10 boards for $65. This puts the physical board fabrication within reach of individual hobbyists rather than requiring a large production run.
What’s the difference between the iCE40 and experimental ECP5 versions?
The iCE40 build uses external 512 KiB, 16-bit wide SRAM, while the experimental ECP5 configuration replaces this with internal 256 KiB, 32-bit wide synchronous memory constructed from ECP5 sysmem blocks via the Trellis toolchain. The memory architecture change is why ECP5 support remains experimental.
What specific toolchain versions does HDL simulation require?
HDL-level testing requires Xilinx ISIM 14.x, and the testing has only been verified on Linux. This is a concrete dependency constraint beyond the general open-source toolchain requirement.
How do you run RISC-V compliance tests without KiCad directory conflicts?
The test suite must be checked out via git submodules with specific flags to avoid conflicts with the KiCad directory structure. This is a practical setup detail not mentioned in high-level verification descriptions.
When did RISCBoy gain mainstream attention?
RISCBoy reached the front page of Hacker News around July 11-12, 2026, which is when the broader developer community discovered the project. The repository existed before that but the HN discussion is what drove the recent wave of interest.
