Edit 2025: time has passed since this project which was my very first repository. All the features presented here (emulator + decoder + paper emulator) are now merged into the TinyGB Printer device for RP2040. The codes in the current project are still updated from time to time to improve their ease of use.

Gameboy Printer Paper Simulation

• Authors: Raphaël BOICHOT, Brian KHUU
• Featured on Hackaday

This project uses the Arduino Game Boy Printer Emulator to get raw printing data and GNU Octave/Matlab to decode them in a fancy manner. It is compatible with any of the 110 games compatible with the Game Boy Printer.

This e-paper feature is now included in the GBCamera-Android-Manager which allows printing and sharing your images online with a mobile phone !

The motivation ? As Game Boy Printer paper is becoming more and more difficult (and damn expensive) to source and subjected to definitive deterioration with time, emulating it is more and more appealing from an heritage conservation point of view. And using 6 AA batteries in 2024, honestly...

The Game Boy printer emulator developed by Brian Khuu which is used here is able to capture a stream of serial data under text form. The project here aims to transform this hexadecimal text stream into pleasant images that have the realistic aspect of a roll of paper exiting a thermal printer. Reproducing the tone, noise, granularity and aliasing of to the printer head is challenging compared to a classical pixel perfect rendering. And what is challenging is fun.

My initial trial: the mathematical way

My first idea was to do a simulation of printer head by replacing hard square pixels by some sort of bell-shaped spots with lots of noise. A 2D bell-shaped approximation had a sense to me as injecting heat in a point on a 2D surface result in gaussian distribution of temperatures. On thermal paper, tones are due to a chemical reaction of a powder deposited on the surface of paper driven by temperature and phase change. I took inspiration from cashier tickets and Game Boy Printer scans at high resolution. Misalignment of the printer head was also simulated. The result of a pure mathematical approach was interesting for sure.

Let's play with noisy gaussian dots

Example of an early attempt of paper simulation

Even if it was not bad at all, pixels were too regularly spaced and paper fibers that deform the dots and create vertical streaks on paper were impossible to simulate with this approach. We need a more agressive design !

My second trial: going brute force

After considering the differences between early outputs and real prints (scanned at 3600 dpi) obtained with a recently bought Pocket Printer, I was still not satisfied by the result. The difficulty is that the printer head and paper grain add noise to the image at different length scales. Moreover, the needles from thermal printer head do not just create noisy gaussian dots. These dots also have a random shape (typically due to fibers in paper). So my new idea was to sample a collection of representative pixels of the different grayscales on a good quality scan of isolated pixels printed with my Game Boy Printer.

There is no image available to print in Game Boy library that presents perfectly isolated pixels in huge quantity. So I have created a test case with my brand new SD Game Boy printer code

I first printed this test image with isolated pixels of the three different grayscales (white is just ignored):

Then I scanned a printing of this image at 3600 dpi (sufficient to see the details of pixels, each pixel being approx. 20x20 pixels on the scan):

And I sampled manually a collection of 50 pixels of each level of grayscale (very boring task but quite rewarding at the end):

Then the GNU Octave/Matlab code just reads a pixel on a pixel perfect image to get its color, picks a random pixel among the 50 of its own "color" and draws it on a new file with some overlapping. 50 pixels of each color is not much, but a pixel is a simple matrix of value. In consequence, to increase randomness each pixel itself is flipped or rotated randomly so that more than 200 different pixels can be generated out of just 50 for each color. Finally, the real printing paper presents fibres that create vertical streaks of "ink" (thermal paper has no ink but you see the idea). So the code randomly decreases the intensity of printing along some streaks of limited length chosen randomly. Of course the code in its present form can be improved, but the result is enough for my poor visual acuity.

Test case with a Chip Chip printed from Super Mario Deluxe

How to use the Game Boy Printer paper emulation ?

You will need: the cheapest Arduino Uno, the cheapest LED, the cheapest wires, the cheapest soldering iron or the cheapest breadboard, a serial cable to sacrify (for example the cheapest chinese clone found on Aliexpress, please do not sacrifice original Nintendo cables) and for ease the cheapest multimeter with continuity mode. The total project cost should be around $10 maximum. Wire and/or solder all that stuff, recharge your cheapest NiMH batteries and you are ready for printing.

Indirect printing from Matlab/GNU Octave using a logfile

• Install the last Arduino IDE and load the .ino file to the board.
• Install the open-source GNU Octave or enjoy your pricey Matlab license.

On Arduino IDE 1.8.X and earlier:

• Connect your Game Boy to Arduino with serial cable, open the serial console in 115200 baud and print as with a real Game Boy Printer.
• Copy/paste text obtained directly from the Arduino serial into Entry_file.txt

On Arduino IDE 2.X.X:

• Copy/paste text obtained from any terminal emulator like PuTTy into Entry_file.txt (or just target the putty log file to Entry_file.txt). Arduino IDE 2.X.X does not allow reliable copy/paste from its serial anymore (it's not clear whether this is a bug or intentional).

• Open Octave/Matlab code Main_Decoder.m

• Choose some color palettes and printing options (default are OK).

• Run and wait for completion, code is fast on Matlab, slower with Octave.

• Enjoy your images. The code outputs both pixel-perfect and paper-like images, can handle compressed protocol, custom palettes and the many variations of the Game Boy printing protocol. The Entry_file.txt is automatically backed-up with a unique date/ID so that you can process old printing sessions later or with other tools, for example the wifi-gbp-emulator.

Direct printing from Matlab/GNU Octave without using the Arduino IDE !

You can run Read_directly_from_Arduino_Matlab.m or Read_directly_from_Arduino_Octave.m directly to acquire data and decode them in the same run. It behaves like the Arduino Serial output from the IDE but without the need to copy-paste text output: the decoder is ran automatically as soon as you reboot the Arduino after a printing session. How to use it :

• Install the last Arduino IDE and compile/load the .ino file. Close the IDE, you won't need it anymore.
• Use your pricey Matlab license or the free GNU Octave alternative and run the .m scripts with the Arduino connected to the USB port. It automatically detects the serial port to address.
• Connect your Game Boy to Arduino with serial cable and print. It must behave like with the Arduino serial console but into the GNU Octave/Matlab Command window.
• Print your images as usual.
• Once the printing session is finished, reboot the Arduino, it will indicate to GNU Octave/Matlab that transmission is over and will run the decoder automatically.
• Enjoy your images. The code outputs both pixel perfect and paperlike images, can handle compressed protocol, custom palettes and the many variations of the Game Boy printing protocol.
• Code generates a log file that you can process again later with the classical decoder "Main_Decoder.m" or with the wifi-gbp-emulator. The text output is also automatically backed-up with a unique ID so that you would never lost your prints.

The pinout to use for Arduino

But you can also use a dedicated PCB !

If you want something neat, you can follow the instructions given here to build a dedicated PCB (for cheap, really).

Back to the main subject

So, the difficulty with a Game Boy printer emulator is to know where the images have to be cut automatically. It can appear trivial to human mind (tear paper when the print is finished) but it is not for a code (some printing sessions have more than 10 seconds deadtime inbetween packets). 90% of the game sends a margin infor