I am making https://github.com/konsumer/dkart We definitely have some similar ideas.

I started on the GB side, and my original hardware design was a lot more complicated with a custom PCB, but for now, I am really into just trying to use a cheap ESP32 dev-board with a cart-adapter (just a simple PCB with a spot for SD & ESP32 dev-board pins.) My goal is a mostly software-designed setup on easy-to-assemble & cheap hardware.

You are welcome to use my GB-side menu program for yours. It works by reading page-by-page from SRAM (which the cart will emulate.) I'm still working on ideas, but it shows a splash screen, manages a menu, and makes sounds when you do stuff. Even if you don't use it as-is, it might give you some ideas.

Your cart should emulate these (GB SRAM addresses) if you want to use it as it is :

```

// the page var that GB writes to tell cart what page to serve up

unsigned int* PTR_CURRENT_PAGE = (int*) 0xA000;

// the current ROM to load, from current page

unsigned int* PTR_CURRENT_ROM = (int*) 0xA001;

// the total number of ROMs on SD
unsigned long* PTR_ROM_COUNT = (long*) 0xA002;

// the names (max 20 chars) of the ROMs on current page, in a size-15 array

char* PTR_ROMS = (char*) 0xA010;

```

At first I thought I might use a command-system (save particular data to RAM addresses to trigger things) but I realized that I will know the current ROM that is loaded cart-side, so I can just make the commands more ad-hoc, depending on what cart is loaded. In this case, telling the cart "I chose this ROM from the menu" is just saving the ROM number to `0xA001` (GB SRAM.) Maybe some kind of ROM-header could also tell the cart "I will need these capabilities" so it will be easier for others to use wifi/bluetooth/i2c without changes to the GB-side cart (just add magic to their ROM-header). I think the "manufacturer" & "licensee" field could be used, if we use one that is not already in use. We might also be able to abuse the "title" field (start with 00, then use the other bytes to communicate capabilities.)

All the menu-paging stuff seems a little fiddly, so I might just try to write the whole file-list into a SAV file (SRAM), so I can manage page-loading GB-side. This would allow me to use a single routine for ROM/RAM and it would be easier to debug (read SAV file on computer.) 8 MB should be more than enough room to store the list of filenames & total length. If I use some known-format that I can seek on the GB (20bytes per name, total-count at beginning of list) I should be able to efficiently do all the menu-paging on the GB, and it'd be easier to manage.

I just got started on the cart-side, but maybe we should work together!

Hey, I just had a similar idea and was glad to find this. My idea was to integrate an existing flashcart with an ESP and have a ROM that would talk to the ESP and the ESP would handle only networking and downloading ROMs to the flash.

Is this even possible? Seems simpler than emulating the cartridge on the ESP.

Non-professional opinion, but this looks really, really, really hard.

Surely what would be much, much easier, would be to stick a SRAM chip in there. Wire it up as a simple ROM from the GB's point of view. Then let your ESP program that, at it's own rate.

Then you could use an I2S expander chip and it wouldn't matter if it was slow.

For contention over the SRAM, have the ESP only write to it when the GB hasn't asserted /CS for a while.

To get it all synced up, perhaps on switch-on have the ESP quickly bung as much code into the SRAM as possible? Including a routine for the GBA to run in a loop from it's onboard RAM for a while. This gives you time, if needed, for the ESP to finish writing to the SRAM. Since your GB software controls where it jumps to, it essentially controls the /CS pin to the cart. That could be how you signal to the ESP that it's time to do some more reading and writing of the SRAM.

It shouldn't be too much of a trick to get them synced up like that. AIUI this would be necessary because there's no way to halt the GB's access to cart memory, a cart is always ready for access. So you'd have to take care of that, fortunately you're writing the GB's code!

Now I think... Since on boot the GB will ask for an opcode, 00 is NOP. So your voltage buffer chips might be hacked to provide that at switchon? Lots of NOPs. Use weak pulldowns maybe, and set the buffer to tristate?

Actually I say wire the SRAM up as ROM... except connect the /WR line too, so GB can write back to SRAM, to send messages to the ESP about button presses and things.

Since it'd only be a 32K simple cart, like Alleyway or the like, you wouldn't, AIUI, need an MBC at all.

OR... you could give up, use the Link port (cables still widely sold), and just buy a commercial GB cart that takes software on SD cards. Thank Chinese pirates and CPLDs for that. So then you just have a lovely slow bit-banged serial bus to talk to.

The way you're going, though, trying to emulate a ROM chip, on the fly, live, in software on an ESP that doesn't have enough pins... no insult to you, mate, but if Sprite or CNLohr managed that, I'd be impressed!

I tried not to get angry about this comment. I failed. I'm so not able to accept comments like "try this chip", "use this method instead", "do it like xyz did", "give up" and "you're not one of the chip gods". Sheesh. 

I have a 32Kb cartridge design already. I know where to buy bigger ones as well.

The ESP32 chip has enough pins (def. more than the ESP8266) to emulate a smaller cartridge, you can emulate bigger cartridges with the exact same way the game boy does, write to an address and switch (smaller) banks. That would make it impossible to run "stolen" ROMs, but I wasn't interested in that. The chip itself was fast enough in theory to provide comparable results to the STM32 chip [https://hackaday.com/2014/12/30/game-boy-cartridge-emulator-uses-stm32/]. It was an experiment to see if I can do the same. Turns out I failed on slow setting pins. Talking with SpriteTM about the project on the other days Hackchat he gave me some notes and said it should be possible, but tricky. 

I welcome you to try out your methods and post them here, but please: sometimes it's really not about what you made a chip do, but with what chip you did it. I wanted to see if I can get a one chip - wi-fi cartridge.

Ok. I got the impression from this, that you wanted a Wifi Gameboy, so you could travel around Wifiing things with it, and write interesting stuff for the GB to do nifty Wifi tricks and whatever.

But actually this is, for you, more of an experiment in emulating a ROM chip with a micro. Admittedly a very powerful micro.

So you don't want to know about other methods of achieving the result because in this case, your method really IS the result you desire. That's OK. You should probably have said so though.

Obviously Sprite knows what he's talking about here, and he's not sure if it's possible.  I'd take that as a warning that it's going to be incredibly difficult, frustrating, and might well fail. There's easier ways of achieving your stated aim. But now I know, that's not your real aim.

Fair enough. If you manage to make this work, I'll be in the front row applauding, it will be very impressive. Good luck with it!

@greenaum I've said that in the "the goal" and "choice of hardware" part of the details, but probably should have added it to the description as well. I'm very aware of the difficulties and frustrations it can bring with it and I threw the towel once or twice :) My skill set definitely isn't that good to accomplish what seemed a good and easy idea at first, but I wanted to share it anyway and see if it is possible and if so, how. 

Actually not ;) I've integrated a backlight into my Game Boys. Well in 3 of them.

Looks promising, but isnt it more feasible to use the LINK Port instead of the Cartridge Port for the ESP and write some driver to put on a separate cartridge? For cartridge emulation, you might need some kind of parallel DMA that can output 8 Bit on the ESPs GPIO clocked by the Gameboy to make it work somehow, but I havent found any such feature (did a quicksearch, maybe the datasheet reveals something?)

The closest thing I've came up with through extensive googling is parallel I2S, that's where my hopes are right now.

There is also this: http://hackaday.com/2016/08/21/fly-with-a-game-boy-classic/ - where the game boy communicates over the serial port with the computer, thanks to a custom cartridge. I do like that approach and think it is feasible to go that route. But it would also require two parts, a cartridge AND an ESP dongle on a port that no one builds plugs for anymore. From a hardware aspect it is much easier to do an egde connector on a pcb and wire up the ESP. 

I've added part of my response to the detail section, thank you very much for asking!

The link port is pretty close to SPI.

http://gbdev.gg8.se/wiki/articles/Serial_Data_Transfer_(Link_Cable)

http://www.hardwarebook.info/Game_Boy_Link

www.reinerziegler.de/GBA/GBAlinkport.pdf

I think SD = slave detect

Can you do midi over bluetooth/usb with this. would go down with the chip-tunes crowd if it could just work with modern software without loads of mods.

"not modding" is definitely a key benefit of having everything on the cartridge, so it would probably be possible. But I have no experience with BT nor MIDI over BT... 

How does the Game Boy even Midi? Also over the serial port?

It probably doesn't do MIDI. But the idea is to use the Gameboy as a synthesizer, which you can play with MIDI, e.g. controlled by Cubase from a PC, or even from a MIDI piano keyboard.

Obviously you need a program for this on the Gameboy, maybe it already exists. For the C64 there is Cynthcart. Together with my Kerberos Cartridge it can be used to use the C64 as a MIDI instrument, as demonstrated by a beta-tester of my cartridge here:

inb4 Gameboy online multiplayer!
Also, have you considered using a Gameboy colour instead? Should be much better for light web browsing (especially when it comes to images).

Totally honest: I'm not sure how to do that. I would have to steal the header from a game boy color cartridge and go from there, but for know I'm quite happy if I can get text to work ;)

Gameboy war driving sounds really awesome. Great project! I haven't played around with the esp32 nearly as much as many others on this site, but I agree with your assessment that power consumption may be a concern. Definitely a good application for a lipo retrofit, maybe there's an existing design out there for the GBP so you can focus on the cartridge?

thank you for reading the logs and the kind words :) for now I will probably breadboard something together and work from USB power or an external power supply. Maybe a ton of caps can help, I've seen some designs that actually work with a coin cell, given some 1000uF tantals. But yes, the focus is full on the cartridge.

Oh crap this is really cool. Ever thought of making a cloud rom storage? So connecting the cartridge to a site, then remotely transferring it to the cartridge. Connecting it the cloud and then pushing a button would save the state and upload it. 

I'm still at the "oh crap, I have no idea what I'm doing" stage :)

Right now I'm thinking war driving with a Game Boy, controlling MQTT stuff and browsing http://retro.hackaday.com/  - that kind of stuff. But I will probably start with faking to be the hackaday cartridge I've build in #Game Boy Cartridge plus Programmer project.