HP-41: New HP-16C Emulator available

[Ángel Martin]

Ok Jon, it turned out to be as simple as suspected - fingers crossed.

The attached MOD file is just off the press. It features an initial 2's Complement setting chosen as default the first time the calculator is turned on after plugging the module, or if the buffer#11 isn't present - i.e. the equivalent to "when Continuous memory is reset" in the original machine. It remains so until changed by the user.

File's date stamp is today, July 7th, 2022 - you can see that in the MOD header.
The ZIP includes the Library#4 again - no changes here though.

[jonmoore]

(07-07-2022 04:59 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'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.

To be clear Ángel, if it isn't obvious by the fact that I generally have nothing but your Rom's installed on my DM41x, I'm a huge fan of your work. But I also realise this is something you've always done outside of day job, and it's something you've been motivated to do for no other reason than for the good of the 41 community (whatever the 41 device/emulator).

My feedback always has two core strands, one is obviously personal, but the second is always framed by UX/UI/interaction design criteria.

BTW I'm continuing on the importance of a mass key assignment trigger living in the top level FAT here. I totally get the challenge, especially when emulating a voyager device, which has more triple function keys than a 41 to start with. When you then frame that challenge by the limit of 64 functions within the top FAT, it makes things very difficult. But I think you answer this challenge better with the SandMath mass key assignment than with that in 16C simulator. The many SandMath launchers provides interactive access to so many functions in deeper FATs and you still have room for the MKEYS mass keys trigger in the top FAT. The story is much the same with 41Z Deluxe. I suppose the main difference I see with the 16C simulator is that you didn't design the core mass key assignment yourself.

When using the 16C simulator mass key assignment I still use the 16C trigger key (the summation key in the top left of the keyboard in the mass assignment - I'm pointing this out for others reading the thread). At a basic level you can't enter numbers onto the 16C stack without first pressing the 16C trigger (or 16NPT), but I also like the simplicity of DSZ and ISZ when programming and often use the original SL/SR functions too (to highlight a few original HP16C functions that were relegated to a sub-FAT. Just because I make use of mass key assignments doesn't mean that I don't access functions in sub-level FATs.

In terms of making room for the mass key assignment trigger, I believe it's possible to further consolidate what were single key functions on the original HP16C to cascaded options in much the same manner as you've achieved with the Y=0 etc and X=Y etc test cases. The prime case would be a single R_ which would provide access to both RR and RL (without breaking existing program compatibility).

I use HP calculators both interactively and programmatically. For instance, if I'm about to do something with lots of repetitive calculations I'll write small programs to reduce those repetitive steps, but if I'm cranking through a variety of mathematical tasks I'll often find it quicker to work interactively (often using programs I've previously written). This approach doesn't change whether I'm using an RPL calculator of a classic RPN calculator.

As I said at the opening of the post I have a huge admiration with regards to your ongoing commitment to the 41, and the manner in which you've created collections incorporating many of the best 41 programs/functions that have been written since 1979. But I have observed that you tend to prioritise the super power user with your creations and accessibility is less of a consideration. The 41 eccosytem of users is shrinking as each year, passes, which is a pity as the platform has so much more to give what with new hardware such as the DM41x coming to market. This is aided by your efforts translate many key routines to MCODE with an under the hood calculation capability of 13 significant digits, which often provides greater accuracy than a modern Casio running at 15 significant digits under the hood (but still only offering 10 visible significant digits).

I've always been of the opinion that accessibiliy leads to an increase in the number of power users when it comes to programmable calculators, as those using their programmables in simple ways grow to require more from their calculators. As long as accessibility is designed in such a way that it doesn't limit power users, it's a win/win situation.

[Ángel Martin]

Thanks for the clarifications and additional details Jon, I appreciate all feedback that may result in an improved user experience (and you're totally right there aren't many of them so better treat them well ;-)

I'm guilty as charged in that I tend to focus more on the more complex/difficult stuff, in detriment of the standard topics. It's part of the motivation to tackle the more challenging tasks, of course... I, however, always try to keep an eye on the ease of use and consistency, but of course there're highs and lows.

Nuff said, here's a Q&D proposal I would like you to try and let me know if eases the pain - even if minimally. The attached revision includes a shortcut to the 16KEYS sub-function in the main 16C launcher: pressing the SHIFted USER key does it

16C, [SHIFT], USER --> 16KEYS

So it's a first step - one that can be taken with just an ad-hoc code change, as incredibly enough there was spare room in the 16C assignments table. Going beyond that will be significantly more involved and probably expose us to trickle-down issues.

Your thoughts?

[jonmoore]

(07-07-2022 05:23 PM)Ángel Martin Wrote:  Thanks for the clarifications and additional details Jon, I appreciate all feedback that may result in an improved user experience (and you're totally right there aren't many of them so better treat them well ;-)

I'm guilty as charged in that I tend to focus more on the more complex/difficult stuff, in detriment of the standard topics. It's part of the motivation to tackle the more challenging tasks, of course... I, however, always try to keep an eye on the ease of use and consistency, but of course there're highs and lows.

Nuff said, here's a Q&D proposal I would like you to try and let me know if eases the pain - even if minimally. The attached revision includes a shortcut to the 16KEYS sub-function in the main 16C launcher: pressing the SHIFted USER key does it

16C, [SHIFT], USER --> 16KEYS

So it's a first step - one that can be taken with just an ad-hoc code change, as incredibly enough there was spare room in the 16C assignments table. Going beyond that will be significantly more involved and probably expose us to trickle-down issues.

Your thoughts?

Thanks Ángel, really appreciate you looking into this. And your solution does the job very nicely indeed.

All one need do is allocate 16C to one of the sixteen A->P shortcut keys in the CST menu of the DM41x; and then Shift USR is easily accessible in both the standard and USR keyboards.

I'm really surprised that configuring the USR key with a shifted value is possible seeing as it's not part of the core 35 USR keyboard keys on the original 41.

I'm presuming this solution only works for DM41x users, or is there a back door to to Shift USR on original 41 hardware too?

[Ángel Martin]

(07-07-2022 08:24 PM)jonmoore Wrote:  Thanks Ángel, really appreciate you looking into this. And your solution does the job very nicely indeed.

All one need do is allocate 16C to one of the sixteen A->P shortcut keys in the CST menu of the DM41x; and then Shift USR is easily accessible in both the standard and USR keyboards.

I'm really surprised that configuring the USR key with a shifted value is possible seeing as it's not part of the core 35 USR keyboard keys on the original 41.

I'm presuming this solution only works for DM41x users, or is there a back door to to Shift USR on original 41 hardware too?

Great to hear that!

It works across all platforms (hey, that's a nice sentence to say...), V41, DM41X, CL, and of course the original machine. The WARP module also uses a couple of these assignments, nothing mysterious as the logical SHIFT-USER is different from the logical USER key. Ditto for PRGM and ALPHA of course.

It's also possible to assign functions to the SHIFTed SHIFT key, and in fact that's profusely used in the SandMath and 41Z launchers as well.

[jonmoore]

(07-08-2022 04:31 AM)Ángel Martin Wrote:  It's also possible to assign functions to the SHIFTed SHIFT key, and in fact that's profusely used in the SandMath and 41Z launchers as well.

Shifted shift in SandMath and 41Z is one of the reasons I love those ROMs so much. It's such an elegant interaction design pattern. As you traverse the launcher maps, mnemonic triggers help you locate the most apt function for your needs.

In view of the fact that you consistently use the sumation key as the core sub-function launcher across, 41Z, SandMath, SandMatrix, Warp Core and the 16C simulator (amongst others), maybe it might make sense if you were to consistently use Shifted USR as the trigger for each respective mass key assignment (where appropriate). The benefit here for DM41x users is that they can get greater flexibility from their CST shortcut assignments (if they save the sub-function launcher key of each ROM in place of their mass key assignment triggers). It obviously helps in terms of the global interaction design patterns too, as you're increasing inter-ROM consistency for similar functions.

By doing this, you'll also be able to free a primary FAT slot for a more deserving function in the likes of 41Z and SandMath.

[Ángel Martin]

It's a good suggestion, I'm all in for consistency across modules and as you say this also has the additional bonus of saving one key assignment - that can be repurposed.
Will be implementing these mods on a need-to-change basis.