7400 Logic Calculator: Breadboarding

In April, I made a lot of progress on my 7400 Logic Calculator project. The last month or so I have been focusing on other projects (which I will post about soon), so I wanted to make a post about this project while everything is relatively fresh on my mind, since I might put the project on hold for a while.

Since the last post about this project, I have made two major design changes. First, I did exchange the 74HC574 octal latch I was using as a register for 74HC670s as I mentioned in that post. The one latch I was using for the ALU is not enough since I need a second register to hold the second operand for the ALU and a third to hold the flags like carry from the ALU. Since the latches come in DIP20, three of them takes up about as much room as four 74HC670s in DIP16, which give a total of eight 8 bit registers. This will give way more flexibility for memory pointers and other uses that will speed things up and make programming easier.

The second change is to the program counters. Instead of saving a copy of the PC in its own register so that it can be reloaded later, the PC is loaded directly from the data bus. This is a little less convenient but became necessary when I thought through how to handle indirect memory addresses. The address latches for the SRAM are loaded from the PC, which is an idea I borrowed from the CSCvon8 project. It is also a minimal design and with less than 20 chips is a lot smaller than my design. One neat thing I found out about corresponding with the owner of that project is the 74LS593 counter which saves room since it is an 8 bit counter in one chip (most others I have found are 4 bit). This is the only 8 bit counter with load inputs that comes in HC. I ended up not using the chip since it doesn't have separate input and output lines, but I did order four of them from China while I was considering it. They look very new and shiny and are marked simply "JAPAN" rather than "ST," which is the only company I could find that ever manufactured them, so they are probably fakes. One day I will test them out and see for sure.

To save room, I decided to use only one EEPROM to generate control signals. The 8 outputs of the chip are not nearly enough for even a simple system, so I decided to use the bits of the instruction itself to select which of the four possible registers to enable from each pair of 74HC670s. This limits me to using only two registers per instruction and means I cannot access registers in the same pair in the same instruction. I don't think this will be too hard to work around. One thing I could do, for example, would be to set aside a register that is only used in macros for temporary values and never by code explicitly. Instructions that access registers in the same pair would be replaced by macros that copy one of the values to the opposite pair temporarily before the instruction. This shadow register could also be used for things like indirect address calculations.

Bus access within the processor is controlled by one 74HC138 demultiplexer that selects an output and one that selects an input. The bits driving the selections are encoded directly in the program itself. This wastes a lot of program space, but it eliminates one EEPROM. Since all program data coming out of the EEPROM, including instructions and constant data, drives the demultiplexers, devices are selected to read and write at random until the program reaches the selection data. This doesn't hurt anything since the input demultiplexer has a master enable driven by the control signal EEPROM that prevents anything from being written until the correct value for driving the demultiplexers is present. One tricky thing with this setup was figuring out how to read constants from the program, since the program EEPROM can't simultaneous supply the constant and select a destination for it. To fix this, every value from the program EEPROM is saved into a latch on the falling edge of the signal that increments the PC on the rising edge. By keeping this signal high, I can output the previous byte that came from the EEPROM on the bus using the latch, which is the constant I need, while the current value from the EEPROM selects that latch to drive the bus. These are the select signals I have so far:

Bus outputs	Bus inputs
Registers R0-R3 Registers R4-R7 ROM constant RAM data Keypad latch ALU (none) (none)	Registers R0-R3 Registers R4-R7 RAM address low RAM address high Program counter RAM data LCD (none)

There are still a few free lines, which I might end up needing.

The breadboarding itself has been fun. After I saw Ben Eater's videos about breadboard computers, I bought the same hookup wire and breadboards he recommended. Amazingly, the voltage on my supply line drops from 3.31 volts to 3.27 volts at the point furthest from the supply with the most connections in between. On other projects, the voltage has dropped way more than that on just one breadboard. The most convenient thing has been to use very long wires which looks completely different from the neat wires Ben Eater uses. Because my wires are so long, I end up unplugging a bunch of them every time I unplug the program or microcode ROM, so I soldered some protoboard to keep the microcode ROM about 6 inches off the board. I'm sure this will limit my top speed but it makes development a lot easier. It took a lot longer than I expected to make the standoff, so I just ran jumper wires to the program ROM so I could lay it on the table next to the breadboard.