Arduboy 'Classic'!

Right, the question then is how fast can the Nano paint the LCD (from FIFO) if that’s all it’s doing (it should be doing more, but this is a starting point).

That’s what I was asking.

Controlling the GameBoy LCD means manually handling the HIGH / LOW state of ten separate pins in the correct sequencing - when I get the time I can edit the LCD controller sketch to make the ‘active area’ fullscreen, and then get the scope out again to see how many FPS.

At that point, the limiting factor would be how far an Arduino Nano can be overclocked!

Are 8 of those a parallel data bus by any chance? If so you can put them on a single port of the Arduino and set them with a single CPU cycle.

The lines in question are VSYNC, ALTSIGL, CLK, DATA1 (MSB), DATA0 (LSB), DATALCH & HSYNC on the LCD itself as well as CLK on the flip-flop and READ ENABLE & RETRANSMIT on the FIFO.

They are manually handled asynchronously to be sure that each pin is in its required state in the correct sequence in relation to the rising / falling edges of the other pins.

OK, have gone to fullscreen, and the VSYNC has only dropped from around 80 FPS down to 63.6 FPS:

Here is a quick fullscreen hypno-spiral 5-frame animation demo (five 2,880 byte frames = 14,400 bytes of PROGMEM):


So the question is what is the CPU % at 60fps… i.e. does it take 50% or 80% CPU just to draw that screen. Just painting the Arduboy screen (from buffer) over SPI (at 60fps) takes like 20% of the CPU cycles at 16Mhz…

You can just time a “repaint” (millis() after - millis() before) from the FIFO to get the ms count… 16.66ms is your target for 60fps at 100% CPU. Anything longer means your frame rate drops… anything lower means you’re not fully using the CPU and you have some bandwidth left over.

Wait, what is LSB and MSB? Is this a 2-bit data bus then?

I’d have to see the code but it could really help making sure 8 of those are on the same port… are you using ports directly or using something like writePin()?

Switched to a DIY custom backlit / biverted GameBoy LCD, which makes taking pictures / video far easier!

Have been experimenting with some different video modes to make the most of the Arduino Micro’s limited resources.

Here’s an example using half-size 80x72 frames which are then scaled up to full-size 160x144 frames during rendering - so this is 33 frames, 80x72 pixels = 720 bytes per frame:

Here’s the source image (from

And here’s an example of a text-mode game, using 8x8 characters gives 20x18 characters on the 160x144 LCD (this could easily be turned into a graphics tile mode as well by replacing the characters with tiles):

The great advantage of text-mode is that the screen buffer is only 360 bytes (20x18) as opposed to 2880 bytes (160x144 / 8)!

I adapted the game from this source:


Gadzooks man what the actual hell! Incredible work!

I chose [1] Scream like a girl!

1 Like

Oh man what an endeavor! Now I want to cram Arduboy guts into a Neo Geo Pocket…


This is a super-cool project! Love it!

1 Like

just stumbled on this old project, it’s pretty awesome and I’m wondering what happened to it?

I’d love to have an “Arduboy Classic”, because well, it’s that cool!


Soo holy necropost batman but, wondering if this would work on a color LCD of a GBA as well?

Thinking of using a GBA shell for a RP2040 powered system and would love to have backward compatibility for Arduboy games and a “video card” like this would work great. Don’t know how much more compute there is needed to talk to that display even passing it mono signal.


1 Like

Haha this is all the information I could find myself, I got through that article and I was like YES!

Then got to this “But what do the other signals do – I’m not too sure but we don’t need to worry about them unless you want to drive the LCD yourself.” and was like… that IS what I want to do.

You think there is enough info here to drive it? I mean, the github links to a comparable LCD datasheet maybe I could get a code sample from them?