32SII new "old-bug"

[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