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

[Valentin Albillo]

.
Hi, all,

After more than a week using, perusing and "abusing" my new HP-15C CE, there's a few personal comments I want to share and a few questions I want to ask, namely:

Note: The TLDR ("Too long, didn't read") people amongst you would better go elsewhere. You've been warned.

The one bug:

The undocumented HP-16C mode's DEC bug. This is NOMAS, so absolutely don't ask Moravia/Royal about it (lest they might not include any undocumented features in future releases if they get pestered now,) but I'm asking a number of itching questions related to this below, because although this was a most generous, most wonderful Easter Egg, as it currently stands it's deeply flawed verging on unusable, at least in DEC mode.

I strongly feel like this is akin to the infamous Pause bug in the LE, in the sense that we're left wondering how on Earth wasn't that bug noticed while testing and retesting the machine prior to release. It isn't an obscure bug in some rarely-used functionality, on the contrary it's about one of the first functions you'll use in any looping program used for test puposes, to watch how many loops have been executed already or else are still pending.

It certainly should've been noticed at once, most any decent test suite would have made it obvious, and if you're never going to offer an update, ironing out such bugs that noticeably impact the usability should be but mandatory.

Same here. Testing the embedded HP-16C, even if just a little, should have immediately revealed that DEC mode is critically flawed and that renders the embedded 16C unusable because DEC mode is so essential. Immediately. Thus, we're left wondering about the quality and thoroughness of the testing. That is, if there was any testing at all, which begins to seem unlikely ...

See my questions below.

The first limitation:

The original HP-15C had a maximum 448 steps for programs but using all of them would leave only 3 registers for data, which are indexes intended for other purposes (loops, indirection, access to matrix elements.) so not really suitable for data storage. Furthermore, a number of instructions require 2 bytes each, so in practice the longest program you'd use would be ~ 250-300 steps at most, and the 25 available labels were usually more than enough, plus you could also try and re-use some of them. So far so good.

But now, with the CE/192 extended memory mode you have 3x the memory and thus up to 1,344 program steps. Even if using just 900 steps max (and still having about 66 data registers available) you might be tempted to create a big program and/or include many short ones in that much room, but the subsequent problem is that you'll have to carefully modify them to cater for duplicate labels. In short, having only 25 labels is quite a serious limitation now. And there's a possible additional problem with that much program memory in use, see the questions below.

Anyway, I find it sad that HP didn't consider including the instructions BGTO/BGSB (backwards GTO/GSB,) identical to GTO/GSB except that they would search backwards for the label instead of forwards (so code like the following would've been possible,) alleviating or completely voiding the need for additional labels, with minimum microcoding and ROM space needed to implement both:
         ...
    --> LBL 0
    |     some loop
    --- BGTO 0       {backwards search}
         ...
        GTO 0 ---    {forwards search}
        ...     |
    --> LBL 0 <--
    |     some loop
    --- BGTO 0       {backwards search}
         ...

The second limitation:

The original HP-15C had 64 registers (elements) to share among five matrices, A-E, and five seemed more than enough, less than 13 elements per matrix on average so no use for having 6 or more matrices at the same time, simply too few elements per matrix, and that even assuming no programs at all.

But now, with the 192 registers provided by the CE/192 mode, there are practical cases where the limit of max 5 matrices at the same time is exasperatingly restrictive, e.g. you can't have, say, a 4-block partitioned matrix and easily use concise, fast block operations to work with it because of the 5-matrices limit, so you're having to jump through far too many hoops and annoyances to try and succeed.

Unless I'm wrong (I'd like to!,) this limitation can't realistically be removed by patching the ROM because having more matrix descriptors would drastically impact the number and mapping of keycodes to instructions, and the only workaround I can think of must be applied strictly on a case-by-case basis, if it works at all.

The three questions:

These are for the microcode gurus and knowledgeable experts in HP-15C ROM matters, you know who you are:

1) The HP-41C GTO/XEQ instructions, when branching to non-global labels would search once, then (if in range) they'd record some info about the label's location in the GTO/XEQ instruction itself so that further execution of those instructions wouldn't need to search again but would immediately branch to the label. The question is:

Obviously, the 15C microcode doesn't work like that but has to search for the label every time, in which case a (possibly short, intended to be fast) loop anywhere in program memory would have to search (wrapping around if necessary) all of program memory to find its label, every time ? (BTW, the BGTO/BGSB instructions I mentioned above would also avoid this)

If a long program and/or a set of shorter programs are loaded into the 900+ program steps available in the CE/192, this could possibly greatly slow down all loops, right ? If so, that would make it unadvisable to have too many steps occupied in program memory, lest all loops would be negatively affected by the long searches needed to find their labels.

2) The "Easter Egg" HP-16C mode is buggy, and DEC mode seems to be unusable. What caused the bug ?. Can you gurus/experts inspect the code and discover what's happening ? Is it already known but not made public yet ?

Would the person or persons who actually embedded the HP-16C's ROM in the CE's firmware possibly shed some light on this ?

3) Is the HP-15C CE upgradable by the user (or someone else offering the service,) using this or that cable and this or that connection to a laptop, say ? And if yes, could the embedded HP-16C's buggy code be patched and uploaded to the CE ?

If that's not possible now or in the near future, can/could/would some of the gurus/experts who know what causes the bug suggest some workaround that would make DEC mode (and thus the whole 16C emulation) usable again ?

That's all. All apropos answers, constructive comments, sensible suggestions or original opinions are warmly welcome.

Regards.
V.

[EdS2]

(08-08-2023 05:34 PM)Valentin Albillo Wrote:  The undocumented HP-16C mode's DEC bug.

For the record, mentioned here by Joe Horn and with detail here:

(08-07-2023 08:15 AM)Joe Horn Wrote:  

(08-07-2023 07:59 AM)ThomasF Wrote:  Is there any more info on this bug?

It only seems to happen in DEC mode. Example: repeatedly pressing the 1 key should make 1, then 11, then 111, and so on, appear. But instead, the following numbers SEEM to appear:
1
11
105
1111
11111
111111
1086535
11111111
110717895
1111111111
11111111111
111010447815
and so on, nonsensically but repeatably. When the wrong number appears, it's actually the correct value internally... it's only displayed incorrectly. It's displayed correctly in HEX, OCT, and BIN modes.

However, perhaps we should discuss this bug in its own thread so that large Fibonacci numbers can continue to be discussed in this thread.

Another set of examples from Voldemar here:

(08-07-2023 09:50 AM)Voldemar Wrote:  

(08-07-2023 08:15 AM)Joe Horn Wrote:  repeatedly pressing the 1 key

Not only [1] key
222 gives 216 on the screen;
33333 -> -32203;
44444 -> -21092;
55555 -> -09885;
7777 -> 6241;
999 -> 903
DEC is not usable

I wonder if by thinking hard one could come up with some mechanism which would cause the binary to decimal display conversion to produce these incorrect representations. This is a mini-challenge of its own.

[brouhaha]

(08-08-2023 05:34 PM)Valentin Albillo Wrote:  3) Is the HP-15C CE upgradable by the user (or someone else offering the service,) using this or that cable and this or that connection to a laptop, say ? And if yes, could the embedded HP-16C's buggy code be patched and uploaded to the CE ?

It is entirely technically possible. Issues are:
1. There is no commercially available cable
2. It is unknown whether updated firmware will ever be made available by HP.

It is my speculation that the 16C issues are demonstrative of a bug in the Nut emulation code, as I doubt that HP has touched the 16C microcode at all. If this is the case, it raises the possibility that there could be very subtle effects on the 15C (and 12C) as well.

Possibilities for firmware fixes:
1. HP could fix it.
2. A third party could reverse-engineer the HP ARM firmware and fix it. (fairly difficult)
3. A third party could write or port a different Nut emulator to the HP hardware (less difficult, but could lose performance compared to the highly-optimized HP Nut emulator)

I am slowly working on #3, motivated less by bug fixes than by providing more advanced features.

[brouhaha]

Quote::
1
11
105
1111
11111
111111
1086535
11111111
110717895
1111111111
11111111111
111010447815
and so on, nonsensically but repeatably.

The incorrect entries are all failed BCD adjustment in the conversion between the internal binary representation and decimal. Note that every error is by an amount 6 x 16^n for a small non-negative integer n.

It's possible that there could be related error cases where the delta is the sum of 6x16^n terms for multiple values of.n.

(08-07-2023 09:50 AM)Voldemar Wrote:  Not only [1] key
222 gives 216 on the screen;
33333 -> -32203;
44444 -> -21092;
55555 -> -09885;
7777 -> 6241;
999 -> 903

These are a mix. Some are the 6x16^n problem, but I suspect the others, wheee the displayed value is negative, are actually "correct", as it appears that the calculator was in the default 16-bit two's complement mode.

[Voldemar]

DEC integer mode
Status 2-16-0000
14 -> 08
15 -> 09
Tried with other word sizes, in 1’s complement mode and in unsigned mode... 14 and 15 cannot be entered in DEC integer mode

[Voldemar]

Should check
Problems with numbers containing E and F in HEX mode
These cannot be written in DEC mode
?

[Voldemar]

These are correct results:
HEX DEC
E 14
F 15
EE 238
EF 239
EEE 3822
EEF 3823
EFE 3838
EFF 3839
FEE 4078
FEF 4079
FFF 65535
...
Let’s try
Unable
Also, for example, 12F2 or 45E8 will not work in DEC mode

[Voldemar]

Problem with E and F

[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.)

[ThomasF]

I tried some values as well and can confirm that any value that contains E or F in HEX mode fails in DEC mode.
But also decimal 60 and 61 (0x3C and 0x3D) and multiples of 80 after that, eg (60|61) + n*80 [n=0,1,....], so 60 and 61, 140 and 141 etc.
60 -> 5A (50 + 0xA = 50 + 10)
61 -> 5B (50 + 0xB = 50 + 11)
140 -> 13A (130 + 0xA = 130 + 10)
So definitely something to do with what was mentioned above.

Cheers,
Thomas

[EdS2]

Excellent info Eric!

[J-F Garnier]

(08-09-2023 03:42 AM)brouhaha Wrote:  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.

Perfect diagnostic, I didn't get it.

The pre-release 15C+ had exactly that problem, and it was fixed in the LE.
Carefully read this old 2012 message:
thread-210530-post-210733

Strange how people involved in the 15C+ (I wasn't) didn't remember that :-)
The forum archives are our memory.

J-F

[Voldemar]

(08-09-2023 05:58 AM)ThomasF Wrote:  I tried some values as well and can confirm that any value that contains E or F in HEX mode fails in DEC mode.
But also decimal 60 and 61 (0x3C and 0x3D) and multiples of 80 after that, eg (60|61) + n*80 [n=0,1,....], so 60 and 61, 140 and 141 etc.
60 -> 5A (50 + 0xA = 50 + 10)
61 -> 5B (50 + 0xB = 50 + 11)
140 -> 13A (130 + 0xA = 130 + 10)
So definitely something to do with what was mentioned above.

Cheers,
Thomas

Interesting
DEC mode
60, 61 give on the screen no DEC numbers, same with 140, 141. These four numbers do not have E or F in HEX mode. Are there others like this?

[Voldemar]

(08-09-2023 03:42 AM)brouhaha Wrote:  It took me a while to understand your point, since your post included the correct results rather than the incorrect display of the calculator.

Ah, You're right. I corrected the post

[ThomasF]

Try:
DEC
80
ENTER
ENTER
ENTER
60 (shown as 5A)
+
+
+
....

Most of the resulting values will end in 'A' (except those that have an 'F' or 'F' in the result (in HEX mode), the rest will end with 'A').

Same if you start with 61 (5B), most will end with 'B'.
But I have never seen 'A' or 'B' (or other hex digit) in the middle of the value, only at the end (and then only 'A' or 'B').

Cheers,
Thomas

[Voldemar]

(08-09-2023 09:19 AM)ThomasF Wrote:  Try:

Understanding the system when bugs appear becomes difficult

[ThomasF]

(08-09-2023 09:33 AM)Voldemar Wrote:  

(08-09-2023 09:19 AM)ThomasF Wrote:  Try:

Understanding the system when bugs appear becomes difficult

I think Eric described it quite well above.
I've seen two cases were we get a corrupt result.

1)
If the resulting HEX-value contains 'E' or 'F' the DEC-value is wrong.

2)
Values of the form 60+n*80 or 61+n*80 will also be wrong, the result R will be shown as R-10+0xA or R-11+0xB and the last digit (A or B) will be shown in HEX (except when R contains E or F in HEX mode, then rule 1 above is valid.

[KimH]

Dumb question of the day - What word length do you use here? It seems to be important (or I’m not getting the idea)

(08-09-2023 09:19 AM)ThomasF Wrote:  Try:
DEC
80
ENTER
ENTER
ENTER
60 (shown as 5A)
+
+
+
....

Most of the resulting values will end in 'A' (except those that have an 'F' or 'F' in the result (in HEX mode), the rest will end with 'A').

Same if you start with 61 (5B), most will end with 'B'.
But I have never seen 'A' or 'B' (or other hex digit) in the middle of the value, only at the end (and then only 'A' or 'B').

Cheers,
Thomas

[ThomasF]

I used 0 (ie 64 bits), but I don't think that is relevant for the problem itself (it might explain negative values in previous posts).

Edit: At least now when we know what Eric wrote above about the possible cause of the problem.

Cheers,
Thomas

[ThomasF]

Another bug/limitation/difference between 16CE and the original 16C is the momentarily showing of other base modes.

If eg in DEC-mode, you can press 'f' then HEX to temporarily see the value in Hex-mode.
On the original the value is shown as long as the key is pressed, but the 16CE only shows the value for some seconds, independent on how long you press the key.

One of the original features I use the most on the 16C ...

Cheers,
Thomas