Now that’s snazzy right there, love the black SP/DS lite to keep in with the 1bit theme!
@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!)
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.
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.
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 http://www.happydaze.se/wolf/ for fun GB passthrough.
You could try implementing the Arduino on the FPGA as well, and then you’d be down to using only the one chip!
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):
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:
…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 https://www.doulos.com/knowhow/fpga/synchronisation/)
Here is the code so far, that lets the FPGA act as a GBA cart (needs further optimisation):
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.