For a long time, when I checked out the graphics for the 64DD title Mario Artist Paint Studio, the successor to Mario Paint, I found a bunch of graphics and text that seemed to be for printing images. I was not entirely sure how that worked, how to even access it. I didn’t know enough reverse enginnering “techniques” to even bother while I was translating all the Mario Artist titles.

Fast forward to this month, and with new tools that I wrote, I started to think again about this feature, because it seemed like a full fledged working overlay code. So I went on, and tried to find the other overlays, such as Game Boy Camera menu, and see how the game loaded the overlay and access it.

After finding the LBAs for those overlays, I tried to backtrack the process of loading until I find what is seemingly a bunch of functions to load, init and access the overlay. Bingo! One of them accesses the unused printer overlay. So all I need is to force a way to access it, such as repointing a button’s purpose.

Okay, so I’m greeted with an error that the Printer is not connected. Now it was time to know what it is actually doing to detect the printer. Turns out it expects the Transfer Pak, as there are errors involving the “64GB Cable” (japanese name)? With JoyBus commands that I’ve never seen?

I eventually respond with something that it wants with a custom script, and then I see commands that are pretty much as the same as commands used for the GameBoy Printer.

Thank you Shonumi for having this great article about the technical aspects of the GameBoy Printer, else I would have never known: https://shonumi.github.io/articles/art2.html

So, okay, we need to “emulate” an unreleased Transfer Pak Link cable feature, alongside some response from the printer.

For people who wants some technical information, here’s how the Transfer Pak Link Cable feature works, this uses the JoyBus commands 0x14 to write data (0x23 bytes to send, 0x01 byte to receive), and 0x13 to read data (0x03 bytes to send, 0x21 bytes to receive). (Oddly close to the commands used for GameCube to access the GBA…)

Those commands basically constantly uses 0x20 bytes for data, and 1 byte for some kind of CRC which, sorry, I haven’t taken the time to figure out the calculation, my script just fetches the CRC output.

I plan to write more about the Transfer Pak communication aspects later, as I want to focus on the GameBoy Printer Color.

Eventually it sends GameBoy Printer commands if you “emulate” the Transfer Pak link cable, then receives the so called “keepalive” byte, usually 0x81. And sure enough, I get a Pocket Printer screen.

You get a screen like this, where you can print vertically, horizontally, or vertical strips, with a bigger resolution. You can zoom the picture a bit when you hover the pointer to the picture. You can set the paper color to get a preview of the output, set the brightness and contrast, not unlike the GameBoy Camera, and then a button to print. It is slow, but I found one undocumented command for the GameBoy Printer: Command 0x08. It seems when there’s an error, this command is sent and may interrupt what the GameBoy Printer is doing? Either way, I’m sure Shonumi would be interested to verify this command.

However, this article is about the GameBoy Printer COLOR. Turns out the game expects more than one keepalive byte, it expects 0x81… but it also expects 0x82. What happens if we use that one?

Pocket Printer Color detected, with a full color picture at the center, and more settings. This time there are 5 print settings: slow horizontal/vertical, fast horizontal/vertical (difference explained later), and vertical strips. We are also allowed to change the brightness, contrast, and hue. And of course, the print button.

This is pretty huge, because not only we get to emulate an unreleased Transfer Pak Link Cable support, but also emulating an unreleased, heck, even unannounced GameBoy Printer Color, and Paint Studio provides a fully functional menu for it.

So here’s the commands for that hardware:

0x01 - Init

0x02 - Print Settings (used before copying)

0x04 - Copy Pixel Line

0x06 - Print? (used after copying)

0x08 - Stop?

0x0F - Nop (Status)

It is pretty similar to the original Printer, but some things are performed differently. First, it uses Command 0x02, which uses 5 bytes now, which I’m not sure of the definition (magic bytes, after all), aside that it may set the horizontal resolution, which is either 320 (slow print) or 160 (fast print).

Then it uses command 0x04, which copies a full pixel line, in either resolution, and sends a linear RGBA5551 line just like the N64 format, which means the printer supports a pretty good amount of colors.

After copying all the lines, command 0x06 is used… twice. I’m not sure what it does, but the menu does ask if you want to print the image again, and if I say yes, it only sends that command again, so that means the printer has a large buffer to contain a linear 320x240 RGBA5551 image, and that this command is related to print the image.

As far as I know, the printer status byte definition is very similar, if not the same as the regular printer.

I have made a script for Project64 that “emulates” the necessary stuff so you can mess around with this feature: https://github.com/LuigiBlood/EmuScripts/blob/master/N64/Project64/DMPJ_PocketPrinter.js

You can select the Printer Type between Normal and Color, and you have to click the Save & Load button to access this feature. Disable the script to recover the use of that button. There’s also a bit of documentation inside.

It also creates a RAW file output of what’s copied, so you can take a look at the image with a proper viewer.





This is kind of an experimental blog post, as I’m not very good at writing this stuff, but I hope this gives a good view of the GameBoy Printer Color.