The long term goal is to implement a simulator for an actual CPU.

I'd be willing to give the class the choice of the following:

• Intel 8080 (ancestor to 8085, simpler in some regards)
• Intel 8085 (relative of the x86 architecture we all know and love– PCs)
• Zilog Z80 (competitor to the 8080/8085. CPU of the Gameboy, coprocessor of Sega Genesis)
• Motorola 6809 (likely ancestor to the M68000 CPUs– Genesis, Amiga, many many things)
• MOS 6502 (Atari 2600, NES)

Don't let actual real world usages (ie video game systems) sway your decision… by building the CPU we won't immediately be able to run ROMs or anything (unless the supporting hardware is also simulated– sound chips, video chips, I/O controllers, etc.) But I wanted to illustrate that each of the mentioned CPUs has a place in the world, even if they've long been bypassed with newer chips.

Each of these are generally 8-bit CPUs. Some may have some 16+ bit characteristics to them (especially in their address bus).

We don't have to implement all of them. But we can implement more than one (in fact I think implementing at least two will ensure enough ongoing tasks for everyone… and of course more will provide even more tasks…). Implementing multiple CPUs might have us naturally fall into sub-groups (each group works on their specific CPU, which is build with the components being constructed by the entire class).

So for long term implementation things, we need to start considering what CPU(s) we are actually looking to implement, and code accordingly.

What I'd recommend is for everyone to take a look at each of these processors (wikipedia should have information on all of them). We're interested in the architecture (#/width/type of registers, address bus, instruction set, etc.)

For some of you, this will be an immediate influx of new material. As you encounter new things, look them up, and ask questions (here, on irc, to me directly, to others in the class, etc.). Try not to get paralyzed by the increase in details… we still have to implement the many components that make up an eventual CPU (remember we need to keep the problem broken up into smaller parts).

Also, there are a few books on Computer Organization / Digital Electronics / Logic in the LAIRbrary… so that is another source of information.

In a nutshell, a CPU is merely a combination of the many components we are building, establishing links between various areas (busses), setting up storage (registers, memory), implementing the execution unit (ability to identify commands, which “activate” circuits of components we're building).

The functioning CPU comes at the end. Right now we're in the midst of implementing its components. But looking up the architecture of a CPU will act as a roadmap, showing you where many of the components we're about to get to (registers, memory, and functionality we can perform on them) will fit in.

Don't be afraid, be excited.

Those who were in my Data Structures class got some hands-on experience with Makefiles. Our backgammon project had a rather integrated Makefile that facilitated the building of parts/all of the project. Those who weren't, you get to join them in enlightenment.

Makefiles are an important development tool, which we can stand to benefit from in our CPU simulator project. So especially the people who haven't had extensive exposure to Makefiles, please take a look at the base Makefile.

It is a series of variable definitions (up top), and rules/recipes. What the Makefile does is describe the steps needed to build various pieces, and by giving the appropriate command (running “make” by itself to get a usage menu). You can actually follow the logic needed to build various things (including dependencies– things that need other things built before they can be built).

What I've done is implement the logic to built some of our simulator components– specifically, I put in rules for the AND, OR, and NOT classes that have been built.

If you look in the Makefile, you will see the associated rules for each of those (the main rule, and a debug rule)… additionally, in the “clean:” section, which is used to clear out compiled objects, is logic to call all the various sub-Makefile clean rules throughout the project. Again, I put in the logic for AND, OR, and NOT.

The immediate new tasks that await some lucky volunteers:

• implement the target rule logic for the remaining components (nand, nor, … flip flops, adders, etc.)
• make sure there are the associated debug rules
• update the “help” display as appropriate
• include the appropriate line in the “clean” rule.
• make sure ALL components have their own pertinent Makefile (many do, but not all at this point).

This is a “copy the existing example” type of exercise. Hopefully it will prove to be an effective learning experience (also checking out the smaller Makefiles to see how they tick).

I don't necessarily want just one person to do all this work… I'd like a bunch of people to contribute (but remember, since the base Makefile is just one file, we'll want to do quick edits and commits, to avoid conflicts).

And be sure to ask questions! I've been getting more questions from more people, which is great! But there's still kinks to work out. So go forth and explore, implement, commit, and ask questions!