Arduino Nano Powers Reverse Polish Notation Calculator

There’s something about Reverse Polish Notation (RPN) and the calculators that use it. It calls to mind a time when a calculator was a serious tool, and not just a throwaway toy. Created in the legacy of such calculators by HP and Texas Instruments, [Simon Boak] shows off his SB116, sporting an Arduino Nano under the hood. It’s a fully custom design, with a hand-built metal case, a custom PCB for the keyboard, and a tiny OLED display for maximum retro green goodness.

The impetus for this build was to replace a particular calculator, a well-used TI Programmer, that’s useful for working with 6502 assembly. The SB116 supports binary, octal, decimal, and hex; and boasts some downright useful functions — AND, NOT, OR, XOR, and bitshifts. The source code is available, but you’re on your own for the case and keyboard. And for maximized retro faux-nostalgia, [Simon] designed a box that would have looked right at home on an 80s store shelf.

Stick around for more retro-modern takes on calculators, or tales of repairing a genuine vintage model.

51 thoughts on “Arduino Nano Powers Reverse Polish Notation Calculator

    1. Agree! Glad I still have my pocket HP-15C and a HP-16C . They still work fine. Although I don’t use as much as I used too, but still within reach for that occasional use. We have a HP-12C for general use up in the kitchen.

      Neat build SB116 BTW! Just won’t fit in the shirt pocket :) .

      1. I have a functioning HP-16C that I bought way back when. But I normally use the Android app WRPN 16c emulator for it. I have no connection to that product, but I have found it works well, and if it does not, the developer is quite responsive.
        Normally, I am lazy and copy and paste into a Windows or Linux calculator. 64-bit numbers are just too much to manually type.

    2. Still have my HP 41CX on my desk at home and still use it. On my phone I use 41CX emulator. I don’t do much programming on them, mainly use them as just regular calculator these days but there is certain comfort to using them. I do find RPN with stack manipulation slightly faster an convenient to use.

  1. The big difference between HP and TI in the late 70’s and 80’s was that while HP was famous for its RPN approach, TI used infix. Infix required using parenthesis which were extra strokes. The HP fans would laugh at that.

  2. Beautiful. I love the weaponized aluminum case.

    60 mA though! Have we learned nothing in a half century since the HP-35?

    My circa 1981 HP41C draws just 4 mA. (though it doesn’t glow in the dark. LCD, not OLED…)

    Annoyingly, my much newer HP15C-LE draws 20 mA. I surmise its code was ported from the original 15C by a neanderthal intern.

    1. I agree, even if it makes the calculator very bulky, even back then. The blog post tells that the front panel was bought, and while I thought he used a folding machine, it seems only the thinnest parts were bent, so he may have done everything with only a CNC and folded everything by hand.

      1. True that the front panel was bought, but everything else I made by hand ;) I’ve got a few tricks now for this sort of thing, including using an arbour press to punch clears round holes instead of drilling.

        Cut aluminium with sheet metal nibbler and hacksaw, and then plenty filing. Even the acrylic over the screen was cut by scoring it and then snapping it over a straight edge.

          1. Thank you!

            The keyboard is simple enough: array of rubber domed buttons on the PCB inside, on top sit the “key caps” made of 2 pieces of acrylic plastic-welded together. The bottom piece sits flat on top of the button, below the front panel, the top piece is then on its side sticking up through the hole.

            Hard to photograph but here’s some of the buttons:

    2. I think the same. I also like the design.
      It’s charming, reminds me a bit of the boxy cars from the 1980s. Or the futuristic 1970s designs (Commodore PET etc) .🙂👍

      *the metal is called aluminium, though.

  3. As someone who has used a HP48 throughout all his studies, I should be a RPN devout, and I was. That is, until non-RPN calculators started offering the possibility to edit the previous expression. When you have a long expression, being able to edit just the variable value and thus evaluating your expression for many variables values quickly, RPN is not the greatest tool in the 21st century.
    I have a TI-89 and a HP48, and I still use the HP48 about 50% of the time, depending on what calculator I get my hands on 1st when I need it. But when it comes to problems such as “oh, and what would the answer be if you changed this parameter value in the expression I have spent 30 seconds evaluating”, I instantly regret not using the TI-89.
    You may argue that you could program the expression, and yes you can, but that’s hardly what you would routinely do when you have to evaluate an expression that you don’t have the hindsight of thinking you’ll have to run again. And even if you do, I’d still be quicker on my TI-89, and to reiterate, that’s coming from someone who has used RPN for 20+ years, including under/post grad studies.
    That is IMHO, if you feel RPN is still better, by all means keep using it. The main reason I use the HP48 at work is to put off people from borrowing my calculator!

    1. As for me, most of the cases I ever used/use a calculator for, my RPN HPs work really well. But as with everything, there are edge cases where a different approach or device is better. Technology goes forward too as who ever thought of ‘editing’ a formula on your calculator (in the sense of what is written above) back in the 70s, 80s? Just like computer languages, you use the more appropriate tool at hand for a given job. That said, I have the HP-41 simulator on my Linux desktop(s) for those quick calculations I need, for example working with FreeCad. I’ve also been know to drop in a python shell and type out a formula or two to quickly compute….

      1. Careful. Many 70’s/80’s calculators like the Sharp EL-5100 and TI-74/95 Basicalc could recall previous entries/formula so you could modify and re-execute.

        Along the lines you said, I use the most convenient tool for the particular problem at hand. I always grab my handy physical HP-48 or HP-32 for quick calculations–I find it much easier than using an emulator or app (although I have those too.) For anything complicated, I’ll write to a short C++ / C# / Python program.

      2. Use needs vary. I am not a big fan of RPN, except for ease of parsing. I find myself editing a previous input in a calculator (these days, it’s often a TI89 emulator on my phone) quite often, either because I made a mistake in entering it or because I want to see what happens if I change some number. It’s also good to see what formula I had typed in so I can see if I made a mistake. And, finally, while it’s pretty easy to convert to RPN, still if I have a formula I need to put numbers into, it’s likely to have started off life in infix notation (does anyone do paper and pencil math in RPN?), and it’s pretty convenient not to have to convert it.

    2. we’ve got a whole programming language called ‘forth’ that is dedicated to expounding on a single principle: RPN makes programming an expression so simple that you would consider it routine. and the HP48 “RPL” really exemplified that, imo.

      not gonna criticize the way you use calculators, but that use case you thought up really is the exact argument *for* rpn among its fans.

    3. In a situation of having a long formula and wanting to tune various values, I’ll move to a spreadsheet program on an actual computer. Similarly if I need something graphed, there’s always gnuplot. But there are still plenty of cases where a calculator is handy, and if anything I’d happily trade away programmability for a few more single -press math functions.

    4. The ’48 did what would (now) be better done on a computer, but sacrificed easy numeric calculator operations.
      The ’42 was a better calculator, and I’ve used it (free42) on every phone I’ve had, and every computer.
      Surprisingly , it’s the only easy truly cross platform way to program calculations 35 years after I first bought one

      1. Someone gave me a 48, which I use so infrequently that the batteries are usually dead when I pick it up. My 32s that I bought in 1988 is on its 3rd set of batteries now and is usually my weapon of choice. Free42 will do in a pinch. Would love something like Free42 but replace R/S with a pi key, XEQ with y^x, and support complex numbers by replacing up & down buttons with ‘i’ and ‘angle’ for rectangular and polar entry.

    5. What you say is impossible is something I do in Forth all the time, that is, change a number on the input line, and execute it again. Whether or not a calculator or computer has some kind of command stack or its equivalent function is separate from whether it’s algebraic or RPN.

      I seem to have an RPN brain, and Forth was an absolute natural for me to pick up after all my years of school trying to make us do things in algebraic. OTOH, I cannot latch onto C. I’ve been through the standard K&R book, and a “C for Dummies” book, and I’m done trying. Our English language is algebraic, but I understand the Korean language is RPN, and native Korean speakers tend to find RPN languages to be quite natural.

  4. Cool! My father has a TI Programmer!
    The ancient display is really fascinating, I think.
    It’s so 1970s. Back then, he has building Z80 systems from scratch. The translate feature to/from HEX was very useful, I suppose.

  5. This project has inspired me to plan my own calculator based on a shrunk spreadsheet UI – a 320×240 lcd should be able to display half a dozen rows by half a dozen columns at a time, 32 x 32 would be a practical overall maximum size. I’ll use T9 style input for alpha labelling of cells to keep the keyboard sane, and a PlayStation style joystick for navigation. One could also potentially include a save to sd option to convert to and from csv/ load&save, and a serial port for data logging of real time data. Perhapa include some really simple charting capabilities. Hmm, nice! Now if only I could achieve SBs build quality!

  6. I’ve got an HP 11C, bought it mid eighties. About ten years back I replaced the batteries. Still working and use it once and a while. I only use software calculators when they support RPN. Saves a lot of keystrokes.

    1. Sadly never had the chance to try a real HP, but they keys on this are softer than the TI.

      BOM is just green OLED + Nano + PCB + 40 buttons. It all seemed a bit too specific to way I build things to share the gerbers or anything.

      Keys didn’t take too much work. Plastic weld dries (cools!?) in less than 2 seconds, but I did make a simple jig out of cardboard to guarantee consistency.

  7. I have often wondered how it would be to have a calculator use only integers. (For that matter, I have also thought about making a binary slide rule, for the heck of it. A given size would give more accuracy and precision than normal ones.) I have come to really like scaled-integer math for processors that don’t have floating-point hardware. There’s virtually nothing you cannot do in scaled-integer, and it sure makes for less overhead for the processor than floating-point; it’s just that in a calculator setting, the range and domain of the numbers to be handled won’t be known ahead of time like they are in a program, and keeping the scale factors straight in your mind might be harder.

    BTW, please note that I said “scaled-integer,” not “fixed-point.” Fixed-point is much more limited than the broader field of scaled-integer. I have an article on it at .

    I think that for an integer calculator I would want at least 32 bits, with 64-bit intermediate results for some things. For example, if you have 16,805 ($41A5) and want to multiply by pi, you multiply first by 355 (decimal) and then divide by 113 (such rationals get ingrained in your mind with constant use), the first multiplication would overflow, at 5,965,775 ($5B:07CF), before you get to the final answer at 52,794 ($CE3A), accurate in all digits; in fact, the first erroneous digit is the third one past the decimal point, if you were to go that far. Another way to do it, not quite as accurate, would be to multiply the 16,805 by pi*65536 which is 205,887.4162 ($3:243F, throwing out the fractional part), getting 3,459,931,035 ($CE3A:5B9B), and dividing by 65,536 by just throwing out the low 16 bits and using the top 16 bits as your answer, which again gets you 52,794 ($CE3A), the same thing in this case.

    On my 6502 workbench computer, in Forth, I do a 2,048-point complex fast Fourier transform (FFT) on sampled audio data. With typical audio, and 16-bit scaled-integer math, I have to hold the samples down to about 6-bit resolution to avoid overflow errors in the intermediate results. 24-bit would always be enough for this size of array of samples from an 8-bit A/D converter (which can sound even a lot better than high-end music cassettes did right before CDs took over, which is pretty darned good). 32-bit would definitely remove the “cramp factor” in this and other applications.

    For programming help though, I use my HP-41cx with the 32-bit boolean and base-conversion functions in the Advantage module. I have wondered what others use.

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.