What has the DM41 extra over the HP42s?

[Werner]

But you can use GETKEY to simulate key assignments ;-)
If only GETKEY would catch the EXIT key... that has bothered me since the beginning, I do not see the logic. MENUs catch the EXIT key, so why not GETKEY? Neither catches R/S, so there's no danger of getting 'stuck'. It keeps me from having a perfect GETKEY MENU simulation (in the Matrix Viewer). Would it be too much to ask for it to be changed in Free42? After all, it doesn't break backward compatibility..

Cheers, Werner

[Thomas Okken]

(11-05-2020 07:55 AM)Werner Wrote:  But you can use GETKEY to simulate key assignments ;-)
If only GETKEY would catch the EXIT key... that has bothered me since the beginning, I do not see the logic. MENUs catch the EXIT key, so why not GETKEY? Neither catches R/S, so there's no danger of getting 'stuck'. It keeps me from having a perfect GETKEY MENU simulation (in the Matrix Viewer). Would it be too much to ask for it to be changed in Free42? After all, it doesn't break backward compatibility..

Hmm. Interesting. Yes, as long as GETKEY doesn't catch R/S, catching EXIT does seem safe, although maybe a bit non-obvious since the "running" annunciator is off during GETKEY.

The HP-41 Extended Functions version of GETKEY catches all keys, even ON, USER, PRGM, ALPHA, Shift, and R/S. That would be a bridge too far in Free42, I think... It looks like the HP-42S designers didn't like that behavior, either; it may be significant that they gave the 42S GETKEY a different XROM code, unlike how they handled other X-Fcn functions they borrowed.

[Paul Dale]

That's interesting. On the 42S, ON-C would still be an escape from a GETKEY gaol wouldn't it?

Pauli

[Werner]

Paul: GETKEY does catch EXIT and R/S, but stops execution. It would be nice if for EXIT, it would continue execution as with MENU KEY 9. R/S always stops execution. And ON-C resets the machine, also during GETKEY ;-)
Werner

[Thomas Okken]

I just checked and it turns out that there is a silly bug in GETKEY that causes it to catch Shift-EXIT ("catch" as in "not stop"), which the real HP-42S doesn't. Doh. I'll fix that.

I'm not entirely comfortable changing the behavior of GETKEY, though. I agree that catching EXIT (and Shift-EXIT) is basically safe as long as R/S is not caught, but because the "running" annunciator is off during GETKEY, it is not obvious that R/S is the key to use to get out of, say, a game that uses GETKEY. I'd be inclined to hit EXIT when the calculator is in an unusual mode and I want to get out.

I could add another GETKEY, let's call it GETKEY1 for purposes of discussion, that does catch EXIT and Shift-EXIT. Adding a preferences setting to control the EXIT behavior of the regular GETKEY is just going to cause confusion, I think.

Thoughts?

[Marco Polo]

(11-05-2020 01:00 PM)Thomas Okken Wrote:  I just checked and it turns out that there is a silly bug in GETKEY that causes it to catch Shift-EXIT ("catch" as in "not stop"), which the real HP-42S doesn't. Doh. I'll fix that.

I would like to highlight one aspect which makes Free42/DM42 preferable when compared to DM41x. IMHO.
Free42 is actively mantained with prompt bug fixes and improvements.
DM41x relies on HP41 roms, and i am not aware about further development. I might be wrong...

[Werner]

(11-05-2020 01:00 PM)Thomas Okken Wrote:  I agree that catching EXIT (and Shift-EXIT) is basically safe as long as R/S is not caught, but because the "running" annunciator is off during GETKEY, it is not obvious that R/S is the key to use to get out of, say, a game that uses GETKEY.

Thoughts?

Well that is the point: I want to use EXIT to cleanly get out of the game (or anything else), but I can't because EXIT stops the game.. and so I have to provide a specific other button to quit.
The MENUs don't have the running annunciator, either, BTW.

Werner

[Thomas Okken]

I was thinking of, say, MINEHUNT, which just ignores keys it doesn't specifically handle, and that would include EXIT.

[Werner]

Yes, I see what you mean.
If you change GETKEY itself, all the old programs that ignored EXIT (all of them, basically) could no longer be stopped by it.
hm.. another command it is, then..
Why not GETKEYX, with a matrix of allowed keycodes in X, or GETKEYA with the keycodes XTOA'd in the Alpha register. This is what is needed all the time anyway.
Slight preference for the former as it doesn't have a 44-key limit ;-)
Werner

[mfleming]

(11-05-2020 01:14 PM)Marco Polo Wrote:  DM41x relies on HP41 roms, and i am not aware about further development. I might be wrong...

You are Ask Ángel or Håkan for details. Nice caveat save...

[hth]

(11-05-2020 01:14 PM)Marco Polo Wrote:  I would like to highlight one aspect which makes Free42/DM42 preferable when compared to DM41x. IMHO.
Free42 is actively mantained with prompt bug fixes and improvements.
DM41x relies on HP41 roms, and i am not aware about further development. I might be wrong...

I do things with the HP-41 ROMs.

First of all, it is of course impossible to alter the ones in existing genuine original HP-41. Well, not impossible on the older hardware, but hardly a practical route. Anyway, read on.

For the firmware itself I have recreated the source and it is buildable. I have made a version that corrects bugs in the original ROMs and also added a new feature (more extended memory). This requires the HP-41CL and is available from the 41CL update channel. I have asked about the possibility to do similar things on the DM41X, but it is not allowed there at the moment.

For further extensions there is the OS4 module which you can find on Github. This module works with any HP-41 model and can be seen as a further development of the firmware. OS4 provides frameworks for custom keyboards which allows you to replace the built-in standard keyboard using a very flexible mechanism called shells. This makes it possible to turn your HP-41 basically anything else, for example an HP-16C. No custom menus or menus for that matter, just plain native full keyboard control with press down and hold keys that says what they will do. OS4 provides programmable prompting functions (single and dual arguments) and it eliminates the FAT limitation of 64 functions. The number of function you put in a module is only limited by available memory.

At the moment I am not doing mainframe/firmware fixes as I do not have any bugs that I think need to be fixed. Please let me know if there are. OS4 is being worked on at the moment, though most HP-41 work on that side is on its companion module (Boost).

The reason this is possible is thanks to the open nature of the HP-41, made possible by HP a long time ago. It is also helped by the fact that the HP-41 is written with extensibility in mind and in a language that allows it, it is not a C program. Thus, the HP-41 is a very nice open retro programming environment and a hacker's dream. You are not constrained by the user language you can read about in the owner's manual, you can go much further if you like.

References:
https://www.hpmuseum.org/forum/thread-13...=mainframe
https://github.com/hth313/OS4
https://github.com/hth313/boost41
https://github.com/hth313/ladybug

[hth]

I can add that the HP-41 and HP-42 were made with different goals. The HP-41 was an extensible system which makes it more than a calculator. It was actually a base model, but eventually no more advanced model were created thanks to the way it could be added to and configured by the user. The HP-42 is a calculator much like the HP-15C, but also based on the ideas from the HP-41. It was made later and should be more refined, as they could base it on more previous experience. However, not everything carried over and some people just prefer the older model thanks to the way it was more than a calculator. If you do not really know what you want, or if you just want a calculator and are happy with user programs, then you will probably prefer the HP-42. If you have experienced the HP-41, like to explore things and tinker with it at a much greater depth, then you will probably want the HP-41. Another aspect is the huge existing software base for the HP-41 which you may like to explore.

[Thomas Okken]

(11-05-2020 02:11 PM)Werner Wrote:  hm.. another command it is, then..
Why not GETKEYX, with a matrix of allowed keycodes in X, or GETKEYA with the keycodes XTOA'd in the Alpha register. This is what is needed all the time anyway.
Slight preference for the former as it doesn't have a 44-key limit ;-)

That's a bit heavy-weight for my taste. The functionality is useful but I think it belongs in user code.

I'm leaning toward GETKEY1 (or something else, I don't have strong feelings about the name) which would simply not stop on any key. It would still treat Shift the way the original GETKEY does because changing that would get very ugly.

It would still be possible to get out of an endless loop, by exiting and restarting the app. I guess it would need a tweak to deal with malicious code that uses flag 11 to restart itself, but that could be handled similarly to what OFF does.

[Dave Britten]

(11-06-2020 02:58 PM)Thomas Okken Wrote:  

(11-05-2020 02:11 PM)Werner Wrote:  hm.. another command it is, then..
Why not GETKEYX, with a matrix of allowed keycodes in X, or GETKEYA with the keycodes XTOA'd in the Alpha register. This is what is needed all the time anyway.
Slight preference for the former as it doesn't have a 44-key limit ;-)

That's a bit heavy-weight for my taste. The functionality is useful but I think it belongs in user code.

I'm leaning toward GETKEY1 (or something else, I don't have strong feelings about the name) which would simply not stop on any key. It would still treat Shift the way the original GETKEY does because changing that would get very ugly.

It would still be possible to get out of an endless loop, by exiting and restarting the app. I guess it would need a tweak to deal with malicious code that uses flag 11 to restart itself, but that could be handled similarly to what OFF does.

How about just holding EXIT or R/S for one second or so to halt the program when GETKEY1 (or whatever it ends up being called) is waiting for input? It would be sort of like holding a key until NULL is displayed.

[Werner]

Okay.. then I can post my GETKEY routines to catch a list of allowable keys ;-) They will not become obsolete ;-)
Werner

[Werner]

GETKANY
GETKNY
GETANYK
GKANY

[Thomas Okken]

It could also catch everything except Shift-EXIT. That way, no tricky work-arounds would be needed to break out of buggy or malicious loops, you could still handle EXIT and R/S in a customized manner, and Shift-EXIT isn't likely to clash with anything else people might want to use that key combination for. And it's something that breaks out of the original GETKEY as well — though not out of the current Free42 GETKEY, due to the silly bug I alluded to before.

[Werner]

Shift-EXIT is OK. R/S would be ok too.. as long as I can catch EXIT ;-)
I certainly prefer to have a key to break out, instead of having to 'exit the app' or so.
(how would that work on a DM42 then?)
Werner

[Thomas Okken]

Yes, there isn't much of a reason to catch R/S either. Just EXIT. As long as it's a new instruction and the regular GETKEY isn't affected, anything goes basically... and the existing GETKEY is fine except for the halting-on-EXIT part.

[Thomas Okken]

(11-06-2020 03:24 PM)Dave Britten Wrote:  How about just holding EXIT or R/S for one second or so to halt the program when GETKEY1 (or whatever it ends up being called) is waiting for input? It would be sort of like holding a key until NULL is displayed.

I kind of like the idea, but that would be a royal pain to implement...