HP-15C CE woes: 1 bug, 2 limitations, 3 questions

[brouhaha]

(08-08-2023 11:07 PM)Voldemar Wrote:  Problem with E and F

It took me a while to understand your point, since your post included the correct results rather than the incorrect display of the calculator. Anyhow, the fact that the problem occurs with 0xe and 0xf tells me with a fairly high degree of confidence where the problem is occurring in HP's Nut emulation code, and that I may in fact indirectly bear a very small amount of responsibility for it.

The actual Nut chip had binary and BCD modes, and operated bit-serially. (The later Saturn changed to digit-serial.) When I wrote nsim/Nonpareil (which is NOT used in any HP product), I implemented the arithmetic as digit-by-digit, which was fine because Nonpareil runs on systems thousands of time faster than the original HP calculator. However, I had some experimental C code that could do a full-word (14-digit) BCD addition in parallel using 32-bit or 64-bit binary arithmetic. The method was apparently originally developed by IBM in the early 1960s, and is generally much faster than digit-by-digit.

At about that time, Cyrille at HP was working on the first ARM-based 12C firmware, and I shared my C function with him. He extended the code to handle 16 digits, and HP patented that, but the Voyager calculators don't need that. However, both Cyrille and I were worried that the parallel BCD arithmetic would not get the same results as a Nut if an operand contained non-BCD digits (A through F). I had studied that issue and come to the conclusion that the 12C never does such a thing, and told Cyrille that I thought it wasn't a problem for the 12C. I suspect that he probably conducted his own testing as well.

Unfortunately it appears that the decimal display conversion in the 16C does do exactly that.

The word-wide parallel BCD addition involves an intermediate result to which is added 0x66666666666666. If a digit going into that is 0xA through 0xD, a carry correction will occur. However, if a digit is 0xE or 0xF, then effectively there are two (decimal) carries, and the parallel addition algorithm doesn't handle that, losing one of the carries.

I haven't verified that this is the exact problem on the 15CE, but based on evidence it seems highly likely.

If this is the case, there are a few options for fixing it. My top two would be:

1) Test the operands of BCD addition (and subtraction) for non-BCD digits, and use a slower digit-by-digit code path if any are present. A parallel digit test is possible, but there would still be some slowdown on every BCD add/subtract. Advantage: this could fix any other as-yet undetected BCD arithmetic problems.

2) identify the specific add instruction in the 16C microcode that is having the problem, and have the Nut emulator (ARM code) special case just that specific instruction at that location. Advantage: this could be done with no slowdown.

I have reverse-engineered a fair bit of the 16C microcode, but not yet the integer display conversion routine. However, I know where that code is, and what influences it, so I probably could find the specific add instruction relatively quickly if I had to. I have not reverse-engineered HP's ARM code, so patching that could take me longer.

(I am potentially available for commercial consulting regarding fixing this problem.)