A while back, I set out to write a Gameboy emulator in Perl. I had never done an emulator before and had assumed it was a place full of black magic incantations only uttered by the most highly skilled programmers.

I didn't intend to make a full emulator with graphics and sound (there are plenty of Gameboy emulators out there if you want to play real games). I considered getting the CPU and memory working to be a major accomplishment.

First, I needed the specification for the internal workings of the Gameboy. This turned out to be the hardest part. It took some quality time with Google to refine the search query until I got what I was looking for.

After I started implementing the emulator, I realized that it's actually quite easy. The memory can be represented as a large array. Each opcode does something which reads and/or modifies the memory.

I implemented a few opcodes, saw that the whole thing is actualy quite easy, got board, and abandoned the project. Reading various blogs/forum postings from people who wrote complete emulators, it seems that the hardest part is getting sound to work--you have to translate sound from the Gameboy format into the format for your given sound library, which is understandably difficult, especially when your given sound library is DirectSound :)

The first semester was digital logic and small-scale integration. You have lectures and laboratory.

• Learn what a NAND gate does.
• Build AND, OR, NOR, NOT, XOR using only NAND.
• Learn about Karnaugh maps, and logic minimization.
• Build a flip-flop.
• Learn about clock signals.
• See how a small addressable memory circuit works.
• See how multiplexing enables larger address spaces.
• See how to make single-bit and multi-bit adders.
• Learn about Binary-Coded Decimal numbers.
• Learn about data registers, accumulators, stacks.
• Learn about instruction pointer registers.
• Make a state machine using a rudimentary combinatorial logic language.
• Explore the 6502 microprocessor, implemented as only 256 lines in the same logic language.

The whole second semester was learning how to use A, X and Y registers, a stack, page zero addressing, and all of the other opcodes.

What really blew my mind was the synergy: if I wanted to know what an opcode really did, I just read the corresponding line of the "source code" that implemented the microprocessor! We learned the chip-design language, and we could see that each line was just an opcode. Some opcodes took more than one clock to execute, but that was okay, because they took more than one line of source code.

(This also explained to me how someone figured out and published the "missing opcodes" of the 6502. They were just doing the last clock's worth of work for a larger opcode. Sort of like adding a goto label in the middle of a line of a program, then using it.)

I saw today that there's a resurgence of people building Apple I computers (6502, anybody?) just for the sheer enjoyment and education of knowing every circuit in a whole computer intimately. That was one of the last processors that anyone sufficiently interested could really learn and understand inside and out.