Arduino Gameboy Cartridge?


#21

I’d fancy a cart like that too. Could also use it with Super Game Boy as a console too :slight_smile:

I think you mean the other way around. You can’t slot in a GBA cart into a DMG.

I see you do that. I think the firmware could be really minimalistic maybe even sotre in the fpga. (atmega loads config from SPI flash into FPGA, SPI flash is there for multiple games ofcourse :slight_smile: )


(Kevin) #22

Here is my professional infographic. Please let me know what you think.


(Kea Oliver) #23

I actually love this Idea, The GBA is a great device and if you could make this work ESPECIALLY if it could run games of roughly equivalent to GBA quality (colour and sound wise) It would be incredible. Even if it was restricted to arduboy/Pico8(love the pico8 idea) I think it would be an incredibly cool device.


(Shawn) #24

Yes I love the idea that the arduboy is coming full circle. It was inspired by the gameboy and finally can combine and be playable on an oem gameboy!


(Kea Oliver) #25

By the way for a while an FPGA for GBA was available called the xPort. Discontinued a while ago and mostly used for robotics and stuff from what i can google up.


(Kevin) #26


(Scott R) #27

Ardunya and four swords- Perfect reason to dig out devkitppc and my wii stuff.

It’s been awhile since I touched a GBA I remember DMG doesn’t look that great on a GBA it was always an issue for Goomba causing a tiny image with borders.


#28

GBA supports hardware scaling of the bitmap, so will have to see what that would look like:

http://problemkaputt.de/gbatek.htm#lcdiobgrotationscaling

…or, could always have button shortcuts to turn scaling on/off and to adjust the position of the scaled image left/right to decide which 16 pixels are lost?


(Kevin) #29

Yeah those are solutions for legacy games. I might lean into a Kylo Ren philosophy on future development and just keep Arduboy on 1 bit and whatever resolution you want.

I mean lets be real once we have full color, how many people will elect to work in 1 bit, of course they are out there but this is a new product. I feel like it is a way to answer everyone who have asked for a full color arduboy. I didn’t want to do that because it would compete with gameboy homebrew. But merging with it is a whole new ball game. Become the homebrew.


(Kea Oliver) #30

Not only are you merging with it you are making a way to make it easier, sure its not EXACTLY gba as such, but it will still be sweet. Honestly I would probably go for whatever resolution, PICO-8 is 128x128 and that would fit in the middle allright.

Bit of an edit but I think you should think of this as a new product, dont let too many previous things effect it.


#31

its 240 RGB pixels thats 720 sub pixels. You could draw pixels as 5 sub pixels. Only the outer pixels will have some color bleeding.


#32

Update - have got the GBA-side firmware working to the point of reading in a 128x64 Arduboy sized image from the cartridge port and using DMA to write it to VRAM in bitmap mode once every V-Blank:

…next is puzzling out how to use these registers to scale it up to 240x128:

http://www.komodoopenlab.com/pub/mirroredpages/gbaspecs/cowbitespec.html#Background%20Rotation/Scaling%20Regi

http://problemkaputt.de/gbatek.htm#lcdiobgrotationscaling


(Pharap) #33

Oh look, fixed points. :P

If I’m reading this right then that means what you want is something like this:

// (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 = 0x80;
	*SourceXHigh = 0x00
	
	*SourceYLow = 0x80;
	*SourceYHigh = 0x00;
}

Because 0x0080 in SQ7x8 is 0.5 and 1 / 0.5 is 2.


(Kevin) #34

online app store on the device


(Kea Oliver) #35

Some interesting ideas, I would hope for the ability to program via a few methods though. I would be wary of feature creep when designing of course.


(Kevin) #36

This is the most simple solution, just plug an ESP32 into a GBA boom done. The rest is software, you could program it any number of ways.


(Kea Oliver) #37

Is the idea to make use of the GBAs processor etc (the esp32 acting like a coprocessor) or just as a pass through?


(Kevin) #38

Yeah correct, I mean this is @uXe design but the GBA processor would be just displaying whatever comes in from the bitmap mode and outputting it to the screen. I’m not sure how the sound is sent through the interface but the generation would also be handled by the GBA processor, as well as the button inputs.


#39

Genius! :grinning:

But, we don’t want 2x scaling on the X-Axis, because there are only 240 horizontal pixels - what we need is ‘some fraction of 2x scaling’? To turn 128 horizontal pixels into 240 (yet to be seen how good or bad it will look…)

GBA2x


#40

…have seen some mention of this on Twitter:

https://translate.google.com.au/translate?sl=ja&tl=en&u=https%3A%2F%2Fcubic-style.jp%2Frpa_exp%2F

Looks great! But, there is no Arduino-compatible ‘co-processor’ type thing in the equation, just traditional GBA flash carts and GBA tool-chain, but with the bonus of the Pi being able to read / write carts and act as a man-in-the-middle talking to the GBA’s link port using multiboot?