Arduino Gameboy Cartridge?

The hardware approach is different, but the concept of using scratch to dev on the GBA is the same.

I just pinged about our project, it would great to have some support of course!

Looks like the module is too big to fit in the case, meaning if we did this project then it would have to get FCC approval which is kind of spendy.

Or just do what the everdrive did, use an oversize case?

1 Like

…if the idea is to take a traditional GameBoy / GBA cart and just add in wireless, then talk to these guys:

No the idea is to add an IOT development platform to a GBA cart, what they did was just put a radio between them. The idea is the GBA could boot up into an online game repo, or the game could be massively multiplayer, or it could be a web browser.

The ESP is just a nice dev target also because it has two 240mhz cores, which is a significant bump over one 16mhz processor.

1 Like

I’m not 100% sure what that board does but from what I gather it’s just a card reader writer with multiboot.
I’m not really sure why they went for a cart port considering you can dump from the GBA’s serial port over multiboot and Arduino. Maybe it loads carts in emulator’s?
It’s been a long long time since I looked at anything GBA but still have my old flash2advance a k1 and some sacrificial hardware if you need anyone to tests anything on hardware.

In that case I think you want 0.5333…


240 / 128 = 1.875
1 / 1.875 = 0.53333…

Of course, 0.533… isn’t 100% representable in SQ7x8.
The closest you can get is either 0x0088 (0.53125) or 0x0089 (0.53515625).


1 / 256 = 0.00390625
0.533… / 0.00390625 = 136.533…
136 -> 0x88, 137 -> 0x89

0x0088 (0.53125) gives you ~240


1 / 0.53125 = 1.8823529411764705882352941176471
128 * 1.8686… = 240.94117647058823529411764705882

0x0089 (0.53515625) gives you ~239


1 / 0.5351… = 1.8686131386861313868613138686131
128 * 1.8686… = 239.18248175182481751824817518248

So assuming the value gets truncated then 0x0088 seems like the better bet.

// (I'm assuming the GBA is little endian)

namespace Registers
	namespace Background2
		volatile std::uint8_t * SourceXLow = reinterpret_cast<volatile std::uint8_t *>(0x4000020);
		volatile std::uint8_t * SourceXHigh = reinterpret_cast<volatile std::uint8_t *>(0x4000021);
		volatile std::uint16_t * SourceX = reinterpret_cast<volatile std::uint16_t *>(0x4000020);
		volatile std::uint8_t * SourceYLow = reinterpret_cast<volatile std::uint8_t *>(0x4000026);
		volatile std::uint8_t * SourceYHigh = reinterpret_cast<volatile std::uint8_t *>(0x4000027);
		volatile std::uint16_t * SourceY = reinterpret_cast<volatile std::uint16_t *>(0x4000026);

void Scale2()
	using namespace Registers::Background2;

	*SourceXLow = 0x88;
	*SourceXHigh = 0x00
	*SourceYLow = 0x88;
	*SourceYHigh = 0x00;

(It’s weird how understanding fixed points suddenly comes in handy :P)

Reminds me of the Gameshark and Action Replay.

Is this being discussed as just a hobby sideproject or as an actual business project?

1 Like

I just loaded a 128x64 jpg its super tiny


Screen resolution is like some kind of a curse.

1 Like

0x0089 was the magic number, thanks again! :slight_smile:


@Keyboard_Camper here’s a full-screen image test ROM you could try on hardware?

image.gba.pdf (32 KB) (remove the .pdf) :roll_eyes:


…the scaling looks pretty good to me? Here’s the original:


That’s one snazzy test image @uXe :smiley: glad it’s already being used!

I’m no programmer so just wanted to say this sounds like such a neat idea! Quickly skim reading everyones points, has anyone mentioned the great addition to having it on a GBA means it would also (I mean, I’m pretty sure it would) work on DS systems too!

Also as an artist any scaling which makes the pixel art all iffy makes me sad but I know some people like the image to fully fill the screen.

But then again…the pixels, the pixels! Won’t somebody please think of the pixels! :smiley:


1 Like


Good point! We would have compatibility across GBA / GBA SP / GB Micro / DS / DS Lite / (and Game Boy Player for GameCube) :smiley:

For sure, would need to have a button shortcut to turn the scaling on/off!

Which is what the Gameboy Advance did for original GB and GBC games, means everyone is happy :smiley:.


Tested on my k1


I’ll dig out a nds,sp and flashcart for some more pics a bit later today.

Edit: it may be a push but sending video and buttons over multiboot may be possible for a multiplayer solution.
A Arduboy emulator may be better suited though.

@uXe have you looked at the jpeg scaling used in pogo shell it may be possible to add some zooming etc. Or goomba stle borders



Damn these things need a good clean :joy:


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):