32SII new "old-bug"

[J-F Garnier]

In my current investigation of the 32S/32SII machines, a new "old-bug" has been found recently by my friend Mike (Stgt) (who is unfortunately no more participating to this forum).
To my knowledge, this bug has never been reported (correct me if I'm wrong).

So here is the bug description:

do CLVARS, CLΣ to start from a known state,
do 2 ENTER 3 Σ+ to create the statistics registers,
then press MEM , VAR to review the summation registers,
you should see n=1.0000
In this MEM/VAR submenu, it is allowed to press ENTER to enter a variable value on the stack,
so press ENTER, and you get an unexpected "INVALID (i)" error. This is the bug.

ENTER works correctly with all the other variables, including the ΣX, ΣY, ΣX2, ΣY2, ΣXY sum registers.
But not for the register 'n'.
Where does it come from?

Locating the source of the problem by exploring (i.e. disassembling) the ROM shows that the code is doing "RCL (i)" instead of recalling 'n'.
This is because the same code that is managing the "RCL var" commands, including "RCL (i)", is also used to recall the values inside MEM/VAR including the stat sum registers.
And the code for the register 'n' is 28, the same as the code for (i) . That is:

Code:

Codes              1  2  3 ... 26  27  28   29 ... 33
"RCL var" coding   A  B  C ...  Z   i  (i) -- N/A  --
register coding    A  B  C ...  Z   i   n  ΣX ... ΣXY

This was likely done in this way to pack the ROM code, and it is was a good decision of the programmer since nobody noticed any problem with it (if I'm not wrong) for more than 30 years.
The bug is present in the two known versions of the 32SII.
Note that the 32S doesn't allow to access the summation registers inside MEM/VAR, so doesn't have the problem.

BTW, if you are (like me) interested in exploring old machine code, an image of the 32SII version B (aka ROM 1 from the annunciator set at the end of the selftests) is now available at the well-known art place.

J-F

[Massimo Gnerucci]

(12-15-2021 09:03 AM)J-F Garnier Wrote:  BTW, if you are (like me) interested in exploring old machine code, an image of the 32SII version B (aka ROM 1 from the annunciator set at the end of the selftests) is now available at the well-known art place.

Thank you!
Just downloaded and converted.

[rprosperi]

(12-15-2021 09:03 AM)J-F Garnier Wrote:  In my current investigation of the 32S/32SII machines, a new "old-bug" has been found recently by my friend Mike (Stgt) (who is unfortunately no more participating to this forum).
To my knowledge, this bug has never been reported (correct me if I'm wrong).

Thanks for sharing this J-F, and thanks also to Mike for finding and relaying the details!

It's amazing this was never found, or at least not reported, in > 30 years. Although a somewhat obscure procedure is needed to uncover it, it seems that someone may have tried this along the way; perhaps it was found and reported to HP, but never publicly acknowledged, and certainly not sufficient to warrant another ROM update.

[Ross Barnes]

Thank you for the bug description as well as the heads up on the new art work.

Ross Barnes

[Joe Horn]

(12-15-2021 01:37 PM)rprosperi Wrote:  ... Although a somewhat obscure procedure is needed to uncover it ...

Actually, unless I'm mistaken, the above setup is not required to see the bug. It seems that ANY attempt to recall the "n" statistics register by pressing ENTER when n is displayed in the MEM/VAR catalog will always fail. If (i) points to an existing register, then pressing ENTER when n is displayed will recall (i) to the stack instead of n. If (i) does not exist, then pressing ENTER when n is displayed will generate an error.

Try it. Just make sure that n exists, and make sure that (i) points to some existing register. Then MEM/VAR, down-arrow to n, and press ENTER. Now try again with (i) not pointing to an existing register. No other setup or procedure is needed to see the bug in action. Since these conditions are not unusual, it amazes me that nobody noticed this bug before.

[J-F Garnier]

(12-15-2021 05:40 PM)Joe Horn Wrote:  Actually, unless I'm mistaken, the above setup is not required to see the bug. It seems that ANY attempt to recall the "n" statistics register by pressing ENTER when n is displayed in the MEM/VAR catalog will always fail. If (i) points to an existing register, then pressing ENTER when n is displayed will recall (i) to the stack instead of n. If (i) does not exist, then pressing ENTER when n is displayed will generate an error.

Yes, that's correct, the setup was just to reproduce the bug easily without ambiguity.

(12-15-2021 09:03 AM)J-F Garnier Wrote:  ENTER works correctly with all the other variables, including the ΣX, ΣY, ΣX2, ΣY2, ΣXY sum registers.
But not for the register 'n'.

It's wrong and actually worst !
ENTER on the ΣXY sum register seems to recall the value of A (or 0 if non existing) on the stack.
ENTER on ΣY2 seems to always recall 0.
No explanation for now.

Probably these bugs remained unnoticed because there is a much easier and faster way to recall the value of the summation registers with the SUMS menu.

J-F

[Alejandro Paz(Germany)]

a 16KB ROM would be a great fit for the small Lattice MachXO3 internal memory !, I can stop writing my own.... but the place says me nothing .

[J-F Garnier]

(12-15-2021 10:02 PM)J-F Garnier Wrote:  ENTER on the ΣXY sum register seems to recall the value of A (or 0 if non existing) on the stack.
ENTER on ΣY2 seems to always recall 0.
No explanation for now.

OK, the explanation was not too difficult to identify. This is the same root cause, the routine that is managing ENTER in the MEM/VAR menu shares the code managing the "RCL var" command, and the "var" argument is extracted from the command code by masking with 31 (0x1F), giving a range from 0 to 31 for the A..Z, i and (i) parameters.
But now with ENTER in MEM/VAR, the ΣY2, ΣXY sum registers have codes 32 and 33 (dec), giving 0 and 1 after masking. Code 1 corresponds to the variable A, but code 0 is not defined and the 32SII considers it as an non-existing variable and returns 0.

(12-16-2021 08:13 PM)Alejandro Paz(Germany) Wrote:  a 16KB ROM would be a great fit for the small Lattice MachXO3 internal memory !, I can stop writing my own.... but the place says me nothing .

Hint: Leonardo meets Emu42

J-F

[J-F Garnier]

Will you believe that the HP32SII has a severe bug that causes a MEMORY CLEAR condition ?

I found it last week. It's a quite simple (although unusual) condition, no complex setup.
I will disclose my finding at the end of the week, if you wish to try finding it yourself.
Maybe will you find a different condition.
In the meantime, I will investigate to find an explanation.

Hints:
it's related in some way to my previous finding above that lead me to my discovery,
the HP32S doesn't have the bug, and gives an error message in the same condition.

J-F

[KeithB]

I don't have the calculator, but is it related to the Standard Deviation of 1,2,3,4,5,6,7,8,9? (or whatever it is) I seem to recall it giving an error on my HP41.

[J-F Garnier]

(01-04-2022 03:15 PM)KeithB Wrote:  is it related to the Standard Deviation of 1,2,3,4,5,6,7,8,9? (or whatever it is) I seem to recall it giving an error on my HP41.

I don't know which kind of error you are thinking of.
For the 32SII bug, I'm meaning a 32SII legal operation (according to the manual), even if unusual or of little practical use, that causes not an error but an unexpected MEMORY CLEAR (like MEMORY LOST on the 41).

J-F

[J-F Garnier]

(01-03-2022 08:55 AM)J-F Garnier Wrote:  Will you believe that the HP32SII has a severe bug that causes a MEMORY CLEAR condition ?

So no bug hunters there? No 32SII experts?
Below is my finding, a never-reported bug that lasted for more than 30 years (unless I'm wrong, if so tell me please!).

-- CAUTION: trying the sequence below will clear your 32SII memory --

Short description:
Using SOLVE(i) or ∫FN d(i) with i=32 causes a MEMORY CLEAR.

Example:
Create an empty program: LBL A RTN ,
do FN= A and 32 STO i ,
then try SOLVE(i) .
The display freezes for some time with "SOLVING" then may display "SELECT FN", then any keystroke produces a MEMORY CLEAR.

Longer description and discussion:
SOLVE(i) is a legal and documented feature, on both the 32S and 32SII.
Although rarely used, it can be helpful to programmatically solve an equation for different variables using i=1 for A, 2 for B, etc.
It is used for instance in the TVM application program in the 32S manual.
The 32S accepts the values i=1..26 for the variables A..Z, but the 32SII also accepts the values 27 to 33 corresponding to the statistics summation registers.
For instance, on the 32SII, you (theoretically) can solve a programmed expression such as "RCL(i) x² 2 -" for any variable/register by setting i=1..33 and SOLVE(i).
It works for the registers 28 to 31 (n, Σx, Σy and Σx²).
It doesn't work for register 33 (Σxy), always saying NO ROOT FND.
For register 32 (Σy²), the 32SII crashes with a MEMORY CLEAR.

The cause is very similar to the MEM/VAR bug above: SOLVE(i) with i=33 tries to SOLVE for variable A instead (code 1 = 33 MOD 32), and SOLVE(i) with i=32 tries to solve for a non-existing variable of code 0. Doing that corrupts the system memory in such a way that the FN= setting is lost (thus the message SELECT FN) and the CMOS test word is corrupted causing a MEMORY CLEAR at the next keystroke.

The same also happens for the integration command ∫FN d(i).

Isn't this bug amazing?

J-F

[Vincent Weber]

Amazing indeed ! Thank you ! Another good reason to switch to Plus42

[Ross Barnes]

Thank you for the bug reveal...and with only 384 bytes of RAM the MEMORY CLEAR isn't so stressful.

If I understood your earlier explanation about masking with 0x1F: Is there one instance of the masking code being called multiple times or is the masking code repeated where needed throughout the ROM?

Since the SUMS menu for recalling statistics variables works am I correct to assume the (i) masking code is not used in that area of the ROM.

Do you happen to have a few ROM entry points you could share?

One thing I did learn trying to find your bug was that I can't indirectly set/clear/test a flag - something I always assumed was possible.

Thanks again!

Ross Barnes

[Thomas Radtke]

A new bug found after so many years ... congrats, J-F .

Used this calculator at university and most part of my career as physicist. Today I though I could have a look at the museum, and there's news about my old HP!