In addition to a simple CPU with a 4-bit data bus and a 12-bit address bus, the HRRG will also boast ROM, RAM, and I/O ports. Furthermore, an emulator will allow users to play with the HRRG in the virtual world before undertaking a physical implementation.
As you may or may not know, my chum, Joe Farr, and I are currently in the process of designing and building the Maxfield-Farr 4-bit HRRG Computer. I’ve written about this previously on EEWeb.com (see Index of HRRG Articles), but — since I only recently started this Cool Beans blog on my own website — I thought it might be worth our time to briefly recap things for new readers.
Why the term HRRG? Well, the beast is named in honor of British cartoonist and illustrator William Heath Robinson (1872-1944) and his American counterpart Reuben Lucius Goldberg (1883-1970). Robinson and Goldberg were both famous for creating illustrations of machines that were intended to perform relatively simple tasks, but whose implementations were incredibly complex such that they performed their tasks in exceedingly convoluted and indirect ways. As we will come to see, the HRRG is nothing if not convoluted.
The overall idea is to create a simple central processing unit (CPU) with a 4-bit data bus and a 12-bit address bus. We will also have read-only memory (ROM) and random-access memory (RAM), along with input, output, and bi-directional ports (we can have multiple blocks of memory and multiple ports).
In future columns, we are going to design everything from the switch-level up, which I think will prove to be educational for all of us (especially me, because it’s only when you try to explain something that you realize how little you actually know).
One of the things that will differentiate the HRRG from the herd is that it’s going to be realized as a mixture of implementation technologies, including relays, vacuum tubes, transistors, and simple (“jelly-bean”) integrated circuits, along with mechanical, magnetic, pneumatic, and fluidic logic.
The physical implementation of the 4-bit HRRG computer is going to be presented in a collection of glass-fronted wooden cabinets mounted on a wall. Each cabinet can be implemented in whatever technology we choose.
Joe and I are hoping that our 4-bit HRRG Computer will be of educational interest for schools, universities, hobbyists, and makers. Of course, even I with my boundless enthusiasm realize that it’s going to be difficult to persuade anyone to build an entire HRRG from scratch. Thus, Joe is creating an HRRG Emulator (see Emulators Rule, Simulators Drool).
As we see, the emulator looks like a rack-mount system, where each rack comprises one or more modules. Each module is powered by its own independent program, and all of these programs communicate with each other via a “software backplane.”
The idea is that we will be able to use the emulator to capture and run programs in the virtual world. When we are ready, we can create portions of the computer in the physical world, and then use these real-world functions in conjunction with their virtual cousins. For example, we could have a cabinet containing a single 4-bit word of memory implemented using pneumatic logic, should we so desire.
In recent columns, we discussed how the 4-bit HRRG Computer’s CPU is going to have 16 registers and support 16 instructions (see The Instruction Set and Instruction Set Tradeoffs).
Now, as you can see from the emulator shown above, one way to enter programs is via a switch panel. In this case, we use the 12 address switches to specify a target address in memory, we use the 4 data switches to specify the instruction or data we want to load into that location, and we repeat this over and over again until the program is loaded.
Although capturing and entering programs at this machine code level is painfully slow and prone to error, it’s the way things used to be done, and entering even a small program this way is nothing if not educational because you quickly learn that you don’t want to do it again LOL.
The next step up the programming hierarchy is to define an assembly language, write our programs in this language, and then use an assembler to translate our programs into the machine code that will be run on the computer. In my previous two columns, we first introduced some basic concepts, after which we considered the process involved in developing an assembly language.
And this pretty much brings us up to date. In my next HRRG column, we will look at our assembly language in detail. In the meantime, as always, I welcome your comments, questions, and suggestions.