Arduboy 'Classic'!

Wow!! Thats so cool! I had no idea it was so easy to find these cases.

And you are right about Seeed being the producer for Genuino which was one of the factors for selecting them as our manufacturer.

Finally found the time to try the shorter headers today, and all systems are GO! :grinning:

What a great feeling to go from thinking “wouldn’t that be cool” - to making it happen and holding it in your hands! :grin:


With that many pixels the CPU starts to become an issue for some applications. Just do some simple math. You have 16 or 20 million cycles per second… but now you also have 160x144x80(fps), which is around 1.8 million pixels you have to push every second (assuming full screen scrolling, etc). Obviously having a dedicated chip for just graphics is going to go a long ways, but you’re starting to get to some pretty big numbers here.

Would love to see something like a megaman demo running on this at full 160x144 and see what FPS is achievable.

Once we go fullscreen, things will start running slower than 80 FPS just because there will be extra instructions needed on the Arduino Nano for decision making on pixels outside of the current 128x64 ‘active area’.

I would love to see a fullscreen demo running too - have just been too snowed under with work and the holidays to sit down and code!

I do have the 8K FIFO in place now though, so if you wanted to get something up and running for the Arduino Micro that could directly render out some kind of animation or something from PROGMEM in 2,880 byte frames (144 lines of 20 horizontally oriented bytes) then I’d be happy to run it!

How is this rendering happening? The Micro grabs data off the FIFO, but how is it putting it onto the Gameboy screen? What does that API and timing look like? That itself might be the limiting factor if it’s too slow.

And what is the interface/timing on getting into the FIFO? Looks like FIFO is 9 bit parallel access (in and out), but what is the timing on that? I assume you have to toggle a pin to advance the read/write pointer? I see it says 12ns… ok, that’s actually crazy fast… faster than we could push/pull. So the FIFO isn’t the limiting factor.

Sorry if I’m causing some confusion here - the Arduino Nano is the LCD controller, the Arduino Micro is where the Arduboy sketches are running.

What I meant by directly rendering from PROGMEM is that the Micro does not have enough RAM for a 2,880 byte frame buffer, so we would need to bypass using that frame buffer and render directly (like the Squario sketch does). Retrieving the pixel data from PROGMEM instead, or even just generating it on the fly?

As long as there is a loop included that will iterate through those 2,880 bytes one at a time in the correct order then I’ll be able to make it work with the FIFO and the Arduino-Nano-LCD-controller…

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?