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.