Remoticon 2021 // Rob Weinstein Builds An HP-35 From The Patent Up

Fifty years ago, Hewlett-Packard introduced the first handheld scientific calculator, the HP-35. It was quite the engineering feat, since equivalent machines of the day were bulky desktop affairs, if not rack-mounted. [Rob Weinstein] has long been a fan of HP calculators, and used an HP-41C for many years until it wore out. Since then he gradually developed a curiosity about these old calculators and what made them tick. The more he read, the more engrossed he became. [Rob] eventually decided to embark on a three year long reverse-engineer journey that culminated a recreation of the original design on a protoboard that operates exactly like the original from 1972 (although not quite pocket-sized). In this presentation he walks us through the history of the calculator design and his efforts in understanding and eventually replicating it using modern FPGAs.

The HP patent ( US Patent 4,001,569 ) contains an extremely detailed explanation of the calculator in nearly every aspect. There are many novel concepts in the design, and [Rob] delves into two of them in his presentation. Early LED devices were a drain on batteries, and HP engineers came up with a clever solution. In a complex orchestra of multiplexed switches, they steered current through inductors and LED segments, storing energy temporarily and eliminating the need for inefficient dropping resistors. But even more complicated is the serial processor architecture of the calculator. The first microprocessors were not available when HP started this design, so the entire processor was done at the gate level. Everything operates on 56-bit registers which are constantly circulating around in circular shift registers. [Rob] has really done his homework here, carefully studying each section of the design in great depth, drawing upon old documents and books when available, and making his own material when not. For example, in the course of figuring everything out, [Rob] prepared 338 pages of timing charts in addition to those in the patent.

LED Driver Timing Chart

One section called the “Micro-Programmed Controller” is presented as just a black-box in the patent. This is the heart of the systems, and is essential to the calculator’s operation. However, all the other parts that talk to the controller were so well-described in the patent that [Rob] was able to back out the details. The controller, and all sections of the calculator, was implemented in Verilog, and tested on an instrumented workbench he built to test each module.

Once everything was working in the simulations, [Rob] set out to build a working model. TInyFPGA models were used, one for each custom chip. A few understandable departures were made from the original design. An 18650 lithium ion cell powers the board, kept topped off by a modern battery charging controller. The board is larger than the original, and yes, he’s using the Hackaday-obligatory 555 chip in the power-on circuit. In this short demonstration video, you can see the final prototype being put through its paces side by side with an original HP-35, working through examples from the owner’s manual.

This is an incredibly researched and thoroughly documented project. [Rob] has made the design open source and is sharing it on the project’s GitLab repository. [Rob]’s slides for Remoticon are not only a great overview of the project, but have some good references included. Its clear he has a real passion for these old calculators and has done a fantastic job exploring the HP-35. But even after three years, there’s more to come. He’s thinking about making a PCB version, and a discrete implementation using individual logic gates may be in the works.

We wrote about the history of the HP-35 before. And if you like hacking into these old calculators, check out our writeup of a similar dive into the Sinclair scientific calculator.

39 thoughts on “Remoticon 2021 // Rob Weinstein Builds An HP-35 From The Patent Up

  1. > But even more complicated is the serial processor architecture of the calculator.
    This made me instantly think of SERV the SErial RISC-V CPU ( https://github.com/olofk/serv ). Where Olof Kindgren, the creator of SERV, used maximum serial processing for minimum logic gates count. The current record is 6000 CPU’s in an expensive Xilinx vcu128 FPGA. Plug “corescore.store” into your search engine of choice to see how many low performance serial CPU’s he managed to fit into other FPGA boards.

    1. Any idea how/if those SERVs are connected on the FPGA? Like, do you have a link that you could share that shows them being used in concert?

      I have had a little read of GreenArray forth chips, and it seems like an FPGA array of J1’s could be interesting – but I’ve not managed to find much on them being used; although I will say the MCMC optimisation seems intriguing, if one had and application to usefully apply it to…

      Thanks in advance if you do reply, and no worries if not :-)

      1. No idea. One thing about SERV is that it “just” a minimal serial RISC-V compliant CPU.

        Example code might be corescore, where every SERV just says it’s number and that reported using a TX only UART ( https://twitter.com/OlofKindgren/status/1409634477135982598 ) to the host computer.

        There was mention of “servESA a servant implemented in a chip that will be used by the European Space Agency”, that may be exactly what you want, info may surface once there are a some ASIC’s made using SERV. Maybe servESA is just a bunch of SERV CPU’s running PaGMO (Parallel Global Multiobjective framework for Optimization), I have no idea, servESA was only mentioned on one line in some slides back in 2019, plug the following into your search engine of choice: site:riscv.org “Olof Kindgren” “Bit by bit – How to fit 8 RISC-V cores in a $38 FPGA board”

        I know that the RISC-V M-extension (Integer Multiplication and Division) will be added as an option to SERV, and that an ASIC is being worked on, which could be very interesting (In reality I do not expect it to be anything like this https://twitter.com/gatecatte/status/1415043099605278721 ).

  2. Six months ago I finished rebuilding a junk Bowmar calculator that I picked up at goodwill for a buck. I also picked up a TI version of the HP calculator shown in the video, but haven’t started rebuilding it.

    I replaced the (Bowmar) damaged batteries with a lithium flat battery and added a charge controller running off of a USB connector on the original casing, along with a handful of cleanup and cosmetic repairs. It’s on my list to do the same for the TI eventually.

    The old calculators are wonderful: the digits emit light with high contrast and are easy to see, the buttons are raised off of the face and have a tactile “snap” when pressed, there’s lots of space between the keys, and the operations are intuitive. Your fingers know when they’re on the keys, and when a button has been pressed.

    Modern keypads have raised domes in a flexible face, and sometimes no dome on a completely flat face (ovens and washing machines nowadays). No tactile feedback, and usually no audible feedback, and the resistive short mechanism sometimes has to be pressed really hard and/or really long to make contact.

    Compare with the default calculator app in linux: type a number and then sqrt, it responds “malformed app”. You have to use the mouse to click ahead of the number and insert the sqrt sign, then it’ll work. Mathematically correct, but not the way people are used to entering calculations.

    1. Sqrt then number is also programmatically correct. All programming languages save some very low level stuff uses some form of sqrt(X).

      I do agree about a calculator app should reflect how calculators have historically handled sqrt, sin, cos, etc. This is where accuracy should be giving way to UI intuitiveness based on historical patterns and expectations, not some mathematician’s “everyone’s been doing it wrong since forever!!!111” pet peeve.

    2. “not the way people are used to entering calculations.”

      Not if they are used to a plain, immediate-execution calculator. Scientific calculators are a horse of a different color though.
      Is that the Gnome calculator? It, and a few others are what’s know as “expression” or “formula” calculators, much like many scientific calculators. If you didn’t expect it to work that way however, they’ve done a poor job on their UI.

      P.S. I’d love to see a photo of your Bowmar calculator, or a full post at some point!

    3. “default calculator app in linux” :)

      in all seriousness i would say there’s no such thing, but if there is, it’s dc….not the clickable nightmare you criticize :)

    4. > Compare with the default calculator app in linux: type a number and then sqrt, it responds “malformed app”.

      What “default” app? On which distro, and which desktop?

      I popped KCalc open, and it doesn’t even have a square-root button. It does give you an x^y button, which you can use to the same effect by punching in 0.5 for y.

  3. I’ve got a scientific calculator from a bit later than this (74). Best part–besides the VFD–is that it uses the display register during calculation. So you can watch it crank through the calculation in real time. Takes a good second or two for trig and root functions.

  4. I feel old.. I still have a 35. On my bench. Getting regular (not daily, anymore) use.

    I didn’t buy it new, though- I am the second owner. My daily drivers are 11C and 15C, though.

    1. I had a friend who bought an HP-35 in the summer of 1972. I bought an HP-45 a couple of years later for $395, and at one point I lusted after the HP-65.

      I still remember friends borrowing it because we all had the same homework that involved doing iterative solutions of transfer equations. I still have it, along with the leather belt pouch, plastic case, and manual. The battery pack doesn’t work anymore, though, so I can only use it with the wall-wart power supply.

    1. Meaning, as I understand it, that pre-packaged microprocessors as ICs were not available so they had to use gates (AND/OR/NOT etc) and build a processor out of those themselves.

      1. kaythe is right. Microporcessors weren’t available yet so the HP engineers had to design their own processor ICs, actually down to the transistor level. The HP-35 technical lead, Dave Cochran, talks about this in a brief memoir:

        It wasn’t my chip design. I just took the architecture, I just laid out the high level schematic-requirements; it needed shift registers, but I didn’t put the little individual cells in. France Rodé and Chung Tung did the individual chip design; they did the detail architecture down at the transistor level and then turned that over to Mostek and AMI, who did the layout. France also did part of the bipolar driver too.

        -Rob

      2. If you follow the trail, microprocessors _evolved_ from calculator chips. Intel’s 4004 came from designing Japan’s Busicom’s calculator. A parallel story at Texas Instruments.

        Interesting aside: HP sent the TWO essential chip designs to *both* AMI and Mostek, but neither was able to initially produce the the chipset (the Timing & Control chip, and the Arithmetic & Registers chip). As luck would have it, *each* was successful where the other had failed, so prototype calculators were built while they worked the bugs out on there defective designs.

  5. Oh, where for art thou, TinyFPGA! May I utter an ode toward your short life? Little gum stick of wonders, you offered freedom from hardware backdoor related silicon strife. Avast, you were too good for this world!

    I really miss these things. Mr. Valenty disappeared (due to his new position at Intel?) and the chip shortage killed off the ice40lp8k at the heart of the flagship offering. My dream of a socketable fpga on a module was a reality for a short time. Perhaps one day, the promise of reconfigurable computing can be ressurected… for now, I must treat the five I have with care, as you cannot get replacements

    1. Hi poe,

      You’re absolutely right, the TinyFPGAs are terrific but they’re unobtanium now. In fact, about two years ago when I was gathering the parts for my replica, the Ax1s were readily available from Digikey and Mouser but the Ax2s were not. My HP-35 replica requires six Ax1s and one Ax2. I put my name on the waitlist at Sparkfun and waited. In the meantime, I found that the Ax PCB was available on Oshpark so I bought three and some Lattice LCMXO2-1200HC-4SG32C FPGAs from Digikey and I built them up – they worked fine. Sadly, the boards on Oshpark were an earlier revision without the LEDs. Fortunately, about a year ago, Sparkfun came through and I got the current rev Ax2s in time for my build. In December 2021, Crowd Supply showed they had stock so I ordered more Ax1s but, four months later, they still haven’t shipped.

      The TinyFPGAs were perfect for this project: they only need one power rail (3.3 V), there’s only one IC on the board so there’s no need to explain why it takes multiple ICs to emulate each of the old 1970’s ICs, and they can plug right into a standard 24-pin IC socket.

      -Rob

  6. I got an HP35 when I was in engineering school in 72. The only person in the class to have one. It was unfair to everyone else with a slide rule. I got a series of great grades.

    1. Someone I knew who worked for RCA got an HP-35 that year or the next. They did a group buy, so they got a good price. It was the first pocket calculator I ever saw.

  7. I’m reminded of a scene in one of my favorite movies, Almost Famous, in which the young writer for Rolling Stone, William, finally gets an opportunity to interview the band’s front man, Russell, and starts asking him questions about music. Russell stops him and says, “Just make us look cool”.

    I feel like Chris Lott did just that – this article makes my project look cool. Thanks Chris!

    I’d also like to thank Kristina Panos, Angie Weis Gammell, Christina Ramsey, and, of course, Mike Szczys for the opportunity to present my three-year journey through the ‘569 patent to a wider audience.

    Thanks again,

    Rob Weinstein

        1. I found the part about the continuously-operating 56-bit Johnson ring interesting. It’s a good way to avoid a lot of mux logic, if you have time to wait for the ring to go around. (It’s not great for power consumption, though.) It reminds me a little of the mercury delay lines they used as memories on old computers. I hope things are going well. I’m still doing error correction!

          1. Although now it seems kind of Rube Goldberg- or Heath Robinson-esque, at the time the HP-35 was designed, using dynamic shift register memory would have been well known and understood. For some interesting background, Ken Shirriff has a couple of terrific blog posts on dynamic shift register memory ICs that were available in the 1970s:

            Inside the Intel 1405: die photos of a shift register memory from 1970

            Inside the Apple-1’s shift-register memory

            Ken explains the history and performs a fascinating and in-depth teardown of these devices. And don’t skip the footnotes, a lot of the best stuff is found in Ken’s footnotes.

            -Rob

        2. Thanks for the links. That is interesting. I liked the footnote about the sonic delay line with torsional pulses. Crazy. That Woz was pretty brilliant with his Apple I/II design. I got to see him speak a few years ago at CU in Boulder. (He’d actually attended school there for a bit and was sort of kicked out.) It’s funny; some nonprofit paid him $25k or $50k or something to speak. I don’t know if he was hurting for cash. I remember the Apple ][ used the normal program RAM as the character (or graphics) buffer and periodically took it over to do a raster scan. You had to make sure not to store data in the character buffer.

    1. Hi smartroad,

      The key switches are:

      Purple Zealios V2 Switches (Tactile) – 67g from Zeal Generation Inc

      HP calculators were famous for the satisfying tactile action of their key switches. That wasn’t an accident. The ‘569 patent says:

      One of the main advantages of the keyboard is the “over-center” or “fall away” feel. FIG. 25 shows a force-deflection curve for a typical key. As can be seen a force of about 100 grams must be exceeded before the metal hump “breaks” through. After this critical value the operator cannot prevent contact from being made. Similarly when the key is released, contact is maintained until a critical value when the hump bounces back. Again, past a critical point the operator cannot prevent the key from releasing. This type of action prevents a condition known as “teasing” in which a key is nearly depressed and slight movement causes multiple entries. The point on the force-deflection curve at which contact is made or released is most desirably on the negative slope portion. In the calculator it is either there or exactly at the bottom (point A in FIG. 25), but never on the final positive slope portion.

      I wanted to duplicate that feeling as closely as possible so I bought one of those nine-key switch samplers from Amazon that had eight Cherrys and one Zealio. I spent days fidgeting with the keys on that sampler, even handing it to other people asking their opinions and it was pretty unanimous – I, and most others, liked the Zealios best. The resistance is greatest right at the top of the stroke and they fall away almost immediately upon pressing.

      The relegendable keycaps are:

      X-keys Relegendable Keycaps, Cherry MX Compatible, Transparent, 1×1 and 2×1 (for the Enter key) from Amazon

      I sketched up the legends in Visio, printed them, cut them out, and inserted them in the caps. I think they turned out pretty good.

      -Rob

    1. Hi koendv,

      I’m glad you brought that up. Wikipedia’s article on CORDIC says:

      CORDIC was conceived in 1956[10][11] by Jack E. Volder at the aeroelectronics department of Convair out of necessity to replace the analog resolver in the B-58 bomber’s navigation computer with a more accurate and faster real-time digital solution.[11]

      In a couple of brief memoirs hosted at The HP Memory Project, the HP-35’s technical lead, Dave Cochran, explains about the algorithms he used in the HP-35.

      In his memoir, A Quarter Century at HP, Cochran explains how he learned about CORDIC right from the horse’s mouth, so to speak:

      I was looking at Osborne’s architecture and trying to figure out what an algorithm was. I even flew down to Southern California to talk with Jack Volder who had implemented the transcendental functions in the Athena machine and talked to him for about an hour. He referred me to the original papers by Meggitt where he’d gotten the pseudo division, pseudo multiplication generalized functions.

      In this interview excert taken from the Computer History Museum, The HP-35 Design, A Case Study in Innovation, Cochran goes into more detail:

      The choice of Algorithms for the HP-35 received considerable thought. Power series, polynomial expansions, continued fractions, and Chebyshev polynomials were all considered for the transcendental functions. All were too slow because of the number of multiplications and divisions required. The generalized algorithm that best suited the requirements of speed and programming efficiency for the HP-35 was an iterative pseudo-division and pseudo-multiplication method first described in 1624 by Henry Briggs in ‘Arithmetica Logarithmica’ and later by Volder and Meggitt. This is the same type of algorithm that was used in previous HP desktop calculators.

      -Rob

      1. I had assumed at one time that CORDIC was obsolete, given that multipliers are readily available and you can use a Taylor series. That might be true for FPGAs. But I just used CORDIC in an ASIC for sine and arctan computations. It uses less power, especially, I think, for limited bitwidths.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.