The ESP32 parts in Arduino are licensed under http://www.apache.org/licenses/LICENSE-2.0, my work will be published under the MIT License (it's in the file section).
The goal
My plan is to achieve a working environment for the ESP32, to handle the requests of the game boy and work with wifi in parallel, so that you can actually use the Game Boy to surf or interact live with the web/wifi. There are many possibilities to take something useful out of it.
Choice of Hardware
Right now I only want to concentrate on one chip and focus on replicating results that are equal to the achievements of dhole [emulating with STM32] or Alex of insidegadgets.com [emulating on Arduino], where dhole managed to emulate not only ROM but also RAM and MBC (memory bank controller) on one chip. I was about to start with an additional Flash or EEPROM and an ATSAMD21 as an MBC, but that would mean programming two firmwares for two chips that I haven't worked with before - plus programming the actual code for the Game Boy side. The first idea was to use an ESP12 module as an MBC, but with only one core to handle WiFi and inputs at that level of speed would have been impossible (IMHO).
Cartridge vs. Link Port
I do like the approach of using the linkport to talk to an ESP12 and think it is feasible to go that route [like flying a drone]. But it would also require two components: an EEPROM 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, so that's another reason to go with a cartridge. You would also need to build and program your own cartridge, like I did on my other project: #Game Boy Cartridge plus Programmer - instead of using an USB ready ESP board in a cartridge form factor.
Choice of IDE
I'm currently using Arduino IDE, I've done a lot with it so far and am a creature of comfort. There are ways to implement features and functions to bypass "crappy" Arduino code. But it's written better then everything I could have come up with and I've heard of good changes that were made to the Arduino code recently. I hate the crappy editor, love sublime. Integration of Arduino into Sublime was always buggy for me. I love just pushing a button to upload code.
Speed of pin toggle
The current way that I use to toggle the pins and also read them is way too slow. As stated [here], the max speed with direct pin toggling through registers is about 4MHz, far from the cpu speed of 240MHz. In comparison the plain olde Arduino with 16MHz CPU has a toggle speed of round about 2.66MHz, when changed through port registers. You can find the ESP32 pin toggle function [here].
Using I2S as parallel input and output bus
Now I'm really leaving the sector of stuff that I'm used to do or comfortable with (I'm a PHP/JS guy in real life). I don't often surf around the latest CPP code written by CNLohr and SpriteTM, but when I do.. well I don't. But I want to work on that cartridge as long as I see there is an option to go on. In comes the code of CNLohr [github link] - and the previously unknown to me parallel I2S bus.
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!