DM42pcm-3.20.8 released

Third parties may release their own firmware builds and announce them in this forum.

Please note that bugs found in these firmware releases should be posted in this same forum. SwissMicros provides no support for these firmware releases so in the event of a problem, please contact the author of the firmware in question.

When publishing your own build of the DM42 firmware, we require that you include a notice in your "About" screen informing the user that this version of the firmware is neither provided by nor supported by SwissMicros.
ljubo
Posts: 70
Joined: Sat Jun 20, 2020 1:46 pm
Location: Austria

Re: DM42pcm-3.20.8 released

Post by ljubo »

Thomas Okken wrote:
Sun Jan 30, 2022 10:34 am
Great, thank you! I'll take a look at it this week.

However, I am thinking of integrating this into Plus42, not Free42. I don't think having a permanent CUSTOM menu is very useful when you only have a two-line display. It's the extra space provided by the resizable display in Plus42 that got me interested.
Indeed, two lines display of Free42 is limiting the value of pcm, and one needs a skin with dedicated custom buttons for meaningful usage - nevertheless, having pcm in Free42 would make possible for users to choose two lines display vs. pcm and one line display, and it would create a base for SwissMicros to offer that functionality in hardware too (DM42 has a multi-line display). Up to you of course, feel free to use the patch in Plus42, Free42 or both :-)
HP-15C, DM15L, HP-35S, DM42
Thomas Okken
Posts: 1100
Joined: Tue May 02, 2017 5:48 pm
Location: Netherlands
Contact:

Re: DM42pcm-3.20.8 released

Post by Thomas Okken »

Ljubo, Taking a look at your repo in GitHub, it looks like your entire patch is this. Is that correct?
ljubo
Posts: 70
Joined: Sat Jun 20, 2020 1:46 pm
Location: Austria

Re: DM42pcm-3.20.8 released

Post by ljubo »

Thomas Okken wrote:
Wed Feb 02, 2022 1:12 am
Ljubo, Taking a look at your repo in GitHub, it looks like your entire patch is this. Is that correct?
Yes - that is the patch (I have formulated it also as a pull request here in a case a discussion is needed). By the way, I have built and tested it only on Linux.
HP-15C, DM15L, HP-35S, DM42
Thomas Okken
Posts: 1100
Joined: Tue May 02, 2017 5:48 pm
Location: Netherlands
Contact:

Re: DM42pcm-3.20.8 released

Post by Thomas Okken »

Ah, cool. Thanks!

Now that I'm looking at this, I wonder if this could be done in an even simpler manner. A few days ago, I added a new menu level, between mode_appmenu and mode_plainmenu, so make the UNITS and DIRS catalogs more useful, and I was a bit surprised how easy that change was.

(It feels a bit like I'm exploring someone else's code, but I wrote the menu system 17 years ago, and it has been virtually unchanged since then, and I have hardly looked at it at all in all those years, so I'm a bit foggy on the details!)

But it made me think: maybe it would be cleaner to implement the permanent CUSTOM menu in a similar fashion, by adding a seventh menu level, above mode_appmenu. This would have to be dealt with in get_front_menu() and maybe one or two other places, but not much else would have to change, I think. Even EXITALL could stay the same. And you wouldn't even need a special mode for permanent CUSTOM, since you could still get out of CUSTOM using EXIT, if you want unshifted access to SST and BST for programming.

The only tricky aspect I can see would be the behavior of Shift-2 and SF 27, because if they're going to activate CUSTOM by setting it at this new menu level, then it would override even application menus, and that's not OK, you should still be able to activate CUSTOM on top of application menus, and use EXIT to return to the application menu, without losing your place there. So I guess there would have to be a new command to activate CUSTOM in the new level, separate from activating CUSTOM in mode_plainmenu.
ljubo
Posts: 70
Joined: Sat Jun 20, 2020 1:46 pm
Location: Austria

Re: DM42pcm-3.20.8 released

Post by ljubo »

Thomas Okken wrote:
Wed Feb 02, 2022 10:45 am
Ah, cool. Thanks!

Now that I'm looking at this, I wonder if this could be done in an even simpler manner.
My very first attempt was to "rewire" manu logic by simply changing "const menu_spec menus[]" in common/core_globals.cc and was thinking rest of the code is implemented in an "universal" way and menus variable defines the whole logic and hierarchy of menus - however, it didn't worked :(
A few days ago, I added a new menu level, between mode_appmenu and mode_plainmenu, so make the UNITS and DIRS catalogs more useful, and I was a bit surprised how easy that change was.

(It feels a bit like I'm exploring someone else's code, but I wrote the menu system 17 years ago, and it has been virtually unchanged since then, and I have hardly looked at it at all in all those years, so I'm a bit foggy on the details!)

But it made me think: maybe it would be cleaner to implement the permanent CUSTOM menu in a similar fashion, by adding a seventh menu level, above mode_appmenu. This would have to be dealt with in get_front_menu() and maybe one or two other places, but not much else would have to change, I think.
Ideally there will be general handling of menus and a structure defining the whole hierarchy - where to go if one press "Exit", what are "higher level" menus that are accessible, etc. - similar to "const menu_spec menus[]". Also a state where there are no menus visible should be a "menu" that can be added to this kind of hierarchy. But, I assume that would be a larger rewrite.
Even EXITALL could stay the same. And you wouldn't even need a special mode for permanent CUSTOM, since you could still get out of CUSTOM using EXIT, if you want unshifted access to SST and BST for programming.
BTW, in my implementation you can exit custom menu only in program mode, otherwise "Exit" will not exit the custom menu.
The only tricky aspect I can see would be the behavior of Shift-2 and SF 27, because if they're going to activate CUSTOM by setting it at this new menu level, then it would override even application menus, and that's not OK, you should still be able to activate CUSTOM on top of application menus, and use EXIT to return to the application menu, without losing your place there. So I guess there would have to be a new command to activate CUSTOM in the new level, separate from activating CUSTOM in mode_plainmenu.
Looking forward to your changes, possibly I could merge it back to pcm version of free42 (although, I will be in the same dilemma - current system is working :-))
HP-15C, DM15L, HP-35S, DM42
Thomas Okken
Posts: 1100
Joined: Tue May 02, 2017 5:48 pm
Location: Netherlands
Contact:

Re: DM42pcm-3.20.8 released

Post by Thomas Okken »

ljubo wrote:
Wed Feb 02, 2022 7:43 pm
Ideally there will be general handling of menus and a structure defining the whole hierarchy - where to go if one press "Exit", what are "higher level" menus that are accessible, etc. - similar to "const menu_spec menus[]".
Menu navigation is heavily dependent on context. The menus array as it is now encodes about as much of that hierarchy as I could manage. This covers the behavior of the application and plain function menus, but then you have three different flavors of temporary menus that can become active during command entry, and then there are VARMENU and CATALOG and the programmable menu, each with their own quirks.

I think keyboard handling could be cleaned up significantly, but I'm not so sure about menu handling...
ljubo wrote:
Wed Feb 02, 2022 7:43 pm
Also a state where there are no menus visible should be a "menu" that can be added to this kind of hierarchy. But, I assume that would be a larger rewrite.
That's basically what I'm suggesting, with the added menu level. I'll give it a go once the skins and GRAPH are done.
Thomas Okken
Posts: 1100
Joined: Tue May 02, 2017 5:48 pm
Location: Netherlands
Contact:

Re: DM42pcm-3.20.8 released

Post by Thomas Okken »

Thomas Okken wrote:
Wed Feb 02, 2022 8:01 pm
That's basically what I'm suggesting, with the added menu level. I'll give it a go once the skins and GRAPH are done.
To clarify, the menu levels I'm talking about there are not levels in the directory hierarchy tree, but like transparent layers in which menus can be presented. Free42 has five of those layers, and I'm guessing the HP-42S uses something similar internally.

If there is an active menu in the top layer, it hides whatever menus may be active below it. And only if there is no menu active in any layer, do you see no menu on the screen.

Normally, the application menus (SOLVER, ∫f(x), MATRIX, STAT, BASE, and VARMENU) live in the bottommost layer, while the plain function menus live in the second layer from the bottom. When you activate a function menu on top of an application menu, it isn't added to any hierarchy, it is just activated in that second layer, and when you exit that menu, you'll see the application menu once again, because it was there the whole time, merely hidden by the function menu living in a level higher on the stack.

Each of the five levels has its own function, so menus aren't simply opened in whatever level happens to be free, but in whatever level is appropriate for the current use. So, function menus are always opened in the second layer from the bottom, which is why, after having switched from one function menu to another, EXIT will not take you back from that second menu to the first. The second menu has replaced the first within their layer.

So, adding another level to the stack of menu levels would be a very straightforward and clean hack to make CUSTOM appear when no other menus are active.

Also, this doesn't preclude opening CUSTOM in the plain-menu level. A menu may be open in more than one level at a time; for example, when you do CATALOG → PGM, and then press XEQ, you have the PGM catalog active in the plain-menu level and the command-menu level, or when you go into ALPHA mode and then press STO ENTER, you have the ALPHA menu upen in the alpha-menu and command-menu levels.

So, in summary, using an additional level at the bottom of the menu stack seems like a good solution for implementing permanent CUSTOM. And if showing that layer were conditional upon not being in PRGM mode — which could be achieved by simply adding an 'if' statement to get_front_menu(), I think — then it wouldn't get in the way too much, and you'd only have to use Shift-SST in RUN mode. And the visibility of the new layer could be controlled using a toggle switch in the MODES menu.
Post Reply