PaperBoyS3 turns an E Ink display into a 60fps Game Boy emulator

For years, E Ink has been treated as the display technology for reading, signage and dashboards, not for fast interactive software. Its strengths are well known: high contrast, outdoor readability, low standby power and a paper-like image that remains visible without constant refreshing. Its weakness is just as familiar: speed. A conventional E Ink panel is not built to behave like an LCD or OLED screen, which is why the idea of a Game Boy emulator running smoothly on an e-paper display sounds like a contradiction. PaperBoyS3 changes that conversation in a practical and technically interesting way. Built around the M5PaperS3 development kit, it shows original Game Boy software running at up to 60 frames per second on a 4.7-inch E Ink touchscreen powered by an ESP32-S3 microcontroller.

A Game Boy emulator on e-paper

PaperBoyS3 is not a conventional handheld console and it is not trying to be one. It is a focused engineering project that takes a compact e-paper development board and pushes it far beyond its expected use case. The hardware foundation is the M5PaperS3, a pocketable board with a 960 × 540 E Ink touchscreen, an ESP32-S3 dual-core processor, microSD storage support, wireless connectivity and a simple onboard buzzer. On paper, that specification looks better suited to note-taking tools, dashboards or low-power interfaces than to gaming.

The software turns that assumption around. Instead of suited to note-taking tools, dashboards or low-power interfaces than to gaming.

The treating the E Ink panel as a slow full-refresh display, PaperBoyS3 drives it with a custom approach that allows the screen to accept fresh image data at a 60 Hz rhythm. That makes original Game Boy titles playable in a way that standard e-paper behaviour would not normally allow. The result is not a commercial gaming device, but it is a serious technical demonstration of how far a modest embedded platform can be taken when display timing, memory use and emulation workload are carefully balanced.

Why E Ink is difficult for games

The central challenge is the nature of E Ink itself. LCD and OLED panels change pixel states electronically at speeds suitable for video, animation and real-time interaction. E Ink panels work differently. They move charged particles inside tiny capsules, and those particles take measurable time to settle into the desired visual state. That physical process gives e-paper its crisp, stable image, but it also leads to slow refresh rates, visible ghosting and delayed response when the whole panel is updated in the usual way.

For a reader or calendar display, that delay is acceptable. For a game, it is a problem. The original Game Boy outputs a 160 × 144 image and expects responsive frame delivery, input handling and sound timing. Even a simple platform game can feel wrong if screen updates lag behind button presses. PaperBoyS3 addresses this by refusing to wait for a traditional whole-screen update cycle. Instead, it manages pixel state more actively, keeping track of how long individual pixels still need to be driven while continuing to feed new frames into the display pipeline.

The trick behind 60fps E Ink

The key innovation is the custom display driver. Rather than using a global lock that waits for the full panel update to complete before accepting new image data, the driver maintains a compact state record for each pixel. In this case, only four bits per pixel are used to track display behaviour. That state buffer allows the software to keep each pixel moving towards the right shade while still processing new frames at regular intervals.

This is where the Game Boy’s low resolution becomes an advantage. The M5PaperS3 panel has far more pixels than the original console needs. PaperBoyS3 scales the 160 × 144 image by a factor of three and uses dithering to represent the handheld’s greyscale output cleanly on the E Ink display. Because the processed image area remains modest compared with the full 960 × 540 panel, the workload stays within reach of the ESP32-S3’s internal memory and processing limits. The active buffers can remain in fast SRAM, avoiding the performance penalty of slower external memory.

That detail matters. On embedded hardware, memory bandwidth can decide whether a clever idea becomes usable software or a barely running prototype. PaperBoyS3 succeeds because it does not attempt to treat the e-paper panel like a general-purpose video monitor. It narrows the workload to the Game Boy image, then spends its limited resources exactly where they matter.

The ESP32-S3 is pushed hard

The ESP32-S3 is not a gaming-class processor. It is a dual-core microcontroller designed for embedded devices, IoT products and compact interactive hardware. PaperBoyS3 uses both cores aggressively. One core handles the Game Boy emulation workload. The other deals with display updates, DMA transfers and supporting tasks that need to stay in step with the 60 Hz output rhythm.

The emulator core is based on CrankBoy, an optimised fork of Peanut GB. That choice is important because Game Boy emulation on a microcontroller leaves very little room for inefficiency. The original console may look simple next to modern hardware, but accurate emulation still involves CPU timing, graphics behaviour, memory mapping, cartridge features and audio state. PaperBoyS3 does not run every situation at a locked 60 frames per second, but it is capable of maintaining playable speed across many original Game Boy titles. When the workload becomes heavier, dynamic frame skipping helps the system preserve timing rather than letting input and audio drift.

Game Boy Color support remains a harder target. The colour handheld has higher processing demands, and the ESP32-S3 already runs close to its practical ceiling in this project. That limitation is not a failure of the concept. It is a reminder that this is a tightly optimised embedded build, not a general emulator box with spare compute power.

Sound from a buzzer, not a speaker

Audio is one of the more obvious compromises. The M5PaperS3 includes a buzzer, not a full speaker and audio subsystem. A standard emulator would typically mix the Game Boy’s sound channels into PCM audio and send that to a DAC or audio codec. PaperBoyS3 has to work with much less. The solution is a pseudo-polyphonic system that rapidly switches between simplified versions of the Game Boy’s four audio channels.

The result is recognisable rather than faithful. Chiptune melodies come through, effects are present, and the system is audible enough to support play. It does not reproduce the original audio hardware with the precision expected from a dedicated emulator on a PC, smartphone or high-end handheld. For this project, that trade-off is sensible. The point is not studio-quality sound. The point is making the onboard hardware do enough without adding external components or shifting the design away from its compact development-board roots.

Touchscreen controls and Bluetooth experiments

PaperBoyS3 uses the M5PaperS3 touchscreen for its main control layout. The lower part of the display presents a Game Boy-style directional pad and action buttons, turning the e-paper panel into both screen and controller surface. Touch input is never going to match the feel of physical buttons, especially for games that depend on precise timing, but it keeps the system self-contained and immediately usable.

There is also experimental Bluetooth LE controller support. This is a more promising direction for serious play, even though compatibility remains limited. External controls solve the biggest ergonomic drawback of a touchscreen-only handheld, but the implementation still needs refinement before it can be treated as broadly dependable. For now, it is best understood as a useful feature under development rather than a polished input layer.

Saving games needs manual discipline

Save handling is another area where the limits of the platform shape the user experience. Game data is stored on the microSD card, but the M5PaperS3 power button directly cuts power. That means there is no automatic shutdown sequence during which the emulator can safely flush save data. To avoid data loss, PaperBoyS3 adds a manual save control on the touchscreen.

This is less elegant than automatic saving, but it is honest engineering. Rather than pretending the hardware can guarantee safe shutdown behaviour, the software gives the player an explicit action. Quick save and quick load features add another layer of protection, allowing the full emulated state to be stored and resumed. On a device that can lose power without warning, that is not just convenient. It is necessary.

What this means for E Ink devices

PaperBoyS3 is interesting because it challenges a lazy assumption about e-paper. The usual statement is that E Ink is slow. More precisely, E Ink is difficult to drive quickly under normal controller behaviour and conventional full-refresh workflows. PaperBoyS3 shows that, with direct low-level control and careful workload design, an E Ink panel can support far more dynamic content than most products attempt.

That does not mean e-paper will replace LCD or OLED displays for gaming laptops, handheld PCs or phones. The technology still has real constraints, including response time, ghosting, greyscale limitations and refresh complexity. However, it does suggest a wider future for fast e-paper interfaces in specialist devices. Low-power terminals, readable outdoor control panels, monochrome development tools, minimalist gaming devices and always-on dashboards could all benefit from display techniques that reduce the gap between static e-paper and real-time interaction.

A clever device, not a consumer product

The most important point is to keep expectations grounded. PaperBoyS3 is not a mass-market Game Boy replacement, and it should not be judged as one. It is a working demonstration of a display technique, an emulator port and a set of hardware trade-offs packed into a small embedded device. It has touchscreen controls rather than proper buttons, buzzer-based audio rather than a real speaker system, limited controller support and no realistic path to demanding colour titles on the same hardware today.

Those compromises do not make it less impressive. They make the achievement clearer. This project takes an ageing development board, a slow display technology and a low-cost microcontroller, then makes them behave in a way that looks almost unreasonable at first glance. The important lesson is not that everyone should play Game Boy games on E Ink. The important lesson is that display limits are often as much about drivers, buffers and assumptions as they are about the panel itself.

Verdict

PaperBoyS3 is one of the more technically meaningful E Ink experiments of 2026 because it does not rely on vague promises or oversized hardware. It demonstrates 60fps e-paper gaming on an ESP32-S3 platform by matching the software design to the exact strengths and weaknesses of the hardware. The custom pixel-state driver is the real story, while the Game Boy emulator provides a demanding and immediately understandable test case.

For computer hardware readers, the appeal is straightforward. This is embedded optimisation with visible results. It combines a low-resolution emulator, a high-resolution E Ink touchscreen, dual-core task separation, SRAM-conscious buffering, DMA-driven display output and pragmatic audio and save systems. PaperBoyS3 is not polished consumer electronics. It is better viewed as proof that e-paper still has unexplored territory when engineers are willing to go beneath the usual display stack.

The SEO-friendly headline is 60fps E Ink Game Boy emulator, but the deeper significance is broader: PaperBoyS3 shows that e-paper can be more responsive, more interactive and more flexible than its reputation suggests. Not everywhere, not without compromises and not without serious low-level work. But on the right hardware, ith the right driver, even an E Ink Game Boy can run fast enough to be playable.