Arduino Gameboy Cartridge?

So @uXe you did it!?! :open_mouth:

I did get the FPGA ‘soft core’ to run Arduino code, yes - but only in a very experimental / minimal way so far… there is some work being done on improving the implementation, could also be beneficial to jump to one of the already supported boards that can already emulate a beefier Arduino:

Should be receiving my GBA breakout cart PCBs from China in a few days, and can finally pick-up where I left off with this Arduboy-on-a-GBA-cart idea!


Just to say, I can’t help with this because I have no idea how. But I love this idea and I think its great you are doing it!


I don’t know what this is because I can’t read japanese, but it looks like something:


出ます! - either ‘to announce’, ‘to appear’ or ‘to come out’.
(This is a really tricky verb with about 20 different meanings.)

技術書典 - technical book celebration (or possibly technical book law)

So I’m pressuming that part means either:

  • “It’s coming out! Documentation manual.”
  • “Announcement! Documentation manual.”

Technical manual 6 | average/common/ordinary

Result situation : winning/being selected

Constructing a Game Boy cardtridge
(More literally a Game Boy “casette”.)


Distribute information

I recommend
It has a ‘draw kanji’ feature and ‘find kanji by radical’ feature.

I asked, and it is a book about a flash cart, it seems to be running a bluetooth chipset, I asked for more info but didn’t get any. But basically I think it is exactly our concept.

1 Like

…breakout PCBs finally arrived on the slow boat from China, and just getting the initial GBA cart emulation running has been a lot more challenging than I had expected - but after several painful days I have thoroughly learned a valuable lesson: “Don’t do asynchronous edge detection, ever. Remember: Keep It Synchronous, Stupid.” (from

Here is the code so far, that lets the FPGA act as a GBA cart (needs further optimisation):

…next comes talking to the Arduino! :wink:


Wow awesome fire demo I used to think these kinds of procedural animations were the coolest thing ever back in the days of VGA graphics.

I think someone mentioned even if an FPGA is needed that an MCU might directly be able to talk to the GBA?

Either way this is such amazing work!

EDIT: Does it have sound and button input functions?


The GBA can act as an SPI master or slave through the multiplayer serial cable connector. 8bits or 32bits transfers at 256KHz or 2Mbit/s

If the GBA acts as slave the transfer clock is provided by the other device.

It’s also possible to use the serial connector as 4 GPIOs and bit-bang stuff in or out with the GBA CPU directly.

You can even boot the GBA off the serial port, without a game cartridge. Then start sending SPI data…

1 Like

That is so freaking interesting!!!

True - the same site warns to only expect ‘stable’ communication at 256Kbit/s though, and having the Arduboy in a self-contained cart also feels nicer than something hanging off the link port? :slight_smile:

Have made good progress this weekend (it’s actually a little too fast(!) because I’m using an STM32 here to avoid the need to level-shift):


Those are just Nintendo’s recommendations because of cheap 3rd party crappy or too long link cables & dirty connectors.

I’ve done 2Mbit/s over a 3 foot long link cable just fine but the 2Mbit/s mode is intended for accessories without a cable. So if it’s short enough it’ll work. We can probably go higher than 2Mbit/s if the CPU is watching the IO port in a tight loop. Interrupt latency is pretty high on the GBA.

If the GBA is set to 32bits slave, the MCU master can (has to) send 4x 8bits transfers before the GBA gets an interrupt / IO register shows that the data transfer is done.

Which can help deal with the amount of data but the MCU code has to be modified to always do 4 transfers.

…buttons are GO!


sound is next…


…it does now :wink:


Amazing! Is there a way to get my hands on one of these?

Code is here:

Has been quite a road just to get this far, coding for three separate platforms (GBA / FPGA / STM32) to make it all work together! :sweat_smile:

The way the sound works for now is by passing a 16-bit ‘word’ to the GBA through the Arduboy2 display() function to control one of the GBA’s square-wave channels - the upper 4 bits of the word are for volume / mute, and the lower 11 bits are for frequency. The GBA button states are encoded into the address when this word is requested - so, the FPGA always returns the same sound data for any request in this address range, but captures the button states out of the lower address bits and sends them to 6 input pins on the STM32.

Ended up using a 3.3V STM32 because I was having issues detecting edges properly when shifting down from 5V into the FPGA… so, the Arduboy2 library is stripped back quite a lot to make it run on a different microcontroller - but this is going to be necessary anyway if the plan for the cart is to use some IoT microcontroller?

Arduboy2 has become very platform-specific and ‘unportable’ though… this section of the Sprites function will need to be translated from AVR assembly before a lot of games will work:


Going to depend if this actually materialises into a design that gets produced?



For a quick port, you can use the SpritesB class code in place of the Sprrites class code. SpritesB has no assembly code.


@uXe, be careful if the size of int isn’t 16 on your platform though.

Both Sprites and SpritesB have a buffer overrun bug that only becomes aparent when int is larger than 16 bits.

I had to fix this for my port of Arduboy2 to the Pokitto (which is still a WIP):

1 Like

Thanks for the tips @MLXXXp & @Pharap! Sprites working now (and a quick demo of switching the scaling on/off using the shoulder buttons):