HP-41: New HP-16C Emulator available

[jonmoore]

(05-20-2022 06:20 AM)Ángel Martin Wrote:  I just tried it on my CL, V41 and DM41X and it worked just as expected. Let's first make sure you have the latest revisions of the module and the Library#4, pls. use the attached MOD files to try it again and let me know if that solved the problem.

Cheers,
ÁM

Very odd. I updated everything (inc my DM41x firmware) on my DM41x at the end of April when you updated Library#4 to R59b. However, the bulk of the Mod files came from the compilation pack of Mods you put together for SwissMicros (last updated April 2021). I always keep my most used Mod's up to date as you release them on ***** but the version of the 16c emulator came from that pack. I'll see how I get on with the version of the Mod you've provided in your last post.

BTW I also CAT 2'd the Mod and 16Keys isn't listed amongst the functions.

[jonmoore]

Ok, I've discovered the problem. The mass key assignments trigger functions (MKEYS and ZK?YN) for SandMath and 14Z exist in the main FAT. 16KEYS is in a lower FAT and can only be triggered via 16$. This inconsistency isn't ideal as a UX pattern as one would expect things to function as they do in your other modules.

I'm sure you've only done things this way as you ran out of room in the main FAT but maybe it would be better if one of the more esoteric 16c functions were swapped to a lower FAT so 16KEYS can exist at the upper level. I trigger all my mass key assignments via the CST feature on the DMC41x but this doesn't work with functions in lower FATs.

[Ángel Martin]

(05-20-2022 11:26 AM)jonmoore Wrote:  Ok, I've discovered the problem. The mass key assignments trigger functions (MKEYS and ZK?YN) for SandMath and 14Z exist in the main FAT. 16KEYS is in a lower FAT and can only be triggered via 16$. This inconsistency isn't ideal as a UX pattern as one would expect things to function as they do in your other modules.

I'm sure you've only done things this way as you ran out of room in the main FAT but maybe it would be better if one of the more esoteric 16c functions were swapped to a lower FAT so 16KEYS can exist at the upper level. I trigger all my mass key assignments via the CST feature on the DMC41x but this doesn't work with functions in lower FATs.

Yes, main FAT room was the limiting factor; it's always a struggle trying to fit so much functionality onto a reduced keyboard - not stepping on your toes or messing with the needed functions.

Well, we thought users wouldn't be using the direct key assignments much on this module because many of the functions on the overlay are really sub-functions, which cannot be assigned to the user keyboard. Thus we figured the preferred method would be using the 16C function launcher instead; this gives you access to both main and sub-functions equally and besides it doesn't mess with the actual key assignments in USER mode (only 16C needs to be assigned).

The flipside is you need one extra keystroke press, but that's (we thought) a small price to pay to rip the benefits of full function keyboard control...

[jonmoore]

(05-20-2022 01:37 PM)Ángel Martin Wrote:  Yes, main FAT room was the limiting factor; it's always a struggle trying to fit so much functionality onto a reduced keyboard - not stepping on your toes or messing with the needed functions.

Well, we thought users wouldn't be using the direct key assignments much on this module because many of the functions on the overlay are really sub-functions, which cannot be assigned to the user keyboard. Thus we figured the preferred method would be using the 16C function launcher instead; this gives you access to both main and sub-functions equally and besides it doesn't mess with the actual key assignments in USER mode (only 16C needs to be assigned).

The flipside is you need one extra keystroke press, but that's (we thought) a small price to pay to rip the benefits of full function keyboard control...

I'll have a play with the 16C workflow as this is different from what I've been doing to date - assigning 16NPT to a key in CST on the DM41x and then entering the commands manually (in most cases these are easy to remember without referring to the docs). But there are occasions when you're simply looking to convert a bunch of values on the fly, and then negate/binary shift or suchlike; and that's where a dedicated mass key assignment makes sense.

I did attempt to get my head around the 16C launcher when I first started having a dabble and things were a little confusing, but now I understand some of the advanced features a little better, things will hopefully fall into place a little more easily.

[jonmoore]

@Ángel, I had another testing session with the simulator today and found what I believe to be a serious bug. The arithmetic operation 16* doesn't work. I attempted to use it interactively by three different methods and all failed.

- Triggering 16* directly from the 16keys layout.
- Triggering 16* directly from the 16keys layout after first activating 16C.
- Triggering 16* via XEQ.

The plus, minus and divide arithmetic operations function correctly with all three of the above methods.

I also believe that the simulator should follow the default configuration of the hardware 16C by having a word size of 32 and 2's complement binary representation of signed integers. This is the most common binary representation on other calculators with binary functionality (apart from HP's RPL calculators, which require bespoke programs for 2's complement signed binary integer representation). It's great that you've extended upon what the 16C provides, but the defaults should be a facsimile of the 16C so things feel familiar for those with prior knowledge of the 16C.

I've encountered many situations where the 16C simulator has required me to reset my DM41x. Maybe this is something that affects original 41CX's to a lesser degree, as I tend to run 16C in a fully stacked DM41x so maybe I'm encountering conflicts (but the problems only occur when your 16C simulator is part of the mix). My active modules are typically (and in this order):

- Thermal Printer
- Warp Core
- HP-16C Simulator
- SandMath
- 41Z DeLuxe
- Sand Matrix

All are the latest versions.

[Ángel Martin]

(07-04-2022 03:54 PM)jonmoore Wrote:  @Ángel, I had another testing session with the simulator today and found what I believe to be a serious bug. The arithmetic operation 16* doesn't work. I attempted to use it interactively by three different methods and all failed.

- Triggering 16* directly from the 16keys layout.
- Triggering 16* directly from the 16keys layout after first activating 16C.
- Triggering 16* via XEQ.

The plus, minus and divide arithmetic operations function correctly with all three of the above methods.

Does it *always* fail for you or is it value/status dependent?
Pls. include some use case examples to troubleshoot it on my side...

ps.- I just recompiled the MOD file, pls. use the attached and let me know if the issue is resolved.

[Ángel Martin]

(07-04-2022 03:54 PM)jonmoore Wrote:  I also believe that the simulator should follow the default configuration of the hardware 16C by having a word size of 32 and 2's complement binary representation of signed integers. This is the most common binary representation on other calculators with binary functionality (apart from HP's RPL calculators, which require bespoke programs for 2's complement signed binary integer representation). It's great that you've extended upon what the 16C provides, but the defaults should be a facsimile of the 16C so things feel familiar for those with prior knowledge of the 16C.

Not sure I follow... the simulator has a default status is 32 bit word size and HEX mode, unsigned.
This is maintained (until changed) when you change the display BASE choice.

Are you saying that in the original HP-16C the complement mode CHANGES automatically to "2" when switching to Binary? That'd be weird...

[jonmoore]

(07-05-2022 06:24 AM)Ángel Martin Wrote:  

(07-04-2022 03:54 PM)jonmoore Wrote:  @Ángel, I had another testing session with the simulator today and found what I believe to be a serious bug. The arithmetic operation 16* doesn't work. I attempted to use it interactively by three different methods and all failed.

- Triggering 16* directly from the 16keys layout.
- Triggering 16* directly from the 16keys layout after first activating 16C.
- Triggering 16* via XEQ.

The plus, minus and divide arithmetic operations function correctly with all three of the above methods.

Does it *always* fail for you or is it value/status dependent?
Pls. include some use case examples to troubleshoot it on my side...

ps.- I just recompiled the MOD file, pls. use the attached and let me know if the issue is resolved.

It's value-independent. I tested with values in the 10's, 100's & 1000's and with both hex and dec bases.

Thanks for the new version. I'll test it later today and report back.

[jonmoore]

(07-05-2022 07:13 AM)Ángel Martin Wrote:  

(07-04-2022 03:54 PM)jonmoore Wrote:  I also believe that the simulator should follow the default configuration of the hardware 16C by having a word size of 32 and 2's complement binary representation of signed integers. This is the most common binary representation on other calculators with binary functionality (apart from HP's RPL calculators, which require bespoke programs for 2's complement signed binary integer representation). It's great that you've extended upon what the 16C provides, but the defaults should be a facsimile of the 16C so things feel familiar for those with prior knowledge of the 16C.

Not sure I follow... the simulator has a default status is 32 bit word size and HEX mode, unsigned.
This is maintained (until changed) when you change the display BASE choice.

Are you saying that in the original HP-16C the complement mode CHANGES automatically to "2" when switching to Binary? That'd be weird...

Apologies I was using the term binary in its generic sense. The most important default value is 2's complement as the user otherwise encounters unexpected behaviour when converting a negative signed binary, hex etc value back to decimal.

It's front of mind as I've had to reset my DM41x often whilst using the 16C simulator.

My recommendation isn't specific to my use case as it's simple enough to trigger the 2CMP command. But I'm thinking of others that try out the 16C simulator for the first time, and in that use case, I think it's important that the defaults provide as friendly and familiar a user experience as possible. Most calculators that offer base conversions default to 2's complement mode for this reason (in fact, the majority are nowhere near as sophisticated as the 16C and the user cannot configure the complement setting so it's permanently in 2's complement mode).

[Ángel Martin]

(07-05-2022 08:38 AM)jonmoore Wrote:  My recommendation isn't specific to my use case as it's simple enough to trigger the 2CMP command. But I'm thinking of others that try out the 16C simulator for the first time, and in that use case, I think it's important that the defaults provide as friendly and familiar a user experience as possible. Most calculators that offer base conversions default to 2's complement mode for this reason (in fact, the majority are nowhere near as sophisticated as the 16C and the user cannot configure the complement setting so it's permanently in 2's complement mode).

I actually agree, but as far as I know the default setting on the real HP-16C is also unsigned mode. Is that not so? I thought I had read that somewhere in the manual...

[Sylvain Cote]

(07-05-2022 10:28 AM)Ángel Martin Wrote:  

(07-05-2022 08:38 AM)jonmoore Wrote:  My recommendation isn't specific to my use case as it's simple enough to trigger the 2CMP command. But I'm thinking of others that try out the 16C simulator for the first time, and in that use case, I think it's important that the defaults provide as friendly and familiar a user experience as possible. Most calculators that offer base conversions default to 2's complement mode for this reason (in fact, the majority are nowhere near as sophisticated as the 16C and the user cannot configure the complement setting so it's permanently in 2's complement mode).

I actually agree, but as far as I know the default setting on the real HP-16C is also unsigned mode. Is that not so? I thought I had read that somewhere in the manual...

HP-16C Computer Scientist OWNER’S HANDBOOK

Complement Modes and Unsigned Mode (p.29)

Quote:The HP-16C provides three conventions for representing numbers: 1's Complement mode, 2’s Complement mode, and Unsigned mode.
The 2’s Complement mode is the default mode when the calculator is first turned on or after Continuous Memory is reset.
Once a mode is set, it remains in effect until you change it or until Continuous Memory is reset.
(All examples in this handbook use 2’s Complement unless otherwise indicated.)

[Ángel Martin]

(07-05-2022 10:46 AM)Sylvain Cote Wrote:  

(07-05-2022 10:28 AM)Ángel Martin Wrote:  I actually agree, but as far as I know the default setting on the real HP-16C is also unsigned mode. Is that not so? I thought I had read that somewhere in the manual...

HP-16C Computer Scientist OWNER’S HANDBOOK

Complement Modes and Unsigned Mode (p.29)

Quote:The HP-16C provides three conventions for representing numbers: 1's Complement mode, 2’s Complement mode, and Unsigned mode.
The 2’s Complement mode is the default mode when the calculator is first turned on or after Continuous Memory is reset.
Once a mode is set, it remains in effect until you change it or until Continuous Memory is reset.
(All examples in this handbook use 2’s Complement unless otherwise indicated.)

Interesting, I obviously had the false impression here...
But considering that the complement mode is also saved in memory even with the calculator off, isn't this bit of a moot point? Once changed it'll remain as selected.

Maybe it's an easy change to set an initial default to CMP2, I'll take a look at that part of the code.

[jonmoore]

@Ángel, The point of the recommendation is to help make the 16C simulator intuitive in use for initial explorations (before a user has looked at configuration options).

And that's the importance of the 16KEYS mass key assignment too.

I'm aware that you have deprioritised mass key assignments throughout your excellent math-focused ROMs as you can only provide access to a limited number of functions through the USR keyboard. But well-designed mass key assignments help users with their initial explorations of your Mod/Rom collections (they're very effective in SandMath and 41Z DeLuxe). And mass key assignments needn't limit the user when programming either. The CST key on the DM41x makes it very easy to swap key assignments on the fly, which is especially important with the 16C simulator, as the mass key assignment repurposes the XEQ key - you need to disable the assignment to (XEQ) execute other functions/commands.

I'm sure many users create custom USR keyboard assignments and don't rely on mass key assignments, but I find with your suite of math ROMs, the mass assignments are so well configured, that I'm not motivated to create a single bespoke USR layout. I get greater flexibility using your assignments as they contain great launcher functionality over and above 'straight' assignments.

I know you have the 41CL front of mind when creating your ROMs and my DM41x CST workflow may not have a parallel with the 41CL, but I can only speak of how I use your ROMs.

[jonmoore]

@Ángel, I've just tested the recompiled MOD, but 16* still has no effect via all three methodologies I mentioned in my original bug report.

[Ángel Martin]

Jon, there was a wrong jump-to address in the 16* code but that was corrected in the version included in the previous post. With this correction the HP-16C simulator works fine on my DM-41X as well as on the CL an on V41. There's something obviously strange with what you're experiencing, it may be a version mismatch with the Library#4, so let's make sure we're on the same page first. Pls. use the versions in the attached zip container and we'll go from there.

Test case: Unsigned, 32 bits, Hex
16NPT "AbC"
16NPT "123"
16* -> shows: "H: C33b4"
LST16C -> shows: "H: 123"
16/ -> shows: "H: AbC"

[jonmoore]

Thanks Ángel. I'll load both Library #4 and the 16C simulator from your zip in the morning and report back.

[Ángel Martin]

(07-05-2022 09:28 PM)jonmoore Wrote:  Thanks Ángel. I'll load both Library #4 and the 16C simulator from your zip in the morning and report back.

Remember to import the MOD files from the USB FAT drive into flash before plugging them in the "Active Modules" list...

[jonmoore]

(07-06-2022 07:18 AM)Ángel Martin Wrote:  

(07-05-2022 09:28 PM)jonmoore Wrote:  Thanks Ángel. I'll load both Library #4 and the 16C simulator from your zip in the morning and report back.

Remember to import the MOD files from the USB FAT drive into flash before plugging them in the "Active Modules" list...

It's now working as it should. Thanks for your efforts.

I've noticed some discrepancies in the Martin McClure mass key assignment/overlay but I'll report these once I've collated them. I've noticed over time that with new revisions to your Rom's, it's possible that the documentation isn't always updated to reflect the revision changes so it's possible that the discrepancies in the USR key assignments are due to undocumented revisions.

On the subject on the mass key assignments, it's still my view that it's wrong that the mass key assignment trigger doesn't exist in the primary bank. This means it can only be triggered via XEQ+ or via 16C (followed by Alpha) and then typing out 16KEYS.

The sum result of this is that the user can't assign 16KEYS to the DM41x CST menu (which is something I do with SandMath's MKEYS and 41Z's ZK?YN mass key assignment triggers). I'm aware you optimise your ROM's for use without mass key assignments but when all ones regular use case mass key assignments are assigned via CST single trigger keys, it's makes for a very powerful way to hop around many key features across all ones loaded ROM's. And this makes the DM41X feel like a single calculator rather than a calculator with an assortment of ROM's. It's a subtle UX quality, but it's one that means that my DM41x is my most used non RPL HP calculator (and your MCODE conversions of key functions across your ROM's means that I rarely feel limited by 10 visible significant digits).

[Ángel Martin]

(07-06-2022 10:50 AM)jonmoore Wrote:  

(07-06-2022 07:18 AM)Ángel Martin Wrote:  Remember to import the MOD files from the USB FAT drive into flash before plugging them in the "Active Modules" list...

It's now working as it should. Thanks for your efforts.

Good to hear the issue is solved.

(07-06-2022 10:50 AM)jonmoore Wrote:  I've noticed some discrepancies in the Martin McClure mass key assignment/overlay but I'll report these once I've collated them. I've noticed over time that with new revisions to your Rom's, it's possible that the documentation isn't always updated to reflect the revision changes so it's possible that the discrepancies in the USR key assignments are due to undocumented revisions.

Those "discrepancies are to be expected because the overlay reflects the 16C launcher layout, not the mass-keys arrangements. The launcher has more functions and subfunctions that cannot be included in the mass-keys.. This forces compromises in the selection of keyboard placement for the mass-keys choices.

(07-06-2022 10:50 AM)jonmoore Wrote:  On the subject on the mass key assignments, it's still my view that it's wrong that the mass key assignment trigger doesn't exist in the primary bank. This means it can only be triggered via XEQ+ or via 16C (followed by Alpha) and then typing out 16KEYS.

I disagree with you, it's not wrong but a conscious decision to prioritize the (complete) 16C launcher over the (incomplete) mass-keys approach. Besides, the main FAT is full so if the trigger function were placed in the main FAT something else would have to be moved to the auxiliary FAT. Which one would you be willing to give away? Would that one be the same chosen by all users? At the end it becomes a matter of personal preferences - like much in the U/I design field.

(07-06-2022 10:50 AM)jonmoore Wrote:  The sum result of this is that the user can't assign 16KEYS to the DM41x CST menu (which is something I do with SandMath's MKEYS and 41Z's ZK?YN mass key assignment triggers). I'm aware you optimise your ROM's for use without mass key assignments but when all ones regular use case mass key assignments are assigned via CST single trigger keys, it's makes for a very powerful way to hop around many key features across all ones loaded ROM's. And this makes the DM41X feel like a single calculator rather than a calculator with an assortment of ROM's. It's a subtle UX quality, but it's one that means that my DM41x is my most used non RPL HP calculator (and your MCODE conversions of key functions across your ROM's means that I rarely feel limited by 10 visible significant digits).

I understand your predicament, using the module on the DM-41X loses the benefit of the overlay and the keyboard layout is not identical to the original 41C which causes confusion. For you the mass-keys option is understandably preferred - but maybe this is just an initial situation that will change as you get more acquainted with the 16C launcher and rip the benefits of having the sub-functions also available from there?

[Ángel Martin]

(07-05-2022 08:38 AM)jonmoore Wrote:  My recommendation isn't specific to my use case as it's simple enough to trigger the 2CMP command. But I'm thinking of others that try out the 16C simulator for the first time, and in that use case, I think it's important that the defaults provide as friendly and familiar a user experience as possible. Most calculators that offer base conversions default to 2's complement mode for this reason (in fact, the majority are nowhere near as sophisticated as the 16C and the user cannot configure the complement setting so it's permanently in 2's complement mode).

I'm looking into this as we speak, pls. be patient as this is not my day job.
BTW although yes it looks "simple enough", one should never underestimate the slippery slope nature of MCODE...

Stay tuned.