Which calculators had no known bugs?

[Thomas Okken]

(08-05-2017 04:51 PM)Sadsilence Wrote:  2^x values are so common to programmers and so easy to handle for processors of all kinds, that I somehow expected a special treatment.

On binary platforms, yes -- but the calculators that have been mentioned in this thread so far all use BCD internally. You could expect special treatment of powers of 10 in such environments, but powers of 2, not so much.

[Joe Horn]

(08-05-2017 11:07 PM)Geir Isene Wrote:  I'm interested in this one:

HP-65
(a) Lampman Split Logic. More of an unintended feature than a bug; it allows three-way branching by splitting the shift away from shifted functions. Discovered by and named after Dean Lampman.

How does that work?

An example is worth a thousand words. Here's a "split logic" three-way branch:

1. 0
2. g X<>Y
3. GTO
4. g X≠Y
5. g X>Y
6. 3
7. 2
8. 1

This routine is equivalent to the following pseudo-code:

IF X>Y THEN GTO 3
IF X<Y THEN GTO 1
IF X=Y THEN GTO 2

Remember, the HP-65 skips TWO steps if the test is false.

What "Lampman Split Logic" does is insert one or more logical comparisons between a command prefix (e.g. GTO or STO) and its argument. It worked for all the commands (except RTN and SST) on rows 2 and 3 of the HP-65 keyboard. It therefore allowed not only short three-way branching, but also short three-way storing, and any number of combinations of functions (e.g. perform a SIN or COS depending on the result of a test) with minimal program steps.

The original write-up can be found in 65 Notes, V2 N1 P7-8 (January 1975).

[PANAMATIK]

Still the HP-21/22/27/19C/29C are in the race for bug free calculators.

I consider mathematical inaccuracies not as a bug, if it is the normal result of the underlying algorithm.

Bernhard

[Dan]

Quote:Of course you are right and it has to do with internal precision and formula used for all exponantial calculations.

Not necessarily, I have just written assembly routines for 2^x, 10^x and e^x for the "AriCalculator" (see main thread in "not HP related" section of forum) that use CORDIC methods and not x^y = e^(ylnx).

[toml_12953]

(08-06-2017 05:40 AM)Joe Horn Wrote:  

(08-05-2017 11:07 PM)Geir Isene Wrote:  I'm interested in this one:

HP-65
(a) Lampman Split Logic. More of an unintended feature than a bug; it allows three-way branching by splitting the shift away from shifted functions. Discovered by and named after Dean Lampman.

How does that work?

An example is worth a thousand words. Here's a "split logic" three-way branch:

1. 0
2. g X<>Y
3. GTO
4. g X≠Y
5. g X>Y
6. 3
7. 2
8. 1

This routine is equivalent to the following pseudo-code:

IF X>Y THEN GTO 3
IF X<Y THEN GTO 1
IF X=Y THEN GTO 2

Remember, the HP-65 skips TWO steps if the test is false.

What "Lampman Split Logic" does is insert one or more logical comparisons between a command prefix (e.g. GTO or STO) and its argument. It worked for all the commands (except RTN and SST) on rows 2 and 3 of the HP-65 keyboard. It therefore allowed not only short three-way branching, but also short three-way storing, and any number of combinations of functions (e.g. perform a SIN or COS depending on the result of a test) with minimal program steps.

The original write-up can be found in 65 Notes, V2 N1 P7-8 (January 1975).

I understand the cases where X>Y and X<Y but how does X=Y work? The way I see it, the execution would be step 1, 2, then, since g X<>Y is false, step 5 is next then, since g X>Y is false, step 8 is next just putting a 1 in the display and not going anywhere. What have I misunderstood?

[PANAMATIK]

(08-06-2017 07:41 AM)Dan Wrote:  

Quote:Of course you are right and it has to do with internal precision and formula used for all exponantial calculations.

Not necessarily, I have just written assembly routines for 2^x, 10^x and e^x for the "AriCalculator" (see main thread in "not HP related" section of forum) that use CORDIC methods and not x^y = e^(ylnx).

Exactly, if you chose an algorithm that is superior to another, it gives better results, but the previous algorithm can still be bug free.

Bernhard

[rprosperi]

(08-06-2017 10:31 AM)toml_12953 Wrote:  I understand the cases where X>Y and X<Y but how does X=Y work? The way I see it, the execution would be step 1, 2, then, since g X<>Y is false, step 5 is next then, since g X>Y is false, step 8 is next just putting a 1 in the display and not going anywhere. What have I misunderstood?

"g X<>Y" is not a test, it is simply exchange X and Y registers ( [g] [7] on an HP-65)

When X=Y, the test on line 4 fails, so it skips 2 steps and proceeds to line 7 to complete the command GTO 2.

[SlideRule]

(08-06-2017 10:31 AM)toml_12953 Wrote:  I understand the cases where X>Y and X<Y but how does X=Y work? The way I see it, the execution would be step 1, 2, then, since g X<>Y is false, step 5 is next then, since g X>Y is false, step 8 is next just putting a 1 in the display and not going anywhere. What have I misunderstood?

In GRAPHIC format(s), hope it helps.

[attachment=5083]

BEST!
SlideRule

[toml_12953]

(08-06-2017 01:54 PM)rprosperi Wrote:  

(08-06-2017 10:31 AM)toml_12953 Wrote:  I understand the cases where X>Y and X<Y but how does X=Y work? The way I see it, the execution would be step 1, 2, then, since g X<>Y is false, step 5 is next then, since g X>Y is false, step 8 is next just putting a 1 in the display and not going anywhere. What have I misunderstood?

"g X<>Y" is not a test, it is simply exchange X and Y registers ( [g] [7] on an HP-65)

Ah! That explains all. I wasn't familiar with the notation. Thanks!

[toml_12953]

(08-06-2017 05:42 PM)SlideRule Wrote:  

(08-06-2017 10:31 AM)toml_12953 Wrote:  I understand the cases where X>Y and X<Y but how does X=Y work? The way I see it, the execution would be step 1, 2, then, since g X<>Y is false, step 5 is next then, since g X>Y is false, step 8 is next just putting a 1 in the display and not going anywhere. What have I misunderstood?

In GRAPHIC format(s), hope it helps.



BEST!
SlideRule

Thanks! Between you and Bob P, I'll get the hang of this yet! I thought "g x<>y" was a test for x<>y instead of just exchanging the X and Y stack registers.

[PANAMATIK]

Finally I discovered a bug in the HP-29C, which I didn't have seen mentioned before.

If you enter all 98 program steps numbers and run, the program can't be interrupted. You have to switch off the calculator.

This is also the case in my HP-29C Low Power emulation, but because it never can be switched off even when the batteries are removed, it hangs forever. I had to add a special "Reset" procedure for this case.

Bernhard

[Dieter]

(11-13-2017 01:33 PM)PANAMATIK Wrote:  Finally I discovered a bug in the HP-29C, which I didn't have seen mentioned before.

If you enter all 98 program steps numbers and run, the program can't be interrupted. You have to switch off the calculator.

What? Do you want to say that any program that uses all 98 steps cannot be interrupted?

Dieter

[Thomas Okken]

(11-13-2017 06:54 PM)Dieter Wrote:  

(11-13-2017 01:33 PM)PANAMATIK Wrote:  Finally I discovered a bug in the HP-29C, which I didn't have seen mentioned before.

If you enter all 98 program steps numbers and run, the program can't be interrupted. You have to switch off the calculator.

What? Do you want to say that any program that uses all 98 steps cannot be interrupted?

Dieter

I think he meant: fill program memory with numbers (0-9).

It sounds like the 29C will keep running when you try to interrupt a program that is in number entry mode, and only stop once it reaches a non-number instruction. Sounds like a good feature, and it anticipates the single-line non-interruptible numbers in the 41C.

I can't say I ever noticed this behavior in my 19C, but then again I never looked for it, either. Once you are aware of it, filling program memory with numbers is a fairly obvious potential bug case to check.

[Sylvain Cote]

(11-13-2017 01:33 PM)PANAMATIK Wrote:  If you enter all 98 program steps numbers and run, the program can't be interrupted. You have to switch off the calculator.

Bernhard,
I do not see this behaviour on my HP-29C (sn: 1908S22721)
My test program consist of 98 lines of + instructions (key code: 51)
I fill up the stack with 1, then run the program.
The adding program run indefinitely because of the loop around, but I can stop and restart its execution at will.
Sylvain

[Sylvain Cote]

(11-13-2017 07:37 PM)Thomas Okken Wrote:  I think he meant: fill program memory with numbers (0-9).
It sounds like the 29C will keep running when you try to interrupt a program that is in number entry mode, and only stop once it reaches a non-number instruction.
Sounds like a good feature, and it anticipates the single-line non-interruptible numbers in the 41C.

Bernhard & Thomas,
Now I sees it, I fill-up the memory with 1, started the program and there you go, not interruptible without using the on/off switch.
Great find Bernhard!
Sylvain

[teenix]

(11-13-2017 01:33 PM)PANAMATIK Wrote:  Finally I discovered a bug in the HP-29C, which I didn't have seen mentioned before.

If you enter all 98 program steps numbers and run, the program can't be interrupted. You have to switch off the calculator.

This is also the case in my HP-29C Low Power emulation, but because it never can be switched off even when the batteries are removed, it hangs forever. I had to add a special "Reset" procedure for this case.

Bernhard

That is true and it isn't true. :-)

I cannot fully test this because I do not have a real HP-29c.

Looking at the microcode, during a running program, the HP29c doesn't test for a key press when it is executing these programmed keys...

0 - 9, CLx, EEX and CHS

Therefore, if your program, which uses all steps, has only these keys, it will not be able to be stopped. This is unlikely in a real program though.

Any other programmed key allows testing for a keypress in the microcode and therefore stops the program.

The power switch is always supposed to stop a running program. As far as I can tell during a running program, there is nothing in the microcode that tests Status Flag [5], which is the power switch test, so there must be some other mechanism to stop the program.

In my emulator, I assumed that Status Flag [2] is cleared by hardware on switch off. This always stops and resets a running program and the calculator jumps into it's power off code loop.

cheers

Tony

[PANAMATIK]

(11-13-2017 08:13 PM)teenix Wrote:  That is true and it isn't true. :-)

Looking at the microcode, during a running program, the HP29c doesn't test for a key press when it is executing these programmed keys...

0 - 9, CLx, EEX and CHS

Tony

Thanks Tony for this exquisite deep look inside the code.

The intention of the HP engineers now becomes clear. If you have a sequence of number entry in your program like 123.45 CHS EEX 5, R/S (manual stop) should not break the number into two parts when restarted. Great idea.

I admit that it is very unlikely to have a nonsense program, which consists only of numbers. Therefore nobody has found this endless loop in the last 40 years. I did, because I tested the correct storage of a complete 98 step program in the LP circuit flash memory, entered all 1s and accidentally started the program.

Bernhard

[Gene]

(08-05-2017 04:51 PM)Sadsilence Wrote:  Of course you are right and it has to do with internal precision and formula used for all exponantial calculations. But 2^x values are so common to programmers and so easy to handle for processors of all kinds, that I somehow expected a special treatment.

Gene: Life is short and ROM is full.

On a semi-more serious note, I'm always amazed that so many things worked as well as they did. The **short** bug lists on these older models is a fabulous achievement.

[ThomasF]

Hi!

Going through my papers from "back then", I found a list of some bugs in the HP34C, but I have found no reference to them while searching the forums etc.

Some examples:

If you in PRGM-mode enter "GTO . 9 9 A" followed by a number, 'A' or 'B', you then enter the corresponding hexcode 0xA0-0xAB into program memory.
Eg. code 0xA0 correspond to 'STO - 0'. Similar with "GTO . 9 9 B" you can enter code 0xB0 - 0xBB.

Another one is that if you press "GTO . 9 9 f 9" in that order, then the numbers 1-9, +, -, *, / and X<>Y will not work anymore, either in RUN or PRGM mode. To get out of this state, press any other key.

I can also get the keyboard "shifted", that functions are moved around on the keyboard, eg. that pressing 'f TAN' results in 'f COS', or that "f integrate" is replaced by 'f TAN'. This also works in PRGM-mode - so that pressing eg. 'g e^x' results in 'g GRD' being enterid in PRGM mode.

There are also some other bugs that involvs switching to PRGM-mode while holding a key, but unfortunately I no longer have a 34C in my possesion so I can't verify these.

But I can reproduce the other bugs on the go34c Android emulator, and my note says that I have tried on several other 34C devices from different build dates and all of them had the bugs on my list.

Are these known in broader public? Someone interested in the complete list?

Best regards,
Thomas

[rprosperi]

(11-18-2020 07:17 AM)ThomasF Wrote:  [snip]

Are these known in broader public? Someone interested in the complete list?

Best regards,
Thomas

News to me, so yes please, the complete list is of interest.