Oh by the way I have found out that an ESP32 will run on a coin cell, even with the wifi on, even though on a 2032 it only lasts a few minutes. With the radio off should be an OK power consumption.
Id look into the esp32-pico-d4
The short run time would probably be due to the high impulse currents drawn when using wifi, which absolutely kills the 2032 making efficient energy extraction impossible (you are probably only getting <30% or so of the total available capacity). Most coin cell datasheets only specify current draws of around 5-20mA or so depending on cell capacity for the express reason of wasting most of the energy as heat dissipated by sourcing high currents through the cell’s relatively high internal resistance.
1 Like
It looks like it would probably be ok piggy backing off the GBA 2xAA even with wifi on (quickly to transfer a game) but would still be ok with the radio off.
But actually, the more I realize it, something that has wifi really should have a rechargeable battery…
Should be plenty fast enough, probably even could figure out audio emulation at that speed.
One of the other limitations that I can think of is how fast the gameboy could display the bitmap. From what I was reading up the bitmap mode is a lot slower than displaying it tile mode
Where did you read that?
I can find a reference (for a GBA emulator written in Rust) that says mode 4 is slower than mode 3 because it has to read a 16-bit value, modify that and then write it back because it can’t just modify an 8-bit value, but I can’t find anything that outright says “bitmap modes are slower than tiled modes”.
" The reason for this is that bitmaps are a lot easier to come to terms with than tilemaps. And this is the only reason. The truth of the matter is that the bitmap modes are just too slow to be used for most conventional GBA games."
https://www.coranac.com/tonc/text/bitmaps.htm
Looking at it further though that probably just relates to running the full game on the gba possessor and not what we are trying to do.
I believe the python circuit dmg cartridge uses tile mode because that is the only option available for the dmg and it might be easier to do a small conversion for the gba to run tile mode instead of fully re-writing the gba version
If we’re talking about shoving an ATmega32u4 in a cartridge then it won’t matter because the GBA code will be doing little other than copying data from the cartridge to the framebuffer (and a little bit of input, and maybe some sound).
I’m not so sure about the GB, but for the GBA, bitmap mode is supposedly good enough for Doom in full colour, so throwing 128x64 1-bit frames at it shouldn’t be too much of a problem.
Trying to reimplement Arduboy games as GB or GBA games would be a different story of course…
That’s true.
So is uXe using the fpga to take a spi style display output and convert it to a bitmap and then convert that to the correct block segments for the GBA to write it to the display?
Just trying to grasp my head around the best way to approach this
The closest comment I could find to describing what the process is:
So I would assume that means that the GBA is mostly just being a dumb data forwarding machine.
If you want to notify someone (e.g. @uXe) you have to put a @ in front of thier username,
or you can directly reply to one of their comments (by using the Reply in the comment rather than the one at the bottom of the thread),
or you can quote their comment (by highlighting a section and pressing ‘quote’).
The code running on the FPGA is here, and shouldn’t be too difficult to follow… it reads in and stores the video / sound data being sent by the microcontroller, and also manages the address / data bus on the cartridge port - depending on which address the GBA wants to read from it takes a few different actions:
-
for the lowest address range, it returns ‘ROM’ data for the program that needs to run on the GBA side
-
for the next address range it returns pixel data, which the GBA then copies directly to VRAM using DMA
-
another special address range actually has the GBA’s button inputs encoded into the address, in this case the FPGA mirrors these button states on pins connected to the microcontroller, and then returns sound data that had been received earlier from the microcontroller
Here are some well-reasoned arguments why you shouldn’t try to do this using a Pi:
and here are some projects using a Pi to act as a sort-of NES cartridge:
…so, maybe start there?
2 Likes
Perfect! Thank you so much for all of the information
1 Like
Nope - @bateske may decide to manufacture them at some point? I was talking with @sjm4306 a while back too and he was fairly confident about possibly being able compactify the design, to fit the microcontroller + FPGA onto a 4-layer board that could fit inside a GBA cartridge enclosure?
@uXe that would be really cool. If I wanted to follow along at home what fpga dev board should I get? I already have a gameboy with the cart de-soldered so I can just connect wires straight to a board
Well, I prototyped this using a BlackIce II, but they aren’t selling those any more - you could get the new model, the BlackIce Mx:
or you could get Lattice’s own breakout board:
http://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/iCE40HX8KBreakoutBoard
Hi! Just stumbled across this and thought I’d revive.
It doesn’t emulate a fixed ROM. CircuitPython queues up GameBoy instructions to modify the pixel pipeline and sound registers. No logic happens on the gameboy CPU.
I did get it to being able to play a version of Pico-8 celeste I have. It worked on GB and GBC. Unfortunately it had some timing issues which would cause the gameboy to crash. I’ll need a logic analyzer to do a good job debugging the issue or give up and use an FPGA to buffer the commands out. :-/
I’ve been following cubic style I think he has his programmable gameboy cart released. I can’t read japanese though. I’ll post up some relevant tweets later.