A YouTuber just made a Game Boy run on e-paper at 30 fps - and open sourced it

A YouTuber just made a Game Boy run on e-paper at 30 frames per second, and then open sourced the driver so anyone can try it on their own stock screen. Bo Made It published a video last week demonstrating what he calls the InkBoy on a tiny ESP32-S3-powered e-paper board, and the result looks just about as good as the original olive-green Game Boy screen - which isn't saying much, but it's an impressive feat to make this work on cheap, off-the-shelf e-paper hardware. The real story isn't the nostalgia: it's the custom driver that could theoretically let any e-paper display do the same thing, and the warning that comes with it: forcing custom waveforms and higher refresh rates on E Ink screens can cause permanent damage, and long-term panel life wasn't evaluated as part of the experiment. If you're going to try this, do so at your own risk, and maybe not on your modded Kindle - buy a cheap E Ink screen to break instead.

For those who haven't owned an e-reader, E Ink displays are great at what they're designed for. They can retain what's on the screen without continuously consuming energy by using electrical pulses to move charged pigment particles within individual pixels, enabling them to store the screen state physically. That makes e-paper devices very power efficient, but it comes with a huge trade off: changing those pixels is a glacially slow process compared with the modern displays we're all accustomed to. The screen that Bo used to make his InkBoy, for example, has a refresh speed of around 300 milliseconds, which is actually on the faster end of e-paper displays - but only really practical for displaying static images. Standard black and white E Ink displays contain two types of pigments: positively charged black ones, and negatively charged white pigments. Swapping between the two requires a series of brief electrical charges in a particular waveform pattern that gradually move the pixels from the front of the screen to the back, clearing out most of the pigment that shouldn't be at the surface. The native driver in Bo's Waveshare 1.54-inch ESP32-S3 e-paper display does just that, and it doesn't leave a lot of room for displaying motion.

To get around those limitations, Bo built his own driver for the display that shortened the waveform and enabled per-pixel driving to reduce image ghosting. More impressively, it enabled his ostensibly black and white screen to display four shades of gray, just like an original Game Boy. He was originally using dithering to create grayscale images, but it honestly looked horrible. Luckily, Bo noticed something while trying to fix the issue of image ghosting. "I noticed the display was already producing gray - just accidentally," he said in his video. "The pigment doesn't instantly jump from black to white, so I wondered if I deliberately stop driving it partway through the transition, can I produce those gray levels on demand?" The answer was yes, and with some additional tweaking he was able to produce those gray levels at 30 frames per second - a vast improvement from the 3.33 frames per second available with the original driver.

It's an impressive accomplishment, but is it a first? Not quite, but it's still a new way of approaching faster E Ink refresh times. As Bo explains, he got his idea from another YouTuber who built their own E Ink Game Boy, albeit with some entirely custom hardware that allowed them to bypass typical E Ink screen design to create their own faster display. What Bo did was code his own driver for stock hardware, making this an impressive accomplishment in its own right, and one enterprising user could theoretically reproduce on their own if desired. After a month of work, and with the admitted use of some vibe coding for the driver, Bo has published a working version of his driver on GitHub, but with a hefty warning: not only can forcing custom waveforms and higher refresh rates on E Ink screens cause permanent damage, but long-term panel life wasn't evaluated as part of his experiment, either.

The implications go beyond a retro gaming novelty. E-paper's power efficiency has made it the display of choice for e-readers, electronic shelf labels, and a growing wave of low-power IoT devices, but its slow refresh rate has kept it out of anything that needs motion. If software alone can push a stock panel to 30 fps with four gray levels, it opens the door to a new class of battery-sipping devices that can show video, animations, or interactive interfaces without the power draw of a traditional LCD or OLED. The catch is that this particular approach is a hack, not a certified solution: it trades panel longevity for speed, and it hasn't been validated for long-term use. For hardware makers, the lesson is that the display's native driver is not the limit of what the panel can do - but pushing past it means accepting risk that the panel vendor never signed off on.

For executives and engineers watching from the sidelines, the InkBoy is a reminder that open source hardware experiments can outpace vendor roadmaps. Bo's driver is on GitHub, and anyone with a cheap E Ink screen can try it today. The practical takeaway for product teams is to treat this as a proof of concept, not a production reference design: if you're building a device that needs motion on e-paper, you now have a starting point for custom waveforms, but you'll need to do your own reliability testing before you ship. And if you're a decision-maker at an e-paper panel vendor, this is a signal that the demand for faster e-paper is real enough that hobbyists are writing their own drivers to get it. The next step could be a vendor-supported fast mode that doesn't void the panel's lifespan - or a wave of bricked e-readers from people who ignored the warning and tried it on their Kindle anyway.