Computational Gameboy Cartridge [Advanced Concepts Inside]

[Oddly]

I've been talking a lot about assembly and C related stuff in the shoutbox this week and I'm sure at least 4 of you are curious. So, what the jazz am I doing.

Well, I've seen A LOT of DIY Projects on people converting gameboy into rom emulators and stuff by replacing the guts of the raspberry pi, but my project...  it's a little more interesting than that.
Instead of replacing the guts of a gameboy to make an emulator, I'm using a Raspberry Pi Zero to create a Computation Cartridge that will work for GB, GBC, and GBA. This means, all of the original gameboy will be 100% intact, no modifications will be made to the system but the cartridge will allow the gameboy to do a lot of various tasks...

Connect to wifi?
Create a web browser rom for the gameboy?
Gameboy Calculator, Internet Multiplayer play? (as in NetPlay, you can play with someone who is using a rom supported by NetPlay).

You can also run low level operations on it to do various other applications, great tool for development and it will all be done via a gameboy cartridge. Now I know there are A LOT of limitations to this, for example how much memory addresses the gameboy can actually hold and how fast it can actually access that data. But I have a few theories to virtually expand the memory...

So, without further-a-due, the post...

So first thing was first, can I think of a way to make this possible? It starts with a lot of research... spent a good six hours just reading about how the gameboy works, found a good autopsy video on youtube explaining how the memory of the system worked, but I needed more in depth than that so I did some reasearch on a few sites. I needed to know how The pins worked and how the CPU talked to the cartridge.



Got plenty of data on that, found out about the different chips on the cartridge and what memory addresses accessed the ROM and SRAM on a cartridge.... I had the idea, maybe I can replace the the rom chip without whatever output data i wanted from the pie so the CPU would just keep reading instructions as I entered them in... Problem was, there was more than just the ROM chip on the cartridge the accessed memory. There was also the SRAM chip, which managed various save datas, this chip is powered by the Infamous Coin Cell Battery that always dies when you make a pretty dope save and the games all "nah bruh, you can't have this"... figured that should go too, i have a storage location on the drive where I can load and save binary information to and from...

|The other Issue was the ROM and SRAM were being controlled by another chip called the MBC or the Memory Bank Controller. Basically, this chip just said if the address is in this range, go to this bank in the ROM or SRAM and if the pin, SC was set to LOW (or 0), grab data from the SRAM... yeah that had to go, but it's function was ABSOLUTELY ESSENTIAL to the memory mapping features of the gameboy... so it was time to do some planning....



Eventually I came to find how the memory addresses worked in the Gameboy and how the addresses were being received, which is where I designed the above concept map. The Gameboy cartridge has 16 pins for a, you guessed it, 16-bit memory address. each pin representing one bit (translated in gbAsm (my short acronym for Gameboy Assembly Language) to Hexidecimal, yay) of the 16-bit address. These pins are referred to as A0-A15 pins. There are also a series of 8 pins next to these address pins referred to as D0-D7 pins. These pins are what memory you're reading/writing. 8pins = 8 bits, 8 bits = 1 byte. That's right, the game reads and writes instructions to and from ROM one byte at a time... lucky me...

So what's all that hubba bubba from above?
Well, that my friends is the software outline for a virtualized version of the MBC chip. I call it a vMBC for Virtual Memory Bank Controller, However it is commonly referred to as an MMU, or Memory Mangement Unit. Which will now be broken up into a separate reply. because I don't know if there's a post size limit.


 

[Oddly]

This is how the vMBC Will work:
First of all this is written in C++ where using Memory Pointers and Iterators is soooo convenient...
The Raspberry Pi Zero has 40 GPIO Pins  (or General purpose Input Output Pins), 25 of these pins are ACTUALLY mappable through C libraries (and a few other languages too) to set values to either High, or low. They can be both read from, and written to. These pins will be soldered to a few pins on the gameboy cartridge (After it is stripped of all its components).

With these we can Read the Following Pins for the following information
A0-A15, a 16bit memory address the gameboy will be using to access data from it's "chips" is retrieved from this. The gameboy has specific ranges in memory addresses for ROM data. As dummy data, we'll make believe that these address are between the 16bit hexidecimal addresses $C000 AND $DFFF. These 16bit addresses may be converted to int16_t variables in C++, or 16bit Integer variables, also called shorts in other languages.

Now, the raspberry pi is a 64bit system and contains 64bit hexidecimal memory addresses, and obviously its memory addresses won't be constant and DEFINATELY won't use the same addresses as the gameboy, but that's okay, that's what iterators are for.

If you don't know what an iterator is, this concept is basically: if I have an address, 164, and this is the start of an array of bytes, that 164 is only a pointer to the first byte. If I wanna get an 64bit (4byte) integer out of it, I have to get bytes 164, 165, 166, and 167 as well. Well iterators are simply 164 + 2 will get you the third byte in that array. It's kinda like simple mathematics with memory addresses.

This is beneficial because we can calculate the offset of whatever memory the gameboy is trying to grab, and map it to wherever our memory is on the vMBC.
Let's say we want to load ROM data into our system. We would have to take a ROM file and map it to the same RAM that the Gameboy is accessing from the vMBC. So to do this, we use a simple function in C known as a malloc. or Memory Allocate. This function (malloc(size_t size)) creates an array of reserved memory on our application's heap of whatever size we specify in its argument, The function also returns a void pointer to the first byte of our newly reserved date (which we can reinterpret as a char which is a plain old data type in C++ that is only one byte large. there is no byte object in C++).

Now, we have the memory address and the reserved space, so we load all the binary data from (let's use a dummy rom file) SuperMarioLand.gb into our newly reserved memory space. So now, the first byte of memory from that gb file is the same as our char pointer object that malloc returned. We now have ROM data in RAM, with the address to that data, just as a gameboy would read it.

Now let's address our problem defined earlier, mapping the gameboy's addresses to the Raspberry Pi's Addresses.
So, as stated earlier in our dummy example data, our memory for our ROM on the Gameboy's address, which i will now refer to as a gbAddr, is between addresses $C000 AND $DFFF. In our system, let's say the first byte of the memory we Malloc'd earlier is addressed #00FF00EE in our Raspberry's pi RAM. This now means that the address $C000 in rom is #00FF00EE in the raspberry pi. Cool right?

Well remember the iterators? Let's say our gameboy is trying to access the address $C020. We would calculate the offset where $C000 is equal to the 0th byte in ROM addesses. so $C020 - $C000 = 20.
So that is the 20th byte in ROM data. Let's grab that from our RAM
#00FF00EE + 20 = 20th byte from the loaded .gb in RAM.

Now we return this value by writing to the D0-D7 where the gameboy's CPU will do whatever it needed to do with the requested data, such as load it into a register, add on it, whatever.

This is how the Gameboy Computation Cartridge will work.
Hope you learned something.

For anyone interested in getting them edumatcations:

 

[or3o]

Could you start with a flash cart? 

[Oddly]

No, this is for a very specific development kit i'm creating which will also include a special type of emulator that allows network communications and a gameboy game design kit in a custom written development language