Reverse-engineering and simulating Sinclair's amazing 1974 calculator with half the ROM of the HP-35

I've reverse-engineered the Sinclair Scientific calculator. The remarkable thing about this calculator is they took a simple 4-function calculator chip and reprogrammed its 320-instruction ROM to be a full scientific calculator. By looking at the chip, I've extracted the original code, reverse-engineered how it works, and written a JavaScript simulator that runs the original code and shows what the calculator is doing internally.

The simulator is at My earlier TI calculator simulator is at (The image above is courtesy of Hackaday.)


  1. Just in case you do not already have it:

  2. My favorite part of the manuals is that they have the 1,2,3 keys arranged backwards in the drawings.

  3. Ciao Ken!
    This calculator has been my dram in my childhood for long years, but for a ton of reasons I never have had the opportunity to put my hands on it...
    I think you just did a *FANTASTIC JOB* Ken.
    I re-read the whole page, and the simulator you kindly posted ket me touch the dream of having that calculator within my grasps... an unbelievable opportunity for me... Thanks!
    A hint: why not put a nice blue-violet background to the display, instead of black?
    Also digit lenses could be simulated a bit...
    Of course these are only cosmetic changes... nothing to do with the real ard work you did!!!

  4. Nice work, enjoyable article!

    The trig algorithm is just a simplified form of CORDIC, no? Single stage, base 1000, using .001 as an approximation of arctan .001.

    Three decimals is poor accuracy compared to more expensive competitors, but better than slide rules. Likely Sinclair was going after that large market.

  5. I've been reading through New Scientist magazines from 1975 and came across a couple of articles about strange Sinclair Scientific calculator behaviour - apparently it 'counts forward' or 'counts backwards' all by itself on occasion. How could that be? Is it reproducible on the simulator?

  6. I had some time to follow along more closely and the constant you published as 229.15 should be 229.105 ?

  7. David: Due to the way they calculate the constant, they end up with 229.15, not 229.105 which would be more accurate. (I stepped through the log calculation to verify, and 229.15 is what ends up in the register.) My assumption is that since 4 digits accuracy is all they were trying for, they were okay with this.