Arduino Gameboy Cartridge?

No problem.

If you need any more fixed point magic then let me know.
I also vaguely understand matrices and affine transformations,
and other mysterious voodoo.

I agree.

I’m glad someone mentioned this because it often gets forgotten about.
I happen to have one (along with a platinum GBA and an original DS).

If borders can be made possible and are on the table…

@Vampirics and I might have something that would be of interest.

1 Like

:open_mouth: Now that’s snazzy right there, love the black SP/DS lite to keep in with the 1bit theme! :smiley:

@Pharap Ohhhhhhh I also hope borders could be a possibility, the Super Gameboy for SNES is what I mostly associate childhood memories of playing Gameboy with. (It’s why black and white is what my memory of game boy sprites are, instead of the olive green of the original DMG system haha!)


Oh I forgot the k1 also does composit 640x480 and 480x320

I don’t have any Gamecubes to hand anymore but I would have :wink:

1 Like

It’d be possible to do a fully compatible Arduboy-on-a-cart for the 8bit Game Boys but it’ll need an FPGA to be a pretend SPI OLED display, reorganise the OLED data to GB tile format, and offer it as ROM data to the GB CPU.

The FPGA also need to contain a small ROM program for the GB CPU to boot, init the display & audio and copy data back and forth. I’m assuming the GB ROM can be small enough to be contained into the FPGA to save on space/chip count and cost. Otherwise just add a ROM.

ATmega32U4 -> SPI -> FPGA Graphic capture -> ROM bus -> GB (on vblank) -> Display
ATmega32U4 -> PC6 & PC7 -> FPGA Conversion (00->10, 01->11, 10->00, 11->10) -> resistors “mixer” -> Vin pin (audio in)

Gamepad -> GB (on vblank) -> ROM bus -> FPGA latching -> PF7,6,5,4 & PB4 & PE6 -> ATmega32U4

The GB’s cpu can read the same address and get different data from the FPGA on each reads so the CPU doesn’t have to increment it’s read pointer, only the write-to-screen pointer. Which makes the CPU’s job a lot easier.

The FPGA translate the display pixels to GB tile data and the GB CPU just dumps them to the display memory.

The Vin pin on the cartridge connector allows audio feed from the cart

The FPGA might need an extra transistor to hold the GB’s /RST low while it boots if it can’t boot fast enough to provide the ROM. Not an issue if an actual ROM chip is used.

Put the LEDs and the USB connector right on the cartridge.

Now we got an Arduboy with an unreadable screen (original DMG with no backlight and terrible ghosting) and consumes ~10x as much power. :smiley:

I think this is why the idea trended towards a device that would be compatible with arduboy but would be distinct from it. You should totally check out for fun GB passthrough.

1 Like

You could try implementing the Arduino on the FPGA as well, and then you’d be down to using only the one chip! :smile:

At that point you might as well take the GameBoy CPU out of the equation too and just control the LCD / buttons yourself - I did that and all it took was an ATmega328:

…a fast / powerful enough microcontroller could do the job of the FPGA too though, I made an Arduboy-on-a-cart for the NES using just an Arduino Mega and some dual-port RAM (depends on how ‘fully compatible’ you want it to be though I guess):


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: