A skinnable phone/desktop 42S emulator (aside from Free42/Plus42)

[MickM]

In an 11th hour twist of fate, the skin I've spent such a very long time developing for Free42/Plus42 has crashed and burned :-(. It has several new and great features, but I required a trivial amendment to the operation of the "E" button (for entering an exponent) that I believe nobody would ever notice. However, the developer (Thomas) is unwilling to make the change on principle and I'm unwilling to donate the skin without it. I continue to hope he will change his mind or perhaps identify another solution, but I (and my colleagues) have been unsuccessful so far - hence this post. The skin itself is complete in it's features but now I'm looking for a new home for it while I still have momentum. I'm generally unaware of the other 42S emulators out there (phone & desktop), and in particular their skin and desktop version hotkey capabilities. Can anybody out there recommend an emulator for which I could work with the developer to donate my skin?

Also, I don't want anybody to misinterpret this post as a jab at Thomas - he's been quite helpful during the development of this skin except for that one issue right at the very end when everything was all done (which was, admittedly, immensely disappointing for me).

[dm319]

What makes you think another emulator/simulator will have the the 'e' key function you want?

Have you considered forking the code? It is open source, so you could either implement it yourself or see if you could find someone who could do it for you?

[SammysHP]

There is emu42, but I'm not sure about its keyboard functionality.

https://hp.giesselink.com/emu42.htm

What feature do you need for the E key?

[MickM]

Thanks for the two responses. I did notice emu42 but I had a tough time just understanding its world, including not containing a ROM image, I didn't see the Mac represented (which is my desktop platform), I didn't see iOS represented (where I mostly want to use this), and the documentation was somewhat wanting (at least for skins). If the ROM image in question is indeed "untouchable" then I'd be stuck because I couldn't get the "E" functionality change I was after. Additionally, a fixed ROM image would mean other 42S tweaks/enhancements couldn't be made either. Thomas has done a superb job on his HP42S emulator and (I believe) has full control over all aspects of it without the ROM image constraints. Honestly, I'd be surprised if something better was out there.

Regarding forking the code - while I can surely write a "normal" computer program to do X and Y, I'm not by any stretch of the imagination a programmer for Mac, Windows, Linux, iOS and Android like Thomas is. The whole open-source universe is just Greek to me. Additionally, in some discussions with him, I've had a peek into what he deals with as a programmer and I just don't have the requisite inclination or remaining life span to get there :-). I was hoping there might be another 42S developer out there that I could persuade to make my change, in exchange for the benefits my skin would provide to the developer by making the product more attractive.

Only because the question was asked - the desired change to the "E" button is that if you've pressed E and started entering your exponent then a subsequent E (before the number has been accepted) takes you back to the start of entering an exponent (i.e. it resets exponent entry). I've never actually knowingly pressed E a subsequent time after starting an exponent entry in my almost 50 years of HP calculator usage, nor have any of my colleagues. The real calculator just ignores all subsequent E presses i.e. you can do 1.2E34E5 and you'd get 1.2E345, but I'm looking to end up with 1.2E5. Thomas is adamantly sticking with the HP way because he believes in absolutely preserving the original HP DNA. I totally get that philosophy (and agree with it in general), however I had hoped that because subsequent E presses never made any sense (and also that nobody even does it) that an exception might be made as a viable trade-off for the benefits of the skin. I can't imagine users would even notice the change if it was ever implemented. I've tried my best to convince Thomas, but without success (indeed, I've had negative success), and hence my original post to find a potential new home for my skin. I'll live if such an app doesn't exist, no harm in asking though :-).

[Eric Rechlin]

It sounds like the functionality you are requesting in the E key has nothing to do with the skin, so I don't see how they are related.

The only thing I can think of is you are trying for a transactional model here -- change your program this way and I will give you this skin to use. That's not a good philosophy for open source software, or even life in general. Make what you want because you enjoy doing it. Give it away if you want others to enjoy it too. But don't hold your creation hostage from the world because someone doesn't want to implement what you want. Thomas hasn't asked for a single cent for Free42 despite spending surely thousands of hours on it.

After all, Free42 is open source so you could fork it and make your own version with that behavior if you are so insistent in changing HP's normal behavior.

[dm319]

(10-19-2023 04:56 PM)MickM Wrote:  I required a trivial amendment to the operation of the "E" button

(10-19-2023 04:56 PM)MickM Wrote:  I'm not by any stretch of the imagination a programmer for Mac, Windows, Linux, iOS and Android like Thomas is.

These statements are contradictory. I don't see how you can judge the change to be trivial if you have little idea where to start. I suspect that this change is not being considered because it would change fundamental behaviour of free42 away from the hp-42s, which is clearly not the idea of free42. Once you make a change like that you must maintain both the methods of functioning to ensure compatibility with the original.

(10-19-2023 04:56 PM)MickM Wrote:  The skin itself is complete in it's features but now I'm looking for a new home for it while I still have momentum.

(10-19-2023 04:56 PM)MickM Wrote:  in exchange for the benefits my skin would provide to the developer by making the product more attractive.

I can see that you both do not understand the culture of free/open source software and you have overvalued your potential contribution.

There are websites that will hook you up with a programmer who can make the change for you. I think there is one called 'fiverr' or similar. Someone could well create you a one-off version of free42 to suit your needs.

[MickM]

(10-22-2023 02:35 AM)Eric Rechlin Wrote:  It sounds like the functionality you are requesting in the E key has nothing to do with the skin, so I don't see how they are related.

I was hoping to not bog down this topic with the details of my skin, but I guess it's not looking that way. Amongst other features, my skin (which does not conform to the standard 42S layout) contains buttons for predefined metric notation exponents for faster entry of such numbers. The button labeled "µ" (micro) is simply a macro that emulates the sequence of pressing of E +/- 6 and similarly "p" (pico) emulates E +/- 1 2 and so on. I have attached a graphic of the phone version of the skin purely for context. While I'm more than happy to accept any feedback on it, that would totally derail this thread so that's better done in another post (if this skin actually ends up becoming a release candidate).

(10-22-2023 02:35 AM)Eric Rechlin Wrote:  The only thing I can think of is you are trying for a transactional model here -- change your program this way and I will give you this skin to use. That's not a good philosophy for open source software, or even life in general. Make what you want because you enjoy doing it. Give it away if you want others to enjoy it too. But don't hold your creation hostage from the world because someone doesn't want to implement what you want. Thomas hasn't asked for a single cent for Free42 despite spending surely thousands of hours on it.

So that's certainly a humbling interpretation of what I'm doing here that I hadn't considered. In my long career as a EE designing ICs it's been ground into my core that, given the ultra high cost of tooling, all known bugs must be squashed before any manufacturing run. The constantly cited mantra being it's always cheaper to do it right than do it over. I've had many colleagues try out my skin and, in their monkeying around with these new metric notation keys, literally every one of them noticed that if you do e.g. 1.2pµ (i.e. trying to break it or find some flaw) that they expected the final number to be 1.2E-6 but instead got 1.2E126. They thought that unexpected behavior was a bug because they pressed a button that had "µ" printed on it and they didn't get what the button clearly indicated it did. Like myself, they thought "fix that bug and your product can be released". We discussed the reason behind the bug and came up with solutions including the previously mentioned E fix to labeling the buttons as e.g. +µ (which was both awkward and mathematically inaccurate) to …µ (which was just awkward). I'm sure you're all aware that entering 1.2pµ can be resolved by typing 4 backspaces after the "p" before typing "µ". Not everybody, but most said the current implementation was just a clear user interface bug and needed to be fixed before release. They (myself included) saw the trade-off of tweaking the E key functionally to hijack a key sequence nobody ever did as the clearly easy and obvious solution. While I respect your assertion that I was holding my creation hostage, my genuine interpretation was more of "Rats! I simply can't release my product to manufacturing unless this bug is fixed". It not as though I was preventing Thomas from moving forward, it was more that I was preventing myself i.e. the harm (or loss) was to me.

This whole open source contributing is new for me. I've not involved myself in such an effort before so apologies for the business model vs cultural model mis-step. While I continue to have a hard time seeing any practical downside to the requested "E" change from a user's perspective, perhaps the less fractious path forward would be to release the skin (along with its bug) and see if the community of users even cares. Would you say that is a better path forward?

dm319: Thanks also for your opinions. I'm hoping my above comments overlap enough into your claims. I would say that if shown the relevant chunk of code that deals with the entering of exponents I could probably finagle that "E" fix, but it's the associated universe that thwarts things for me (figuring out github, the Apple App Store, and all the other things I don't know that I don't know). It'd be hard for me, but likely easy for Thomas - that's all I was implying. Thomas does, of course, have final say in the matter. I was just doing my best to test his assertion that modifying "E" as requested actually impacted anybody while also dangling whatever carrots I could find while I was at it. There was never any intention to offend, but there certainly was the intention to debate underlying assumptions...

[rprosperi]

It's good that you've shared what you're planning, as indeed many folks here were interpreting things the way Eric did, which it now appears is not the case.

While I've not evaluated the usefulness of you proposed skin for my own use, it is clear lots of thought went into it. How useful such a non-standard approach is to a Free42/Plus42 user is a totally subjective thing and cannot be predicted well or generalized.

All that said, I have to agree with Thomas' decision. Free42 is designed specifically to emulate the UI/UX of the 42S and that includes all the intended and unintended cases of pressing the E key; introducing non-standard behavior would lead to bug reports and criticism that it's broken, as the compliance test is try the same action on a 42S.

Suggesting that few or no people would notice the proposed E change is also disingenuous at worst, or naive at best, as when you're own testers encountered behavior they didn't expect, you noted that they immediately reported it as a bug.

It seems your goals can be easily met by simply documenting CLEARLY that pressing multiple prefix keys is additive and will lead to errors (or at least unexpected results) if not corrected.

Asking for a change which you hypothesize 'should not bother' the >99% that use Free42 to make an incorrect key sequence more recoverable for the <1% that may use it is simply not reasonable.

You can of course pay (or whatever) someone with sufficient skills to fork Free42 to make you a private build with this change to be used by you and your associates, but that would be frozen in time and could not benefit from the ongoing bug fixes and enhancements Thomas publishes regularly unless you pay them again, etc. Seems to make more sense to adopt the standard Free42 code and publish/explain the small limitation to your users.

Please don't take this as criticism, it is intended as feedback and guidance for how this community operates and what they expect. I hope you can resolve it and proceed to release as it looks like an interesting skin approach and I'm curious to see how widely it would be adopted.

[Nigel (UK)]

Just a thought: I would personally expect 1.2pµ to enter 1.2E-18. This could be done without modifying “E” by having the p key (for example) execute the key presses ENTER E 12 +/- x. This would work even if the initial number was already in standard form. After all, why shouldn’t I be able to enter 4.2E3 nanometres if I want to?

You would lose the T register doing this, but these days Free42 offers the option of an unlimited stack so that need not be a problem.

Nigel (UK)

[Nigel (UK)]

Here’s a suggested way to do it without losing the T register:

STO .L (store X in LastX reg)
<- (Clear X; stop stack lift)
E 12 +/- (Enter 1E-12)
RCL x .L. (multiply 1E-12 by original number leaving result in X)

I should probably admit that I know nothing about how skins work: I’m assuming that they let you enter a series of key presses when a key is pressed. In any case it’s been fun to think about!

Nigel (UK)

[MickM]

(10-22-2023 05:40 PM)rprosperi Wrote:  Suggesting that few or no people would notice the proposed E change is also disingenuous at worst, or naive at best, as when you're own testers encountered behavior they didn't expect, you noted that they immediately reported it as a bug.
...
Asking for a change which you hypothesize 'should not bother' the >99% that use Free42 to make an incorrect key sequence more recoverable for the <1% that may use it is simply not reasonable.

I feel awkward belaboring this because it's readily apparent folks here appear to be clearly in Thomas' camp. I will however make the distinction that the above opinion arose out of discussions with many colleagues and their collective and unanimous conclusion was something like:
"Entering 1.2E34E5 to get 1.2E345? Maybe it's the way it works, but I've never knowingly done that and nor am I likely to ever do that. E inconsistently changes it's function on the fly - it does one thing the 1st time and nothing all subsequent times. In fact, the proposal fixes the issue at hand and makes the key's function both consistent and more useful. And no existing programs would be harmed by this change."
A devil's advocate might say I poisoned the well, although I don't think so because in all the conversations I've honestly forgotten exactly who came up with that solution.

That being said, now is apparently not the time to fight this battle. We can take the 42S constitution formed by our HP forefathers to task another day. At that time I would propose the 1st amendment. 1st amendments are good! It's those 2nd amendments where everything goes to crap ;-).

(10-22-2023 05:40 PM)rprosperi Wrote:  Please don't take this as criticism, it is intended as feedback and guidance for how this community operates and what they expect.

No offense taken - it's a healthy and productive debate. My main takeaway in this thread is needing to conform to the principles of an open source community.

(10-22-2023 09:43 PM)Nigel (UK) Wrote:  Just a thought: I would personally expect 1.2pµ to enter 1.2E-18. This could be done without modifying “E” by having the p key (for example) execute the key presses ENTER E 12 +/- x. This would work even if the initial number was already in standard form. After all, why shouldn’t I be able to enter 4.2E3 nanometres if I want to?

We had already heavily discussed that, and similar options, and rejected them for reasons I'd be happy to elaborate upon in another thread if this skin sees the light of day. Other options also came up, but they all require Thomas to implement something new.

In light of my realizations in this illuminating thread, I reckon I have to figure out how to back-pedal my way out of Thomas's bad books - at this point I think he thinks I'm an arsehole... :-(.

[dm319]

(10-22-2023 04:05 PM)MickM Wrote:  I was just doing my best to test his assertion that modifying "E" as requested actually impacted anybody while also dangling whatever carrots I could find while I was at it.

I appreciate your frankness in explaining what you are trying to achieve, but have you considered whether your repeated requests and statements are reasonable? There is a risk that what you are doing is perceived as coercive and harassing.

(10-22-2023 04:05 PM)MickM Wrote:  I feel awkward belaboring this

And yet...

(10-22-2023 04:05 PM)MickM Wrote:  My main takeaway in this thread is needing to conform to the principles of an open source community.

Really? Only in that understanding why people license their work under F/OSS will help you to know what a carrot is.

(10-22-2023 04:05 PM)MickM Wrote:  I reckon I have to figure out how to back-pedal my way out of Thomas's bad books

Honestly, I'd suggest now would be a good time to leave him alone, and start speaking to someone who can help you code what you are after, or use the next-best work around.

[rprosperi]

(10-22-2023 11:38 PM)MickM Wrote:  In light of my realizations in this illuminating thread, I reckon I have to figure out how to back-pedal my way out of Thomas's bad books - at this point I think he thinks I'm an arsehole... :-(.

Probably not... Thomas is quite used to folks asking for this or that to extend Free42 for various reasons. And his record of refusing things that break pure 42S behavior while often embracing other kinds of enhancements is exemplary, and is one of the reasons Free42/Plus42 have become so popular, probably the most widely used HP Calculator Emulator.

But once an idea has been rejected, continuing to advocate for it (to Thomas) surely doesn't win any points. Again, IMHO finding a way to accomplish your goals while keeping standard behavior is your best path to success. I for one, hope you can, as your skin idea is interesting. Most skins simply are decorative or move a handful of buttons around for convenience of some kind, while yours introduces some quite different ideas. I hope it becomes available.

[Nigel (UK)]

I see that your skin includes the "E" key; nothing in the notes says that a number with an exponent must not be followed by one of the prefix keys. If this is the way you want things to work, then this should be brought to your users' attention.

I can't help you to build Free42 on a Mac, or even on Windows. However, it is easy to build it on Linux and I have done so and played with the source code previously. To make the E key behave as you wish, this is what you need to do.

In the source file core_keydown.cc (this is in a folder of code files called common/) locate the following code:

Code:


        if (exp_pos == -1) {
            if (only_zeroes) {
                if (cmdline_length > 0 && cmdline[0] == '-')
                    cmdline_length = 1;
                else
                    cmdline_length = 0;
                cmdline[cmdline_length++] = '1';
                if (seen_dot)
                    cmdline[cmdline_length++] = dot;
            }
            cmdline[cmdline_length++] = 24;
        } else 
            return;

It's in a function called keydown_number_entry; in the version of Free42 that I have it starts on line 387 of the file. This code decides what to do if the E key is pressed. If it hasn't been pressed yet (if exp_pos = -1), then character 24 (small E) is added to the cmdline buffer; if it has been pressed, it is ignored (return).

Change the code to:

Code:


        if (exp_pos == -1) {
            if (only_zeroes) {
                if (cmdline_length > 0 && cmdline[0] == '-')
                    cmdline_length = 1;
                else
                    cmdline_length = 0;
                cmdline[cmdline_length++] = '1';
                if (seen_dot)
                    cmdline[cmdline_length++] = dot;
            }
            cmdline[cmdline_length++] = 24;
        } else { // E pressed a second time
            cmdline_length = exp_pos + 1;
            cmdline[cmdline_length] = 0;
        }

Only the last four lines are different. The comment (the text following //) is optional, but comments are good. The first line shortens the cmdline buffer so that its final character is the first occurrence of "E"; the second line makes the following character zero, which is the standard way of showing the end of a string in C. The code then continues, without a return, to redraw the display.

Isn't open-source great?!

This builds, and for me at least it seems to work as you would wish it to. The usual disclaimers apply: I offer absolutely no guarantee that this will work consistently or that it will not cause problems elsewhere; this new code fragment is under the same open-source licence as the rest of Free42.

I'm not offering you the complete modified file as (a) my version isn't the latest version, and (b) this way you should be able to update any new versions of Free42 that come out.

If you are unable to build Free42 yourself on a Mac, this information should be helpful to whoever you find to build it on your behalf.

I still think that implementing metric prefixes as multiplication by powers of 10 rather than by entering exponents is more straightforward and ultimately more useful (e.g., convert .22 microfarads to nanofarads by pressing .22 mu SHIFT n), but I accept that you disagree.

Good luck!

Nigel (UK)

[MickM]

I've already mentioned to Thomas I'm just going to drop the whole "E" thing at this point. My passion has ticked people off and I'm sorry for that - I just wanted this to be the best skin out there and took things too far I guess.

Nigel, I very much appreciate your coding efforts to provide what I did indeed ask for, but I've since realized this is a double edged sword. You're welcome to my skin if you want to play with it further.

[MickM]

In case you're interested, I'm going to start another thread (tomorrow) for beta-testing this skin and soliciting your comments and feedback now that there is a clear path forward. Thanks to everybody for your advice and guidance.

[dm319]

Nigel UK - I'm very impressed!

MickM - I like your idea. For fun I thought I'd see how a program on the DM42 might look like which could implement this on hardware rather than a skin. I know it isn't quite the same as having a button with the symbol on it, but maybe a 'soft' hardware button is > dedicated software button?

https://youtube.com/shorts/3zBZ-Uk3oM4?feature=share

[MickM]

That's a cool video - I really love the resolution of what can be done on the screen menu boxes vs the ridiculously pixelated version on the HP42S! When designing this skin I definitely thought about doing an in-line multiply vs continuing the numeric entry process using the E key. However, you're forced into "entering" the number without the possibility of further edits, and that multiplication also nukes the T-register. Yes, I know you can use the N-level stack, but I wanted this to work for people who didn't want to use that feature. Additionally, if a user program menu was up and you were feeding it numbers via the menu buttons then the program could easily be corrupted by the unexpected loss of the T-register when you key in such a metric notation number.
I'm going to stick with the way it's currently being done for my skin, although I respect the process of discussion and debate to test assumptions.