60 FPS gaming on an E Ink display? That doesn’t seem right… But that’s exactly what Wenting Zhang’s PaperBoy Game Boy emulator project does, using the M5Stack PaperS3 devkit, pairing an ESP32-S3 wireless microcontroller with a 4.7-inch E Ink display with 960 x 540 resolution.
One of the tricks here is that the bottom part of the ePaper touchscreen display is used for control buttons and doesn’t need to be refreshed, while the active part only requires 160 x 144 resolution, scaled three times to represent various shades of grey.
Contrary to most small Eink devkits, the PaperS3 features a screen with a raw row/column driver interface, which enabled him to drive the display while bypassing the normal waveform method, and deliver a higher refresh rate up to 60 FPS. Wenting didn’t reinvent the wheel for the Game Boy emulation part, and after testing three different emulators, he went with the CrankBoy project, delivering better performance at 30-60 FPS for most games. Tetris appears to be the most demanding game, while Super Mario Land offers the highest frame rate.
The audio implementation was also a challenge, mostly because the PaperS3 devkit only comes with a buzzer that can handle a single tone at a time. He solved the issue by using square waves for audio output, the same method as used on a PC’s buzzer. User input was easier with the touch screen, and Bluetooth LE joypad support was also added to the project.
You’ll find more technical details in the write-up on Hackster.io, or in the video embedded at the end of the video. The ESP-IDF-based source code can be found on GitHub, and the pre-built firmware can also be installed from M5Burner.
One downside is that the PaperS3 devkit is EOL (End-of-Life), so it’s hard to source, although it can be found on eBay for twice the original price. It might not be easy to find a replacement, since an ePaper devkit with a raw display interface is required to achieve the same results. The closest option is the older M5Paper based on the same display and still selling for $85, but it’s based on ESP32 instead of ESP32-S3, and would require further modifications.
Via Liliputing
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress. We also use affiliate links in articles to earn commissions if you make a purchase after clicking on those links.
Shame to learn that the PaperS3 is EOL. Wonder why M5 decided to bin it so quickly after release, since there doesn’t seem to be an upgraded version coming.
Yep I was surprised to learn that they EOLed it. They released a color version, but IMHO that’s a very different use case given the zzzzZZZZzzzz “speed” zzzzZZZZzzz of the Spectra E6. They should have kept the fast black and white besides the slow colour version.
I just hope this means they’re working on an updated version of the PaperS3.
The primary upgrade I’ve been recommending since the release was that they add a co-processor – an open source one – for driving the display. Even for the S3, driving a 960×540 e-ink display is a bit of a chore (not really a struggle, it just doesn’t leave much resources available for other tasks).
Which pushed the PaperS3 from a potential dynamic handheld terminal (a “proto-smartphone”), to a strictly task-specific device, as any framework that would allow for dynamic “app” (task) loading would overwhelm the device…
With an RP2350B, which can be set up with enough RAM for proper double-buffering at 8bpp colour depth (plus calculating the waveforms from the diff of the double buffer), can bit-bang it super effectively over PIO instead of using DMA and LCD/I80 interfaces, such a controller could act as a bog standard MIPI display over, say, SPI (plus UART for loading the firmware of it), reducing the pin need for display driving from nearly 20 to ~9 (2x for UART, 4x for SPI, pin hookups for BOOT and RST, plus a pin to control the Pi’s power supply switching), the resource usage to bare minimum, and barely increasing power usage.
That, and maybe a proper sound system would make the device immediately more useful.