Last quarter I took a Machine Organization class as part of my required studies at UW. Machine Org deals with how computers (and other machines) translate between voltage changes coming in, to discrete 1’s and 0’s and finally towards maintaining state and running the software and other functions that are asked of them. I like the class a lot, but completely hated the book (I’ll probably get around to reviewing that later). The more I got entrenched in the minutiae, the more exciting it became. I decided to try my hand at building a working Game Boy game in C and/or Assembly, and dumping it to a working cartridge to play on an actual console.
Why Game Boy?
The Game Boy first launched here in the US in 1989. It played Game Boy games via a cartridge system, a 32-pin circuit board held inside a plastic shell. The console itself is made up of an 8-bit Sharp CPU, a 160×144 LCD, and supports 4-bit audio playback. Nintendo has sold various system that play Game Boy games via expansion slots, and I believe I probably own the last one of these devices they made– the Nintendo DS Lite. To argue that the system is well-known is somewhat of an understatement. Supporting a system for 20 years means there are a lot of devices on the market, and potentially a large knowledge base of information out there from the homebrew community. I don’t have a ton of money to spend, so I wanted this to be fairly cost-effective.
The Basics
I knew I was going to at least need the following:
- Nintendo Game Boy
- Gameboy game cartridge (to reverse-engineer)
- Soldering station and tools
- Method of dumping my compiled code to the cartridge in some way.
I hit Ebay and found fairly quickly a working Game Boy Color unit for $17. The Color variant offers the same CPU and instruction set as its predecessor, and offers essentially 15-bit color values within the palette.
Game Boy Color unit.
The display is still not back-lit, so colors are a bit muddy on the device. I have a ton of old Game Boy carts floating around the house to verify the system works, and it does. Surprisingly, it also comes with an IR port which is interesting as well. I’m wondering if I can just IR some type of commands to the unit to put it in a store state, and/or what that looks like. I continue to assume that I’ll have to be storing my program on some type of memory, which leads us to the next section.
EEPROM’s
EEPROM’s are Electronically Erasable Read Only Memory chips. Each Nintendo Game Boy cartridge has on it at least one EERROM where the game’s code is stored and pulled from when the device boots up. EEPROM’s are handy because they allow you to read data stored out of the chip on a bit-by-bit basis, and they can only be erased by a high-intensity blast of UV light or from an input of voltage (typically above the normal amount running through the system). Through some research I found a compatible EEPROM chip that’s still available for sale today: the AMD Am27C256, a 256-Kb EEPROM. I’ve purchased a quantity of 4 from Jameco just in case I toast some. Here is the datasheet, which is also running around the web.
Sample PROM in a breadboard.
IC Programmer / Arduino
With chips in hand, and a rudimentary idea of how I’m supposed to write something to them, I set out to now implement some sort of repeatable reader/writer that I could use to verify the data on a given chip. There are (or were at least) several EEPROM programmers on the market, where you would drop in a chip and send over some binary code via a serial or parallel port to flash onto the device. However, I like using current tools and these days there is nothing quite as awesome as Arduino.
The Arduino platform is described as a prototyping platform. It offers a standard programming language set (Java-based I might add) to control various prototyping boards, typically all powered by an ATMega chipset. There are both analog and digital pins providing ample I/O (input/output) processing, and loads of modules or shields to add new functionality: Ethernet, WiFi, GPS, GPRS, and IR are just some examples. I own an Arduino Uno probably the easiest and most cost-effective board to start out with. However the Uno only offers 14 I/O pins, and the AM27C256 has 28-pins. I would need to grab an expanded Arduino board with more pins to facilitate communication between the chip and the Arduino.
Arduino Mega 2560 board.
I settled on the Arduino Mega 2560 which has 54 I/O pins which is probably overkill for what I want it to do. It also supports an additional feature that I didn’t know I needed until after I received my EEPROM’s– 12v input from an external power supply. Most Arduino units will in 5v from a wall power supply or powered directly from your computer’s USB bus. In PC land I’ve seen typically 3 voltages used all over the place: 12V, 5v, and 3.3v. I mentioned earlier that EEPROM’s can be reprogrammed with voltage, but typically only with an amount of current that the system where it’s embedded could never supply. You’d hate to “burn” your program into the chip, only to have the device its inserted in overload in some way and send an excess of current down a couple of pins and zap your burned in code.
For the AM27C256 you can apply 12v on pin 1 to trigger a programming mode where it’ll store the data that its given. With the Mega board I can do that and still have it supply 5v and 3.3v for the other functions I need (such as reading from the chip).
What next?
I feel like I’ve gathered a lot of components, and I’m ready to start building a functional programmer. But before I do that, I’d really like to read something from an existing, known and working EEPROM. There was a time in my life when my garage probably had a bin full of old circuit boards with loads of chips and EEPROM’s that I could take off. Most of that stuff I tossed years ago (and I’m kicking myself now). I’m off today to visit a store here in Seattle that should have some old electronics gack– I’m hoping my chances are high that I can find some working EEPROM’s and begin to verify that I’m reading these things the right way.
I’m sure I’m going to hit some roadblocks around reading and writing data to the chip as well as issues even getting the code to execute on the Game Boy. I’m trying to work in parallel a bit, but I won’t know what the big hurdles are until I get going. I keep trying to imagine what tools the programmers had in order to test-dump their code right to a Game Boy development device. Info from around this time seems scarce.
Timeline
I’m trying to finish this project before the end of September 2015. I wanted to have some proof that I could take the concepts I learned in my classes and directly apply them to something hands-on, even if the technology is a little old by today’s standards. I plan to tag all the posts with a unique identifier and see how far I can get.
As always, if anyone has any questions or comments please let me know– would be nice to know if anyone out there is kinda geeking out over the same stuff I am.
