This is one of those projects that was both inspired and made possible by the absolute embarrassment of dev boards available to the modern hacker. In this case, the dev board was the M5Stack PaperS3, which as the name implies combines an ESP32-S3 with an e-ink panel. [Wenting Zhang] picked one up and was immediately inspired to try and make an e-ink Game Boy.
The M5Stack PaperS3 made this project possible by exposing the display with row/column control — parallel, some would call it, as opposed to the usual serial interface of SPI. That allowed [Wenting] to work some of the same e-ink magic he perfected on his Modos monitors to allow partial refresh at up to 60 Hz. That the ESP32-S3 is capable of emulating a Game Boy while driving the screen should surprise no one, since it can emulate an MSX while outputting VGA or even Windows 95 on a 386. In this case, he’s basing the actual Game Boy emulation on Crank Boy.
Of course the e-ink screen on the M5Stack is far larger and has a much higher resolution than what the Game Boy shipped with, which lets him implement touch controls and scale the image up 3X so he can fake a couple of shades of grayscale while actually outputting black and white. Even better, if he was actually playing this thing on the regular, once the high-refresh portion of the screen starts to wear out, he can flip the orientation and keep gaming on the virtually-unrefreshed control portion of the screen — doubling the lifetime of the system, something many of you raised as a concern when we last looked at a his e-ink monitor project.
The only real shortcoming of this hack is the sound. With one-bit beeps coming out of the M5Stack buzzer, it’s got nothing on Nintendo’s hardware. Of course, that’s partially down to using the hardware as-is. With the addition of an I2S sound chip like the one used in the MOD player project we featured recently, you’d just need to squeeze out enough processor cycles to make this sound as good as it looks.
I find this quite cool. :) The big question though is: with this e-ink screen, does it last as long as the Gameboy classic? I.e. between 10 to 30 hours of play before batteries need changing/charging?
And actually, on lithium AA batteries, the Gameboy classic can run over a 100 hours before running out of charge. :)
There are enough variables here that the only real way to know is to try it, but I’d suspect the original Gameboy still has an edge when it comes to battery life.
Various sources suggest that the Gameboy consumes about 0.7 watts under operation. Coincidentally, according to the official specs, the m5stack PaperS3 also consumes just under 0.7 watts while active, with the ESP32-S3 accounting for perhaps 0.45 watts on its own… but I doubt those specs are anticipating someone driving the e-ink display the way this project does, which is rather power intensive.
At 1800mAh/4.2v nominal, the built-in battery on the m5stack is also a bit lower capacity than a decent set of four alkaline AA batteries.
I received two M5 stack boards from a friend who had buyers remorse and promptly binned em and the plethora of stickers included. Thanks for taking useful items and obfuscating the gpios while managing to add nothing I couldn’t do in I2C at least on the boards I had. Actual dev boards are far more useful and plenitful at pennies on the dollar lol.
I think if you’re looking for dev board functionality you don’t want M5 stuff, but that doesn’t mean M5 stuff has no purpose. I see it as being more like a demo product that’s still at the stage of being usefully programmable, that’s the benefit of the different modules, the cases, etc. If you’re trying to hook it up to much outside the M5 world it’s probably the wrong choice.
It’s a shame that this board is completely discontinued now so you couldn’t make one of these if you wanted to. You’d have to use the new 1.1 version… And most likely fix the code
I wonder if you can just use the CPU to calculate the screen pixels, and re-rout CPU cycles during the time when the CPU is waiting for pixel 2/3-3/3 is being drawn?
The CPU can handle the pixels easily because it’s basically doing 1/3rd of the work, so is there any CPU cycles left for sound generation or game emulation?
I would think the lack of physical buttons would be the main shortcoming 🤷🏼♂️
I presume that would be easily fixable though. Especially if you could use a single side SMD board, then you could still flip the screen if desired.