WIP: 16C firmware hack for more memory

[Garry Lancaster]

(01-28-2023 09:47 PM)brouhaha Wrote:  

(01-28-2023 10:38 AM)Garry Lancaster Wrote:  these could potentially be added as alternative f-Shifted functions on the top row and/or right column of the keyboard when in float mode, as all of the current functions in those positions are only active in integer modes.

That's a great idea!

Glad you like it

In fact, I suppose g-Shifted functions are also available for the top row keys (except ABS, also active in float mode), so sin/cos/tan/e^x/10^x/2^x and their inverses could fit on 6 keys, with plenty of space left for others like y^x, pi etc. Maybe there would even be room for some stats; f-shifted + and - would be a good place for accumulating.

That ought to keep you busy for a while, anyway

[Garry Lancaster]

In fact, looking in more detail at what's not active in float mode, there are also the f/g-shifted functions on keys 4/5/6, and WSIZE/</>. Plus there's the primary functions on A B C D E F available!

The nice thing about the top row (and to a lesser extent the right column) is that it would be easy to place a sticker above to indicate alternate functions in float mode.

More food for thought; there are also some inactive keys in integer mode: 1/x . EEX

The most useful missing integer feature IMO is something to query the current word size - perhaps that would be a good fit for EEX as it's next to STATUS. Or maybe just make STATUS programmable and have it return the current word size in programs.

Nothing else stands out to me as "missing" from integer mode, but other possibilities are perhaps RJ and MIRROR.

For float mode, FRACT and INT would really come in handy.

[Paul Dale]

(01-29-2023 09:33 AM)Garry Lancaster Wrote:  Nothing else stands out to me as "missing" from integer mode, but other possibilities are perhaps RJ and MIRROR.

Proper float to int conversion that does IP(float) and gives that value on the stack in integer mode.


Pauli

[Garry Lancaster]

(01-29-2023 10:31 AM)Paul Dale Wrote:  Proper float to int conversion that does IP(float) and gives that value on the stack in integer mode.

Yes, that would be nice as an additional function, or perhaps as an alternative flag-controlled mode when switching from float to integer. I would definitely want the current conversion method to remain, as that is invaluable for writing programs to convert to various floating-point representations.

[Paul Dale]

If only the calculator were good at extracting bit fields and doing bit manipulations, then the conversion would be easy to code

That it's changing from decimal to binary makes it a bit awkward IMO.

[brouhaha]

If I made more labels available, so that the 999 step program memory is more useful, would you rather have:

1) The standard 16 labels, but additionally LBL CHS <one hex digit>, and similarly GTO CHS snd GSB CHS, (32 labels total)

2) The standard 16 labels, but additionally allow LBL CHS <two hex digits>, and similarly GTO CHS and GSB CHS, for two-digit labels (256 labels total, as CHS 00-0F would be the same as the standard labels)

3) LBL, GTO, and GSB always require two hex digit argument, requiring 16C users to adjust to the new entry requirement (256 labels total, but consistent key entry)

[Boub65]

(01-30-2023 06:40 AM)brouhaha Wrote:  If I made more labels available, so that the 999 step program memory is more useful, would you rather have:

1) The standard 16 labels, but additionally LBL CHS <one hex digit>, and similarly GTO CHS snd GSB CHS, (32 labels total)

2) The standard 16 labels, but additionally allow LBL CHS <two hex digits>, and similarly GTO CHS and GSB CHS, for two-digit labels (256 labels total, as CHS 00-0F would be the same as the standard labels)

3) LBL, GTO, and GSB always require two hex digit argument, requiring 16C users to adjust to the new entry requirement (256 labels total, but consistent key entry)

Hello, I can't say for the 16C...
but for the 15C, I think that "just" doubling the number of labels with CHS would be enought for me.

One question for you : any way this improvements could make it to the DM1x/DM1xL series ?

[Garry Lancaster]

(01-30-2023 06:40 AM)brouhaha Wrote:  If I made more labels available, so that the 999 step program memory is more useful, would you rather have:

1) The standard 16 labels, but additionally LBL CHS <one hex digit>, and similarly GTO CHS snd GSB CHS, (32 labels total)

2) The standard 16 labels, but additionally allow LBL CHS <two hex digits>, and similarly GTO CHS and GSB CHS, for two-digit labels (256 labels total, as CHS 00-0F would be the same as the standard labels)

3) LBL, GTO, and GSB always require two hex digit argument, requiring 16C users to adjust to the new entry requirement (256 labels total, but consistent key entry)

Even with just 203 steps and careful re-use of labels which are only forward-referenced, I am currently using 12/16 in my standard configuration. For this reason, I would rule out (1) as I don't think it would be adequate for 999 steps.

I can see the appeal of both of the other options. I'd perhaps lean slightly to (2) as it gives you quick 2-keystroke access to execute up to 16 programs. But (3) would be great as well.

[brouhaha]

(01-30-2023 08:26 AM)Boub65 Wrote:  One question for you : any way this improvements could make it to the DM1x/DM1xL series ?

I'm hoping to do that, but I have to write the platform code to support the LPC1115. I don't plan to release it as a freely available flash update. I haven't determined the exact details. There will be other enhancements to justify the price.

This recent burst of activity started as a plan to make an enhanced 12C, and although most of my recent progress has been on the 16C, the enhanced 12C is still my top priority, as I think that has the best revenue potential.

[brouhaha]

(01-30-2023 08:39 AM)Garry Lancaster Wrote:  Even with just 203 steps and careful re-use of labels which are only forward-referenced, I am currently using 12/16 in my standard configuration. For this reason, I would rule out (1) as I don't think it would be adequate for 999 steps.

I suspected that, but it's good to have confirmation from a serious 16C user.

Quote:I can see the appeal of both of the other options. I'd perhaps lean slightly to (2) as it gives you quick 2-keystroke access to execute up to 16 programs. But (3) would be great as well.

I'm leaning toward option 3, requiring LBL, GTO, and GSB to always be followed by two hex digits. Due to the potential confusion due to the change from single-digit, it occurs to me that I could add prompting, so that when LBL is pressed, the display could show "LbL __" like the 41C, and similarly for GtO and GSb. Aside from writing and debugging the code for that prompting, one thing I don't like about it is that none of the other key sequences that take a numeric argument (STO, RCL, WINDOW, GTO ., SF, CF, F?) do that kind of prompting, so then I'd want to add those, but I'm not sure how to show or abbreviate WINDOW on the seven-segment display.

Although...

How useful would it be to have direct access to more than 32 registers (0 to F, .0 through .F)? I could do that with STO CHS nn and RCL CHS nn, and if I did that, then I'd probably want the CHS thing for the labels also, for consistency.

[brouhaha]

(01-28-2023 04:33 AM)brouhaha Wrote:  Since the divisor is a constant 14, this is done by multiplying by a fixed point approximation of the reciprocal of 14. There's some additional trickiness with efficiently getting a remainder of 0 to 13 out of the reciprocal multiplication, instead of a negative power of two, and I still don't really understand how they're doing that. It involves using 4688 as the approximation of 65536/14, rather than 4681, but there's more stuff going on after that which I haven't yet grasped.
...
Because of the extreme cleverness of HP's code, there's no obvious way to extend it to handling a larger input range. It's not a matter of just adding a few more digits to the reciprocal, or more loop iterations. (They aren't even using a loop.) I think the best solution is just to replace the reciprocal multiplication by a more conventional long division routine.

This was nagging at me, because the long division loop really can take significantly longer than HP's approach using the reciprocal. I've investigated it further. I still don't understand every line of code in HP's routine, but I decided to try writing my own. I've just written and tested it.

HP's routine occupies 28 words of ROM, and takes a fixed 39 instruction cycles to execute. It correctly handles input in the range of 0 to 682. (The standard HP-16C requires it to work for values of 0 to 405.)

My routine uses a higher-precision approximation of the reciprocal. My routine occupies 18 words of ROM, and takes 41 or 42 instruction cycles to execute. There's one additional goto instruction needed to skip the empty locations left by the patch, and the goto is only used in 50% of cases, due to an early exit dependent on the remainder value. Counting that goto, it is 19 words of ROM and an average of 42 instruction cycles. It correctly handles input in the range of 0 to over 10,000.

[brouhaha]

Since there was more space available, I found a way to make my routine take 28 words (vs 29 for HP), but execute in 35 or 37 cycles (average 36), vs a constant 39 for HP. So now in my firmware numbered register STO and RCL is actually ever so slightly faster than in the original. I prefer speeding things up rather than slowing them down.

[Paul Dale]

(01-31-2023 03:02 AM)brouhaha Wrote:  but I'm not sure how to show or abbreviate WINDOW on the seven-segment display.

|     |
|_| |_|


?

[Garry Lancaster]

(01-31-2023 05:14 AM)brouhaha Wrote:  Since there was more space available, I found a way to make my routine take 28 wrods (vs 29 for HP), but execute in 35 or 37 cycles (average 36), vs a constant 39 for HP. So now in my firmware numbered register STO and RCL is actually ever so slightly faster than in the original. I prefer speeding things up rather than slowing them down.

Nice work!

[Garry Lancaster]

(01-31-2023 03:02 AM)brouhaha Wrote:  Aside from writing and debugging the code for that prompting, one thing I don't like about it is that none of the other key sequences that take a numeric argument (STO, RCL, WINDOW, GTO ., SF, CF, F?) do that kind of prompting, so then I'd want to add those, but I'm not sure how to show or abbreviate WINDOW on the seven-segment display.

I would be tempted to treat WINDOW as a special case if possible, because I think it would be pretty distracting to have a prompt replace the contents of the current window. Much nicer for the display to switch directly between the contents of each window as they are selected.

What definitely would be useful is, after pressing f-WINDOW, the base indicator at the right of the display changed to show the current window number (with the left/right dots left in place), as it's currently easy to lose your place when viewing a binary number. This would also act as a prompt that a new window number is expected.

Not sure what you would show for the current window number if it wasn't exact because you'd been using g-< and g-> to scroll around. Perhaps a _ in this case.

Quote:How useful would it be to have direct access to more than 32 registers (0 to F, .0 through .F)? I could do that with STO CHS nn and RCL CHS nn, and if I did that, then I'd probably want the CHS thing for the labels also, for consistency.

I currently don't tend to use storage registers (except for I) as my memory is filled with programs. So I'm sure 32 directly-addressable registers would be more than enough for me personally when memory becomes less of an issue. I could only imagine using large numbers of registers as tables of some kind, in which case I'd be accessing them indirectly anyway.

[Garry Lancaster]

(01-31-2023 03:02 AM)brouhaha Wrote:  I'm leaning toward option 3, requiring LBL, GTO, and GSB to always be followed by two hex digits.

I've been thinking about this some more. I really like the consistency, but am somewhat loathe to give up my quick 2-keystroke access to my most frequently used programs.

However, as you're taking inspiration from the 41C, how about adding some form of key redefinability? Whilst I don't think a toggle-able USER mode would be ideal, something simpler would be nice. Could ON be pressed into service as a 3rd shift key, perhaps? I concede this may be tricky/impossible if it is handled as a special case by the hardware or firmware, but I'll assume for now it's feasible.

Option (1):
ON followed by keys A-F or 0-9 acts as GSB to those 16 labels. ON followed by ON turns the calculator off. ON followed by anything else is ignored.

Option (2):
ON is treated as a third shift key, followed by any other key (except ON, which turns the calculator off) to perform a user-defined action.
f-ON followed by any other key starts redefining that key. The definition is just the 2-digit label id.
g-ON followed by any other key clears the definition for that key.
This option is perhaps a bit OTT

Option (3):
If ON isn't usable in this way, you could perhaps still give quick access to a few programs.
In float mode, pressing A-F could do a GSB to one of those labels.
In integer mode, pressing . followed by A-F would do the same.
This option is perhaps slightly inconsistent but pretty easy to remember, and very similar to the quick-access capability of many other HPs. In fact, I think I like this one best

[Garry Lancaster]

(01-31-2023 10:46 AM)Garry Lancaster Wrote:  Option (3):

After a bit more thought, I definitely prefer this option. A year or so ago I had issues with my DM16L's ON key sinking beneath the faceplate, and had to perform some remedial work to get it back into shape. So it's perhaps not wise to overload the use of ON anyway.

[EdS2]

(01-30-2023 06:40 AM)brouhaha Wrote:  If I made more labels available, so that the 999 step program memory is more useful, would you rather have:

1) The standard 16 labels, but additionally LBL CHS <one hex digit>, and similarly GTO CHS snd GSB CHS, (32 labels total)

2) The standard 16 labels, but additionally allow LBL CHS <two hex digits>, and similarly GTO CHS and GSB CHS, for two-digit labels (256 labels total, as CHS 00-0F would be the same as the standard labels)

3) LBL, GTO, and GSB always require two hex digit argument, requiring 16C users to adjust to the new entry requirement (256 labels total, but consistent key entry)

I'm really surprised to be seeing support for (3) despite the breaking of compatibility. Doesn't (2) offer the same functionality, but with the no-longer-advanced idea of suppressing leading zeroes? And the benefit of compatibility with earlier, smaller, programs?

[brouhaha]

(02-01-2023 09:08 AM)EdS2 Wrote:  

(01-30-2023 06:40 AM)brouhaha Wrote:  2) The standard 16 labels, but additionally allow LBL CHS <two hex digits>, and similarly GTO CHS and GSB CHS, for two-digit labels (256 labels total, as CHS 00-0F would be the same as the standard labels)

3) LBL, GTO, and GSB always require two hex digit argument, requiring 16C users to adjust to the new entry requirement (256 labels total, but consistent key entry)

I'm really surprised to be seeing support for (3) despite the breaking of compatibility. Doesn't (2) offer the same functionality, but with the no-longer-advanced idea of suppressing leading zeroes? And the benefit of compatibility with earlier, smaller, programs?

I prefer 3, even though it's not entirely compatible with the 16C, because

* There's only one way to enter labels, so as a user, I have to retrain my fingers a bit, but then it's consistent
* It's easier to modify the 16C code to do this, rather than have a new flow involving the CHS key.
* I don't actually know where there's an extra bit of state in the 16C that I can use to track whether the CHS key has been involved in the sequence, without breaking something else. I don't think I can steal a bit from the ST register in the CPU, so I'd probably have to steal it from RAM.

I would observe than the 12C Platinum has done something similar with regard to requiring GTO and GTO . to be followed by three digits, vs. two digits on a normal 12C. I don't recall hearing any howls of frustration over that, but then again, maybe long-time 12C users don' t buy a 12C Platinum.

By the way, if you're asking why people support my option 3, I don't think there was any huge outpouring of support for it. Garry Lancaster's recent post supporting option 3 was for HIS option 3, not mine, although in an earlier post he said he said that of the three options I proposed, he was OK with 2 or 3.

[Sylvain Cote]

Although I am not participating, I am following this thread closely.
Thank you for doing this and I will gladly pay for the resulting firmware.
I vote for option 3.
I use an HP-16C @home and an DM16L @work.
Sylvain