Khonbai is a preliminary specification for a general-purpose computer and video game console compatible with the Nintendo Entertainment System. It can be implemented on a single chip, ASIC or FPGA.



The first implementation is aiming for a RISC-V core with hypervisor extensions and support for the AXI4 bus. This may involve some permutation of the PicoRV32 core. 


Graphics are generated via an implementation of the Family Computer's PPU (picture processing unit.) Values are fed to the PPU over SPI, the bridge acting as a shift register to parallelize the input. The PPU outputs three 8-bit colour values, which are then converted to an AXI4-STREAM to be processed

A block diagram of a possible implementation. In this case, processing is quad-core.

by a video processing core.

Unless configured, the PPU lacks the original limitation of a maximum sprite count per horizontal line. This reduces the need for flickering routines which cause large sprites to appear transparent.

Screen Shot 2019-01-22 at 7.39.55 PM

In this screenshot of a Famicom game, Mario's sprite is distorted due to a limit of sprites that can be shown per line.

The video processor may support the ability to composite different sources above, behind, or alongside the NES PPU output. This could be utilized, for example, in a peripheral that allows the user to dock a Nintendo Switch into a Khonbai-compliant system, the system providing menus and additional functionality, e.g. the ability to inject and launch payloads via the Switch's RCM mode. Another use may be using the Khonbai-compliant system as a 10 foot interface to access various video inputs.

Field Programmable Gate Array

Khonbai-compliant systems can contain a field-programmable gate array - or, if the system is already running on an FPGA, a dynamically-programmable subdivision. This area is intended to be used for compatibility purposes - e.g. a recreation of the Motorola 6502's instruction decoder for compatibility with NES games.


The software stack is variable, but for standardization's sake, most tasks are hypervised via a minimal code stub which also provides access to key devices such as the bridge (and hence the PPU, APU, video processor, etc.) The code stub could host a shell or programming language such as BASIC.


The hypervisor could host operating systems such as Linux, which would be useful for things like file management and networked communications. Games could run as Linux processes, insofar as they had permission to tunnel graphics instructions back to the hypervisor.

Real time operating systems

Real time operating systems could run on the hypervisor, allowing it to function as a general control unit for use cases such as home automation and amateur robotics.

I/O Shields

A standard hardware expansion card could contain I/O shields that provide swappable output connectors on the back of the unit. For example, the default pack-in I/O shield may only contain HDMI connection(s) alongside USB ports and power. However, I/O shields could be made that pass through GPIO connections á la the Raspberry Pi. I/O shields could also be made that add additional HDMI inputs to composite multiple sources - for example, in a home entertainment center.


This standard seeks to accomplish a goal that other projects have tried before. It seeks to become a generalized, modular, standardized, appliance-like device that can be used for applications as diverse as family entertainment to Nintendo Labo-style electronics experimentation.

Community content is available under CC-BY-SA unless otherwise noted.