7400 Logic Calculator: One ROM Design - More Ideas

Two years ago, after writing about my ideas for a calculator built from 7400 series logic, I posted a second time about shrinking that from three ROMs to a one-ROM design to save space. Last year, I had more ideas about how to improve the one-ROM design and made a lot of progress on a schematic. Laying everything out showed that there was still a lot to figure out. At that point, I stopped working on the schematic and started working on this blog post but didn't finish. When I came back a few months later, looking back over my notes to remember how the design works inspired me to come up with a separate second design! This posts explains the first design that didn't quite work and the second design that seems to have solved all the pending problems while being much smaller

First Design

The biggest difference in the first design is the register arrangement. Rather than two 74HC670 register file chips driving the address bus of an ALU EEPROM, this design uses two 8-bit latches to drive a single EEPROM used for everything. The two 74HC670s are still on the bus but serve as storage memory rather than driving the EEPROM address directly. The two latches in the new design can each read eight bits from the data bus and drive the address buses of the EEPROM and RAM. This allows data access to those two memories and also serves as the ALU since the single EEPROM fulfills that function as well. This simplifies things a little compared to prior designs since no separate RAM pointer chip is required. Half of each 8-bit latch is connected to the address bus through resistors to act as pull-ups and pull-downs. A separate ALU latch overcomes those values when activated. This allows the two latches to form a 16-bit pointer when the ALU latch is disabled by an instruction and to function as two 4-bit registers when the ALU latch is enabled. One of the big problems to solve in a 4-bit design like this is how to access each nibble of a byte fetched from memory, do calculations on the nibbles, then recombine the nibbles to write them back to memory. This design has the low nibble of one latch and the high nibble of the other latch wired directly to the address bus so those two nibbles are used for ALU operations. This allows access to the high and low nibbles of any byte but also complicates things a bit for instructions like increment or decrement that treat the combined nibbles as a single byte. Another complication is the carry bit which needs to be disabled when not fed to the ALU and annoyingly wastes a whole chip for a single bit.

7400 Logic Calculator: One ROM Design

After finishing the new design for my 7400 Logic Calculator, I continued to think about different ways to build a minimal design that would fit in a calculator body. Watching James Sharman's videos about his breadboard computer got me thinking about eliminating the microcode sequencer ROM, which would save a lot of room. It eventually dawned on me that the ALU ROM could be eliminated too if it was combined with the program ROM. ALU operations then become ROM lookups and can share the same circuitry used for looking up constants which also eliminates chips. Based on this, I came up with a modified design using only 18 chips compared to the other design's 21. Best of all, the whole thing fits into just one 32K EEPROM rather than three.

7400 Logic Calculator: Revisited

In January, I made a post about my 7400 Logic Calculator project coming to an end and my ideas for improving it. After thinking about the project again this past week, a lot of new ideas came to me for fixing most of the problems with the last design. The new design also incorporates a lot of the ideas from the last post. As I explained in another post, my plan is to focus on a short list of projects for 2022, so I decided to document my ideas for the new design rather than restart the project.

Architecture

The new design is a 4-bit architecture rather than an 8-bit architecture like the last version. One thing that complicated my ideas before was trying to figure out how to drive the ALU with a register and another source, latch the ALU output, and write it to the correct place. The new design handles this by using two 74HC670s as 4-bit register sets feeding the ALU directly to avoid the complication of having the ALU on the bus so other sources can drive it. As a result, anything that goes through the ALU needs to be loaded into a register first, which is not a big sacrifice since the two 74HC670s provide eight 4-bit registers. Latching the ALU output also simplifies the design since an instruction only needs to read or write to the ALU but not both in the same instruction. A 74HC574 latch can optionally be trigged to capture the carry bit of the latched ALU output so it can be fed into the next ALU operation.

Other than the ALU and set of four register pairs, there is a 74HC193 counter that supplies the bottom four bits of the address for an 8K SRAM. This register is named X. The next eight bits are supplied by a 74HC574 "RAM pointer." It's a little unconventional to address the memory this way since it splits it into 256 pages of 16 bytes each. However, 16 bytes is the right size for holding floating point numbers, so the memory can be seen as holding 256 objects with the RAM pointer specifying which object. As a bonus, an instruction can trigger the clock input on the X register to count up, saving a few cycles when stepping through memory.

The next part of the system is a 32K EEPROM to hold the program along with four 74HC193 counters to act as the program counter. This is a pretty standard setup. The RAM pointer and X register combo mentioned above drive the EEPROM address through pullups when the program counters are disabled, so constants can be loaded from the program through a 74HC574 latch. Another latch captures instructions from the EEPROM, and a 74HC244 buffer transmits keypad input to the bus. There is also a control signal for an LCD which is connected directly to the output of the two register sets.

7400 Logic Calculator: Project End

After two and a half years of on and off work, I'm ready to end this project. Unfortunately, I got distracted by other things and never got close to finishing the project. When I last worked on it, the calculator could step through program memory, load immediate values, and move values between registers. The ALU in the form of a DIP8 SPI EEPROM was programmed but never hooked up to the rest of the circuit. A few months ago when I moved, I finally took apart all the breadboards, so the calculator is officially gone. Below are some ideas about what I would like to keep and what I would like to do differently next time if I ever return to this project. Over the past few years, I've thought a lot about how to redesign this, so I may change my mind again. These are the ideas I have so far.

What to keep

Control signals in instructions
Like most other TTL computers, this one used an EEPROM to store the microcode controlling the state of the components in the system. Since the instruction byte is just an arbitrarily assigned index into a lookup table, I also encoded information in the instruction itself. This let me save room in the design and is part of how everything fit into one microcode EEPROM instead of two.

Work on both sides of the clock
An inverted copy of the clock signal latches values where necessary so that state changes in the circuit when the clock signal goes up and is latched when it goes down. This is simpler than trying to coordinate machine cycles like a Z80 or 8051.

Separate RAM and program memory
As tempting as it is to build a Von Neumann architecture where addresses can refer to RAM or ROM, it's simpler to keep the two types of memory apart.

What to change

Move from 8-bit to 4-bit architecture
This is the biggest change since it affects a lot of the other aspects of the design. It will hopefully require fewer chips and simplify some things. In the old design, for example, there were four 74HC670s that form two sets of four registers for a total of eight 8-bit registers. In the new design, one 8-bit latch should be enough to hold two 4-bit registers. This is also a good register size since the BCD numbers a calculator uses are divided into 4 bits for each decimal place. 

Simplify design
The old design was up to over 30 chips without being finished. Space on the two protoboards I planned to put the chips on was starting to get really tight. The new design should be simpler since it only uses 4-bit registers and also because I have some new ideas for reducing the chip count like using pull ups to eliminate a lot of buffers. For example, to load immediate values into one half of the 8-bit latch that holds the two 4-bit registers, the immediate value can be encoded in the instruction and fed to the data bus with pull ups. Z-stating everything that can drive the data bus and loading the latch will load the immediate. The other 4-bit half can drive the other four bits of the data bus so the load retains the value in the other half of the latch. Another idea is to use pullups to the RAM address bus driven by the bits of the instruction to refer to eight or 16 bytes of RAM that can be used like registers.

Arithmetic Logic Unit (ALU)
My plan to use a DIP8 EEPROM as an ALU was something novel about the old design but at the same time also what held me back from finishing it. The EEPROM I found had 4MB of storage, so it could hold 64 tables 8x8 in size. Adding a carry bit, this would mean 32 ALU operations which is definitely enough to implement what I was planning with the calculator. Carry could also serve to refer to different instructions in cases where it isn't used, such as multiply and divide, so the practical number of instructions would be much more than 32. The problem with this setup is getting the 22 bits of information needed for every ALU operation into the EEPROM efficiently along with the eight bits or more needed to put the device into read mode. One idea was to run a second clock eight or 16 times faster than the main clock and use that to clock data into the EEPROM, but I could never figure out how to get the two systems to cooperate while running at different speeds. Also, this setup would require extra latches and shift registers which would probably negate any space savings from using the EEPROM in DIP8. The new design will use a 32KB EEPROM. With eight bits for the two 4-bit registers and one bit for the carry bit, there will be room for 64 ALU operations.

There are a few aspects of this that I haven't figured out yet. One is how to handle the carry bit. The 8-bit latch holding the two 4-bit registers will drive the ALU and also receive it's output, so in the case of addition, one half will contain the sum and the other half will contain the carry. From there, there needs to be some way to record the carry bit since it will be overwritten when a new value is loaded into the register. The easy way is to add a latch to capture the carry, though I hope I can devise something that doesn't add to the chip count like having that latch do something else useful with the other seven bits.

Another interesting advantage of using an 8-bit latch to hold both registers that feed the ALU is that the latch can load an 8-bit address value from ROM or RAM and increment it with the ALU without having to do it in two 4-bit halves. The problem with this is that the ALU output is only 8-bits so there is no room to record the carry output which would be needed to increment a 16-bit pointer. One solution is to keep the 8-bit value in the latch and test if it's zero to know if it overflowed. Another idea is to have a separate bit fed to the ALU so that operations can have a second 8-bit output when needed as in this case with the carry bit. The advantage of this is that 4-bit operations could also have a carry output without trashing one of the two 4-bit registers to hold the carry.

Microcode changes
The old design embedded microcode directly into the program ROM in order to reduce the number of microcode ROMs from two down to one. This made some instructions balloon to many bytes. In retrospect, I don't think even a simple scientific calculator would have fit into the 8KB EEPROM I was using since the encoding was so inefficient. The next design will use a more traditional setup without microcode steps in the program. I'm still trying to think of ways to get away with only one EEPROM for microcode. One idea is to store two 8-bit values on the EEPROM for each microcode step and add a second latch to output the second byte every instruction cycle.

Program Counter (PC)
The program counter is another area that proved to be more difficult than I imagined. For one, connecting three 4-bit counters is a huge amount of wiring and only allows for an 8KB program ROM. Unfortunately, as I mentioned in a previous post, there are no readily available 8-bit counters that can be loaded with an arbitrary value. One simplification is to use two 4-bit counters and an 8-bit latch to allow a full 64KB address space. This would require the last instruction in every 256 byte page of program space to change the 8-bit latch to the next page. The assembler could insert those instructions in the background without the programmer needing to worry about them.

Voltage
The old design used a mixture of 3.3v and 5v since the EEPROMs all need 5v while the DIP8 EEPROM for the ALU needed 3.3v. The next time around, I plan to keep everything the same voltage if possible. Hopefully, this will eliminate the HCT parts I was using for managing level translations.

Simulation
Building this type of TTL computer in a simulator is one of the most fun parts of these projects. The last time, I used Atanua to simulate part of it. Unfortunately, I found a major bug in one of the counter chips that would be used for the program counter. The author of Atanua responded to my email reporting the bug but was not helpful in fixing it since he no longer maintains Atanua. There are also useful chips like the 74HC670 that aren't simulated in Atanua, so I think I would try making my own TTL simulator next time. This would be quite a lot of work which is part of my hesitation to jump back into this project.

Miscellaneous ideas
There are a few other interesting things that might be useful for this project that I haven't found a place for yet. The 74HC670 that I was using for registers before is an amazing chip that I don't have plans for in the new design. Implementing some type of bank switching for the RAM or ROM using this might help reduce a chip or two, though there would have to be a way to set it without adding extra chips.

Another interesting observation is that a latch holding eight bits of an address plus four more bits encoded in an instruction would let me specify 12 bits which is enough to address 4KB of RAM. Since 16 bytes can hold a BCD floating point number, memory could be split up into 256 chunks 16 bytes in size. This could shrink the SRAM addressing mechanism to just one 8-bit latch. The problem is that encoding the lower four bits in the instructions means there is no flexibility to loop through the 16 bytes programmatically, so a different mechanism would be needed for when that's necessary.

Open Projects

After starting on my 7400 Calculator project, I thought about how many projects I have open at the moment. Like a lot of hobbyists, I seem to start more than I finish. Most of these are not abandoned, since I do plan to get back to them someday. I decided to take stock here of how far I am and what is left to do. There are two projects here I have not posted about: 6502 Optimizing Assembler and 6502 Calculator Emulator. There isn't really enough yet to write about, but I might as well mention them since I have been working on them now and then for a while. They would also be good for the github page I want to set up and list when I apply for jobs. My plan is to finish most if not all of these projects before I start on something else. Otherwise the list might keep growing without finishing any of them.

Tiny Calculator

80%

A few weeks ago, I put a lot of work into the interface code, which ended up taking more time and effort than I imagined. Like in my RPN Scientific Calculator, the interface code takes up a lot of space compared to the math routines. So far, I can enter numbers and do addition and subtraction, but I still need to fix the sign of the result. For the rest of the calculations, I need to write a lot of checking code for things like scaling angles before applying trig functions and avoiding inputting negative numbers in logarithm functions. Two weeks ago I made some major progress with the keypad, which I will post about soon. Posts related to Tiny Calculator

Pocket Calculator

20%

This project kind of stalled because I got busy with other stuff and also because I hit a few hardware problems that I did not solve. The LCD would work when the speed of the SPI clock was set very low and it would continue to work once I turned the speed up to what the LCD is rated for, but if I turned the calculator off, the LCD would not work again until I set the speed back to very slow. The LCD also did not work when I fully closed the case. Eventually, one of the very stiff ethernet wires I was using broke right off. I will need to rewire the LCD with different wire and start over on the emulator I was working on. Posts related to Pocket Calculator

Programmable RPN Calculator

95%

The last time I worked on this calculator in 2015, I considered it finished other than labels for the keypad. One thing I figured out in the meantime is that the key reading is not entirely reliable since two of the pins on the LPC1114FN28 are open drain, which I did not account for. It also seems that I did not write the key reading code correctly, so there is a chance of shorting pins when you press two keys at once. These probably won't take long to fix, then I will make labels for the keypad, which should be easy now that I have done it for my Tiny Calculator. Another thing that might be helpful is to review the source code and make sure all of my checking code is correct. Posts related to Programmable RPN Calculator

7400 Logic Calculator	30%
This is my latest project and I have been doing a lot of work on it, so I am still really excited about it. I might try to finish some of the projects that are close to done before I return to this to get them out of the way. Posts related to 7400 Logic Calculator

6502 Graphing Calculator

???

In summer 2015, I put this calculator together very quickly to try to get it ready for Makevention that year. Not suprisingly, it did not work at all since I was in such a hurry putting it together. I'm not sure it would be worth it to resurrect this project, but I would like to at least return to it and figure out why it didn't work. One possibility is that the LCD was damaged when I was trying to drive it with an MSP430 since the wires I used had metal connectors that kept shorting to each other. Another thing I noticed when I pulled the board out a few weeks ago was that the EEPROM is not a modern CMOS chip but something older that uses 140mA and has a slow 250ms access time. The latches to drive the LCD are 74LS874s, which I now realize consume way more power than HC chips. There could also be other problems like the CPLD. In any case, it will be fun to try to figure everything out. Posts related to 6502 Graphing Calculator

6502 Optimizing Assembler

25%

This is a project I started to practice my Python skills and have a concrete project to talk about in job interviews. My plan is to analyze assembly files (not compiled binaries) and make optimizations based on a few simple assumptions. This will should be able to shave a few cycles off of unneeded instructions, which is especially useful when you are using macros. It will also be able to manage zero page much better than just assigning fixed addresses to each function or sacrificing the X register for use as a slow pseudo stack. Posts related to 6502 Optimizing Assembler

6502 Calculator Emulator

40%

This is a 6502 emulator written in JavaScript that will let me test calculator firmware in the browser without having to upload it to a physical calculator. The emulation works at over 50MHz currently and passes Klaus' test suite. The input and screen output work, as well as memory paging like the real calculator will have. Now I have to find a way to speed up screen drawing, since I think this is the source of lag when typing. Then I will need to start writing the firmware for the calculator. Someday I will host it on a website so that other people can help me find bugs. Posts related to 6502 Calculator Emulator

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.

New Project: 7400 Logic Calculator

My newest project is a calculator using 7400-series logic chips. There are a lot of really neat computers built using these parts, and I would like to try building a relatively small one that fits into a calculator. My idea is to keep the design as minimal as possible, since even a simple computer of this type could get pretty big quickly. There are a few things I have been thinking of for a long time that should help me save space.

A few years ago, I got interested in building one of these computers using lookup tables on a flash or EEPROM chip to implement a simple ALU and got as far as putting a 4x4 bit look up on table on an EEPROM. Eventually, I gave up the idea since at least one other person had built essentially the same thing that I wanted to build, and I didn't want to totally reinvent the wheel. Recently, I got interested in the idea again when I saw Ben Eater's excellent series on building an 8-bit breadboard computer. It uses an EEPROM for microcode, which is what I had considered for other projects. Another neat project I looked at is the Gigatron, which is a different RISC-type design that I don't think uses microcode. So far, I have been able to get a fairly simple version of what I want to build going in the Atanua simulator:

After I got this going, I already started looking for ways to make the circuit smaller and fit into a calculator sized case. First, I have four registers, which would make programming a lot more convenient, but I would leave out to save space. Also, I have two microcode ROMs, like in Ben Eater's design, although I could survive with just one if I latch out some of the control codes from the program ROM.