Online HP-35 Emulator - First scientific pocket calculator from 1972

[van2z]

I love building emulators. The HP-35 was quite fun because it actually has two separate CPUs - The HP Control & Timing chip and the HP Arithmetic & Register chip. 3 ROM chips, and no RAM chips. Here it is:

https://veniamin-ilmer.github.io/hp35/

I like to emulate each chip as accurately as possible, with all clock timings the same as the original.

It works in mobile and desktop. Desktop view shows register data.

As an imprecise but fun measure, I checked the compiled code's size of this HP-35 emulation vs my Busicom 141-PF emulation, which used the Intel 4004.

HP-35 was 39 KB. Busicom was 43 KB. Yet the most advanced math function in the Busicom 141-PF, was doing a square root.

[Johnh]

Thanks for posting this!

It's a fascinating insight to let us experience the state-of-the art calculator of 50 years ago. You show us how the pocket scientific was born fully formed and ready for work. Even today, any engineer could do a confident days work with this.

Interesting to see the slight lags in each operation, which i see on my recent Samsung and also on an older pc. Do you reckon the program approximately mimics the times taken by the real thing? I never have seen one myself. It shows how they pushed the available tech to create this very practical (but rather expensive) tool. It must have seemed like a true marvel when it started to appear in the design offices of the early 1970's.

[Thomas Klemm]

This is a very nice addition to the list of emulators of HP calculators.
Thank you very much.

---

I noticed a bug though: when pressing the 0 key it performs multiplication.
Both keys are mapped to the same number 30:

Code:

        } else if(e.keyCode == 48 || e.keyCode == 96) { //0
          pendingClicks.push(30);

Code:

        } else if(e.keyCode == 42 || e.keyCode == 106) { //*
          pendingClicks.push(30);

That should probably be 36 instead.

---

How hard would it be to emulate other processors?
It would be great to have e.g. the HP-15C running in a browser as well.

[van2z]

(12-25-2023 08:11 AM)Johnh Wrote:  Interesting to see the slight lags in each operation, which i see on my recent Samsung and also on an older pc. Do you reckon the program approximately mimics the times taken by the real thing? I never have seen one myself. It shows how they pushed the available tech to create this very practical (but rather expensive) tool. It must have seemed like a true marvel when it started to appear in the design offices of the early 1970's.

Per Jacques Laporte's calculations, here are the timings of each operation in the HP-35:

• floating point “+” and “-“(215 word times) = 60 ms,
• floating point “*” and “/” = 100ms,
• digit by digit ln and ex = 200ms,
• CORDIC trigo (tan, sin, cos) = 500ms.
  

My emulation should maintain the same timing on any device. One difference however, is what happens if you type many buttons too quickly at the same time. My emulation will remember the keys, and slowly feed them into the chips. However on the real thing, I think it would forget the keys? However it feels different physically pushing in numbers on the calculator, rather than clicking.

(12-25-2023 11:59 AM)Thomas Klemm Wrote:  This is a very nice addition to the list of emulators of HP calculators.
Thank you very much.

---

I noticed a bug though: when pressing the 0 key it performs multiplication.
Both keys are mapped to the same number 30:

Code:

        } else if(e.keyCode == 48 || e.keyCode == 96) { //0
          pendingClicks.push(30);

Code:

        } else if(e.keyCode == 42 || e.keyCode == 106) { //*
          pendingClicks.push(30);

That should probably be 36 instead.

---

How hard would it be to emulate other processors?
It would be great to have e.g. the HP-15C running in a browser as well.

Excellent find! Thank you Thomas Klemm, I have updated the code, it should be good now.

I would love to emulate other processors. It comes down to availability of ROMs and good documentation. We are lucky that the the HP-35 was well documented, and someone extracted the ROM. A lot of time is spent chasing down these details. That is the hard part. With excellent documentation, writing the emulator is simple.

[Gerson W. Barbosa]

(12-25-2023 11:59 AM)Thomas Klemm Wrote:  This is a very nice addition to the list of emulators of HP calculators.
Thank you very much.

---

I noticed a bug though: when pressing the 0 key it performs multiplication.

Also, ln is broken for arguments in the range ]0..1[:

8 7 8 ln 1 6 × ENTER↑ ln ÷ ln → ok!

2 ln ln → NOT ok!

[van2z]

(12-25-2023 01:50 PM)Gerson W. Barbosa Wrote:  Also, ln is broken for arguments in the range ]0..1[:

8 7 8 ln 1 6 × ENTER↑ ln ÷ ln → ok!

2 ln ln → NOT ok!

You are right. Thank you for finding this. I will debug, it will take me some time.

[Thomas Klemm]

(12-25-2023 12:31 PM)van2z Wrote:  I have updated the code, it should be good now.

This was quick: about half an hour.
And that at Christmas.
I can confirm that the bug is fixed.

(12-25-2023 12:31 PM)van2z Wrote:  I would love to emulate other processors. It comes down to availability of ROMs and good documentation.

I can only recommend Eric Smith's nonpareil emulator:

Quote:In this release, the following calculators are simulated:

    Classic series:    35, 45, 55, 80
    Woodstock series:  21, 22, 25, 27
    Spice series:      31E, 33C, 34C, 37E, 38E, 38C
    Nut series:        41CV, 41CX
    Voyager series:    11C, 12C, 15C, 16C

    Modified Voyager:  15X

Since you're writing your emulator in Rust, I'm assuming you're also familiar with C.
So the documentation is in the source code.
But my understanding is that all of these processors have gradually evolved from the original processor used in the HP-35.
So if you know that one, you kind of know them all.

[Thomas Klemm]

Here's another bug: e^x with negative argument returns always 0.
It might be related to Gerson's finding.

[Sylvain Cote]

2 ENTER 4 x^y gives 15.99999999 instead of 16

[Gerson W. Barbosa]

(12-25-2023 03:36 PM)Sylvain Cote Wrote:  2 ENTER 4 x^y gives 15.99999999 instead of 16

This is not a bug, just a limitation of the original algorithm. That’s exactly what I get on my HP-35 (serial # 1302S84772).

[Gerson W. Barbosa]

(12-25-2023 02:10 PM)van2z Wrote:  

(12-25-2023 01:50 PM)Gerson W. Barbosa Wrote:  Also, ln is broken for arguments in the range ]0..1[:

8 7 8 ln 1 6 × ENTER↑ ln ÷ ln → ok!

2 ln ln → NOT ok!

You are right. Thank you for finding this. I will debug, it will take me some time.

No problem! Meanwhile just do 2 ln 1/x ln CHS

[van2z]

Thank you all for your input.

I have discovered the issue.

In the 0 - c - 1 inversion instruction, I accidentally happened to subtract the carry twice. I have since corrected this. The ln(x) for 0 to 1 and e^x for negative x should be fixed.

[Thomas Klemm]

(12-25-2023 01:50 PM)Gerson W. Barbosa Wrote:  8 7 8 ln 1 6 × ENTER↑ ln ÷ ln

I like how you sneaked in yet another solution to a \(\pi\) approximation contest into this bug report.

[Steve Simpkin]

(12-26-2023 07:23 PM)Thomas Klemm Wrote:  

(12-25-2023 01:50 PM)Gerson W. Barbosa Wrote:  8 7 8 ln 1 6 × ENTER↑ ln ÷ ln

I like how you sneaked in yet another solution to a \(\pi\) approximation contest into this bug report.

And an approximation accurate to 10 digits as well.

[Gerson W. Barbosa]

(12-26-2023 07:23 PM)Thomas Klemm Wrote:  

(12-25-2023 01:50 PM)Gerson W. Barbosa Wrote:  8 7 8 ln 1 6 × ENTER↑ ln ÷ ln

I like how you sneaked in yet another solution to a \(\pi\) approximation contest into this bug report.

That’s an old one. I found it years ago with help of the HP-32S solver. I thought it might make for a good test for the ln function for 10-digit calculators, but I was wrong as it failed to detect that particular bug.
Some new approximations have been placed in the Test forum, together with some not so new.

[Thomas Klemm]

(12-26-2023 09:43 PM)Gerson W. Barbosa Wrote:  That’s an old one.

This is still my favourite:

Quote:Just an interesting result:

2 SQRT 23 + XEQ GL XEQ GL

[EdS2]

(12-25-2023 01:50 PM)Gerson W. Barbosa Wrote:  8 7 8 ln 1 6 × ENTER↑ ln ÷ ln

This is a completely unexpected and remarkable pi approximation - how did you find it? Is there any significance - surely getting 10 digits of closeness out of 5 digits of input can't just be a numerical coincidence?

[John Keith]

(12-30-2023 04:46 PM)EdS2 Wrote:  ... surely getting 10 digits of closeness out of 5 digits of input can't just be a numerical coincidence?

I can't see how the number of digits affects accuracy in this case, the numbers entered are both integers. It is an impressive approximation, on 12-digit calculators it is only off by 18 ULPs.

[Gerson W. Barbosa]

(12-30-2023 04:46 PM)EdS2 Wrote:  

(12-25-2023 01:50 PM)Gerson W. Barbosa Wrote:  8 7 8 ln 1 6 × ENTER↑ ln ÷ ln

This is a completely unexpected and remarkable pi approximation - how did you find it? Is there any significance - surely getting 10 digits of closeness out of 5 digits of input can't just be a numerical coincidence?

In the thread linked by Thomas Klemm above, there's a link to this paper. At page 23 therein there's this approximation by Simon Plouffe:

\(\pi \approx \) 689/396/ln(689/396)

When I saw it I thought of a more slightly complex approximation and tried it on the HP-32S Solver:

LN(A×LN(B)÷LN(A×LN(B)))=\(\pi \)

When making A=16 and solving for B I got B=877.999998596 , which I found a remarkable result (I'm doing this on my remaining HP-33s because my HP-32S is not working properly anymore). I don't remember whether I used Markovitch's method on it, but I suspect it gets a better score than Plouffe's approximation. It was about 14 years ago, judging by this thread.

Regards,

Gerson.

[EdS2]

Many thanks for the extra info and the link to Markovitch' 2004 paper!