What makes a good project? In designing SPAM, we had to answer this question in order to attempt to build one. Obviously, it has to work. Also, one might consider extra add-ons and new functionality. These two considerations make or break a project, but they help very little in making design decisions.
We felt that a very important factor in the relative quality of this project would be its size and hardware complexity. In addition, we did not want to be tied to equipment and time available in the lab. With this in mind, we decided to attempt to design the hardware to be sufficient to accomplish the design, but orthogonal, so that very little hardware would be redundant. This enabled us to build our project on two boards (for the mark I, later three for the mark II), using only fifteen controller outputs and fifteen controller inputs, allowing us to use just two EPROMS and a very simple multiplexed input selection design. The microcode tends to be more complicated than for other designs, since it is dealing with less hardware to accomplish the same tasks, but we felt the tradeoff was well worth it, as our facilities made changing and debugging microcode very easy.
As a final note, we would like to point out that we thought quite a bit about our design. Some things may seem strange, unconventional, and different from ideas presented in class or discussions which would accomplish the same thing. This is not because we've got no idea what's going on. It is because we feel that our unconventional ideas will work better, faster, stronger. Thank you for your support.
In general, we did nearly everything together. This was possible mainly because we live in the same run down shack, and therefore communication was simple. All block diagrams and most schematics were a joint effort. Within the actual construction and writing of microcode, there were some blurry labor divisions. Bryan built the controller and the digital to analog circuitry, while Larry built the address controller, the microphone input circuitry, and the other small blocks.
For the microcode, Larry wrote the main event dispatcher and the RING handler, and Bryan wrote the rest. These divisions were pretty much arbitrary, and in no way reflect any particular talents on either of our parts. The main factor was that the assembler for the microcode was an old 6502 assembler that Bryan was familiar with, and Larry had never even heard of.
All in all, we spent almost exactly equal amounts of time on the project, since we invariably worked on it at the same time.
Next: Block Diagram