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.

Improved 8051 DPTR Addressing

Today I was reading more about 8051 microcontrollers, and I realized I could make an improvement to some of the code I posted in 2017 for my BCD Addition Speed Test comparing the 6502 and 8051. As I wrote there, the 8051 has at least one 16 bit register called DPTR, which is the only way to get data to and from external memory. Unlike the 6502, there is no indexing or indirection when accessing external memory, so all addressing has to be done manually. Here is the macro I had in my other post to compare the two types of addressing, with an extra column showing cycle count:

Line	6502	Cycles	8051	Cycles
001 002 003 004 005 006 007 008 009 010 011 012 013 014	... LDY #Offset STA (Address), Y	2 6	IndexDPTR0 MACRO DPTR_copy, Index  clr C  mov A, DPTR_copy add A, Index mov DP0L, A mov A, LOW(DPTR_copy)+1 addc A, #0 mov DP0H, A ENDM ... push A IndexDPTR0 Address, #Offset pop A movx @DPTR, A	1 1 1 1 1 1 1 2 2 2

The first improvement is to get rid of the clr C on line 002. I'm not sure how I missed something that simple! When I wrote the post, I had mostly worked with the 6502, which needs C to be explicitly cleared. Maybe writing MSP430 assembly, which also has an add without carry instruction, helped me realize that. The second improvement is eliminating the push on line 11 that saves the accumulator. One shortcut is to save that value to DP0H then restore it when the new DP0H is written using the xch instruction. This eliminates the pop on line 13 also. The new version looks like this:

Line	6502	Cycles	8051	Cycles
001 002 003 004 005 006 007 008 009 010 011 012	... LDY #Offset STA (Address), Y	2 6	IndexDPTR0 MACRO DPTR_copy, Index  mov DP0H, A mov A, DPTR_copy add A, Index mov DP0L, A mov A, LOW(DPTR_copy)+1 addc A, #0 xch A, DP0H ENDM ... IndexDPTR0 Address, #Offset movx @DPTR, A	1 1 1 1 1 1 1 2

The macro is still 7 cycles but it saves the 4 cycles for push/pop or the 2 cycles to save A in a register instead. It also looks much cleaner and will hopefully lead to less headaches.

In addition to movx @DPTR, A and movx A, @DPTR there are also movx @Rn, A and movx A, @Rn instructions that I had not paid much attention to, since using them constrains where objects like BCD numbers can be stored. At the very least, those objects would have to fit into 256 byte pages to use those instructions, and realistically the objects might have to start at the beginning of the page and possibly waste some memory. On the other hand, I have been doing a lot more thinking about how to store those objects to build a graphing calculator. Splitting memory into regular chunks (regardless of the size the object it occupies actually requires) is one strategy to prevent memory fragmentation, so using the faster movx @Rn, A and movx A, @Rn instructions might be a good fit. The R registers are also much more flexible for indexing since it is faster to adjust the address when you don't have to account for crossing page boundaries like the macro does.

Tiny Calculator: Hardware

Tiny Calculator is business card size.

The hardware for this project is finally done! The first step was getting the LCD running. This time I went with a 128x32 LCD from Newhaven, which is a little pricey at $11. A simple HD44780 compatible LCD like I used for my RPN Scientific Calculator project would give me the same 20x4 character resolution for $3-4, but all the ones I have seen are way too big. Another option would be a small OLED screen, which are very cheap but would drain the CR2032 battery a lot faster.

The LCD has 17 pins with 1.5mm spacing, which is smaller than a breadboard or protoboard but still big enough to solder by hand. The majority of the pins are for capacitors, so I soldered a small adapter board to hold them and route the data pins to a breadboard. This was tedious and more difficult than I imagine when I bought the LCD but the hardware worked on the first try. After I got it running, I epoxied the LCD to the board. Next time, I think I will go with something easier to solder like an OLED screen even if it takes more current.

The datasheet for the LCD has some initialization code, which I could not get to work. A search turned up some working C code from another forum that was easy to get running with GCC for the MSP430. Translating the C code to assembly was a little tricky since some of the variables for initializing the SPI module on the MSP430 are not plain constants as you might expect from looking at the C code. It took some searching in the header files to figure out that what appears to be a constant is actually something cleverly defined to load a configuration value from the MSP430. After I got that working, everything else went smooth. Rather than try to design my own 5x7 font, I reused a character set I found on a German forum, which came in handy on another project I have been working on but haven't posted about yet.

The main board of the calculator is pretty simple. It just holds the microcontroller, CR2032 battery, and some pins for programming. All the wires are 30 gauge wire wrap I got from Mouser, which I really like using. The power lines are thicker gauge, but they are there more for color coding than because I need them to be that thick. 30 gauge copper is supposed to be able to carry more than the few mA I am using without dropping a lot of voltage.

The keypad has 35 keys, which is more than the 25 I was planning on originally. The main reason I did this is because it looked strange to have a square keypad. Also, there were two leftover pins since Xin and Xout can be reused as GPIO if there is no crystal.

 Each key takes up one 3x3 block on the protoboard, which is smaller than the 4x3 spacing of the keypad on my Pocket Calculator project. It turns out, it's not too difficult to bend the legs under the button a little to make them fit the tighter spacing. The LCD and the keypad both plug into the main board with headers.

Since the calculator runs on a battery, it's important to keep the calculator in low power mode as much as possible. This turned out to be surprisingly painless in assembly! Setting up interrupts is very straightforward too. The calculator scans the keypad a few dozen times a second and goes back to sleep if there is no work to be done. Each key has a byte of memory allocated to it to implement a counter for debouncing the keys and showing which keys have been read. My very cheap multimeter shows that the calculator uses a lot less current than the datasheet for the MSP430 and LCD suggest. Hopefully I can borrow better equipment and get a more accurate reading to try to better estimate how long the calculator should run before it needs a new battery.

The interface code is already mostly done and will be the topic of the next post on this project. After that, the only step left is adding the key labels.

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.

Tiny Calculator: Improved CORDIC

Since my last post I have made a lot of changes to the CORDIC routines I was working on. As you can see in the chart above, the new version fits in less than the 4.1k of the last version even after adding in logarithms. The change came after I found an article about how the HP-35 did CORDIC calculations. Unlike the other descriptions of the method I have used, this version uses an atan table of powers of 10 instead of powers of 2. This lets you shift the arguments by whole decimal places, which is much faster with BCD numbers than powers of 2 . Before, I had wondered if this would be more efficient, but I don't understand the math behind it well enough to modify the routine myself. My implementation of the method the HP-35 uses only takes 90k cycles, compared to the 1.18 million of the last version. The X and Y that the calculation produces, however, cannot be scaled to produce sine and cosine directly. The scale factor depends on the number of rotations, which is easy to precalculate when the angle is halved every iteration, but not possible to know in advance when you use powers of 10 since each iteration requires up to 9 calculations with each affecting the scale factor. As a result, the ratio of X and Y provides the tangent and the HP-35 used identities involving multiplication, division, and square root to generate sine and cosine from tangent. In addition to the 90k cycles for the CORDIC calculation, I would need at least another 140k cycles for these identities. This is 5 times faster than how I was doing it before, although I'm afraid the accuracy would suffer from the added calculations.

The next thing I tried was posting on the HP museum forum, where Thomas Klemm showed me how to do CORDIC calculations in base 10 without resorting to identities. This was a huge help and a much better way to do things than anything I have tried before. The newest routine I have calculates tangent in only 186k cycles and provides sine and cosine without additional calculations! Like in Thomas' version, I tried to make this CORDIC routine more generic so that I can reuse it for inverse trig functions too. Logarithms and powers of e turned out to be much simpler than trig functions using the method described on the same page about the HP-35.

There are still a lot of things to learn about MSP430 assembly. One thing that tripped me up was thinking that RRA automatically shifts a 0 in from the left when rotating when it actually reproduces the leftmost bit instead. Another surprise was that shifting packed BCD by two decimal places is just as fast loading a word from memory, swapping and combining bytes, then writing the result back to memory as it is to just copy bytes directly. I thought the byte copies would be faster, but I was actually able to shave one cycle off by loading and writing words. I rewrote this short section of code five different times trying to save a cycle or two and eventually realized that this is not a useful way to spend my time. This improvement is too tiny to ever be noticeable, and I want to finish this project soon. There are a few other small improvements I have not spent time on since they would provide only a negligible speed up.

The next step is to start working on hardware and the interface code.

Tiny Calculator: Sine, Cosine, and Tangent

For the trig functions, I started building the same angle table that I used for the CORDIC routines in my RPN Scientific Calculator. Comparing my table to an example calculation I found of how CORDIC works, I noticed that the values are all pi times bigger than the ones in the example. Could I have made the same mistake in my RPN Scientific Calculator? When I get back home from the holidays, I should check to make sure that this does not throw off some of the calculations. Another thing I found out from the same page was that the K value to multiply by after the CORDIC calculation is calculated for a particular number of iterations. In my RPN Scientific Calculator, I included a K value for the maximum number of iterations and truncated it when less precision was used. On second thought, I should have done some testing to make sure truncating the K value to the precision of the argument always yields the best results for a particular level of precision. At the moment I don't plan to redo anything on my older calculators unless something is majorly wrong. It is good, though, to recognize this type of mistake, so I can look out for it in future projects that use CORDIC.

To generate the angle table I used the bc command line calculator. It has a very simple programming language that can run from a script. Interestingly, bc does not seem to do any type of rounding, so the tables I have are unrounded. Maybe I will experiment with a rounded table to see how much of an effect it has. For some of the other tables (including a couple I ended up not needing) I used Python, which has been really helpful. The table itself contains angles descending in size, so I only sto

The first step to implementing the trig functions was replicating the CORDIC calculations in a spreadsheet. This works for about 30 iterations until the numbers become too small for the spreadsheet to handle. Rather than doing bit shift operations like I would on the microcontroller, I multiplied by inverse powers of two, which accomplishes the same goal. When I had that working, I tried generating those multipliers on the MSP430 and multiplying, rather than bit shifts. I thought this might be fairly fast since the multiplier could be left in binary, which makes it quicker to use with the Russian Peasant algorithm, and the amount of zeroes in the multiplier would mean relatively few multiplies altogether. Consider this shortened table of successive inverse powers of two: