HP-67/97 early ROM bugs

[brouhaha]

Thanks to someone else here, I finally have dumps of one of the early 97 ROM revs, and can do some analysis of the fixes.

The three "quads" in bank 0 from address 02000 through 07777 are shared between the 67 and 97. In both calculators, the two shared ROMs from 02000 through 05777 were revised after initial release to fix bugs. The well-known bug is with inverse trig functions, and is described on the MoHPC calculator variations page. The main fix is a change of two words at 04520 and 04524. The first changes a branch target, while the second changes a register exchange instruction from "a exchange b[w]" to "a exchange c[w]". I haven't yet analyzed exactly what was wrong.

There's another, perhaps more interesting bug fix that may have affected inverse trig, but probably affected other functions as well. The floating-point normalization routine, used to normalize the result of floating point operations so that the mantissa doesn't have leading zeros (unless the result is zero), is:

Code:

S3235: p <- 12
       if a[wp] # 0
           then go to L3244
       0 -> c[x]
L3241: return

L3242: a + 1 -> a[s]
       c - 1 -> c[x]
L3244: if a[p] # 0
           then go to L3241
       shift left a[wp]
       go to L3242

It tests whether there's a leading zero, and if so shifts the mantissa and loops, counting the number of times it shifts the mantissa of the A register using the sign digit a[s], and decrementing the exponent value held in the c[x].

The problem apparently was that the ACT is operating in decimal mode during that routine, but the number of shifts can actually be more than 9 when doing internal 13-digit arithmetic, in which case the count wraps from 9 to zero. Simple arithmetic operations invoked from the keyboard (or program step) only use 10-digit arithmetic; 13-digit arithmetic is used internally as part of more complex operations such as y^x and statistics, to avoid loss of precision, and the exponent is stored in another register during those operations. See "The New Accuracy: Making 2^3 = 8" by Dennis Harms in the November 1976 issue of HP Journal for background on that.

The fix is to surround the "a + 1 -> a[s]" with instruction to first set binary mode, and after the increment, set decimal mode. There wasn't room to put the extra two words inline, so the increment of A and decrement of C had to be replaced with a two-word jump to a patch location. Unfortunately there wasn't a patch location in the same ROM, so it jumps to the other ROM (04000-05777).

The routine that loads the natural logarithm of 2 starts at 03777, crosses the ROM boundary to 04000, where there are six NOPs, then the rest of the routine and a return. It's strange that there would be NOPs in the middle of the routine, but they were probably left over from some earlier bug fixes or something. The fix for this bug involves moving the second part of the routine which was from 04006 through 04022 down to 04000 through 04014, which then makes available six words at 04015 through 04022. That's exactly enough room for the bug patch.

The same fixes (both inverse trig and normalization) might have been necessary in the HP-91 (first use of the 13-digit arithmetic routines), the 92, 19C/29C, the 27, and perhaps other models as well. It appears that these fixes were done before the release of the 30 series so no later models should have the same bugs, though they have others (e.g., 41C "bug 4", computing SIN of small angles incorrectly).