DB48X: HP48-like RPL implementation for DM42

[raprism]

(10-21-2024 10:19 AM)c3d Wrote:  If you create a variable called `CST` (which expands to `CustomMenu`), then it will be used as the custom menu content. For example try this:

Code:


{ PATH HOME CRDIR RCL 'A' 42.42 } 'CST' STO

I see (after looking bit late in some hp48gx easycourse) that with some HP48 knowledge I might have found out myself. HP50 seems to use MENU or TMENU, but I do not care (so far).

It's great to have the possibility to try this out quite immediately with Copy-Paste into the simulator.

Only one remark on CustomMenu entry: one could await that unshifted F-key action would enable menu, too. Now it's the same as f-shifted F-key (showing content).

[raprism]

(10-17-2024 06:43 PM)c3d Wrote:  Please be aware that, based on various feedback plus personal experience, I am likely to do one last major keyboard layout change (the primary changes being to put y^x and MTH as primary keys, but also to group things more logically even if it means deviating more from the HP42/DM42). Before I do that, I will put features in that let you customize the keyboard layout, and ship two configuration files for old and new overlays.

For now I would probably go on with the old design. Because I try to avoid key stickers, and 2 more keys that does not show the primary action, might be hard (recognizing that I still forget that LOG label is indeed e^x ...). Therefore it's good to get customization of keyboard layout.

If one wants to change DM42 more radically (because key stickers are needed): It might be interesting to note that in the SwissMicros forum it turns out that for some R47 proposals (which exist as simulators for a desired future hardware design with 2 shift keys like WP43), other mathematical functions were preferred as primary keys. That is TRG instead of SIN/COS/TAN, and LOG and LN are still there.

These decisions are quite dependent on use cases. Sure HP42s tried to expose 1/x, sqrt, log, ln, sin, cos and tan as important, i.e. primary, functions. R47 shifts trigonometric functions away (partially because of the primary goal to have a second shift key), and in the presented new db48x layout e^x and ln are at least single-shifted actions. This might be a working compromise also for me (if having proper overlay).

Your new design looks reasonable for me - in particular the more consistent ordering of menu items (CPLX, REAL) and (MEM,LIB) are fine.

[c3d]

(10-21-2024 11:04 AM)raprism Wrote:  

(10-21-2024 10:19 AM)c3d Wrote:  If you create a variable called `CST` (which expands to `CustomMenu`), then it will be used as the custom menu content. For example try this:

Code:


{ PATH HOME CRDIR RCL 'A' 42.42 } 'CST' STO

I see (after looking bit late in some hp48gx easycourse) that with some HP48 knowledge I might have found out myself. HP50 seems to use MENU or TMENU, but I do not care (so far).

This should be coming soon.

Quote:It's great to have the possibility to try this out quite immediately with Copy-Paste into the simulator.

Only one remark on CustomMenu entry: one could await that unshifted F-key action would enable menu, too. Now it's the same as f-shifted F-key (showing content).

DB48X menus can have up to 18 entries. That is true of the CustomMenu too. So shift-F1 selects entry number 7. This is a difference compared to the HP48 where you can specify the behaviour for left and right shift for each menu entry.

[raprism]

(10-21-2024 04:07 PM)c3d Wrote:  

Quote:Only one remark on CustomMenu entry: one could await that unshifted F-key action would enable menu, too. Now it's the same as f-shifted F-key (showing content).

DB48X menus can have up to 18 entries. That is true of the CustomMenu too. So shift-F1 selects entry number 7. This is a difference compared to the HP48 where you can specify the behaviour for left and right shift for each menu entry.

Okay - good to know.

But my remark was for the "CustomMenu" entry itself. It is shown like other variables, but if it is shown in 1. position, F1 does not change to this CST, but is same action like left-shift F1.

[jibanes]

Quick question, I'm not sure how I got to this, but it says "duplicate" in the left upper corner, why am I seeing this and how to remove it? (see pict)

thank you!

[c3d]

(10-27-2024 11:17 AM)jibanes Wrote:  Quick question, I'm not sure how I got to this, but it says "duplicate" in the left upper corner, why am I seeing this and how to remove it? (see pict)

thank you!

This is the debugger showing the next instruction. It means that you either had an error running Duplicate (that would probably be an empty stack), or that you interrupted a program while it was about to execute Duplicate. In both cases, it drops you into the debugger.

Normally, the DebugMenu should have shown up. If you need to bring the DebugMenu back, use shift-shift-1. With the DebugMenu shown, you can interrupt execution by hitting F6 for Kill. Or you can fix the problem and hit Continue with F5, or use Step, Over (step over calls) or Steps (run a give number of steps).

Whether you debug on error can be configured with the DebugOnError / KillOnError flags. HP calculators do not have such implicit debugging that I know of (i.e. you need to explicitly tell you want to debug a program). Maybe I should not have made DebugOnError the default.

[jibanes]

Thank you!/Merci !

[BruceH]

On the subject of shifted menu item behaviour: what do people feel about the highlighted row dropping back down to "unshifted" after selecting a menu item?

For example, I entered 3.5, went into the FRAC menu and pressed ->Frac to see it as a fraction. I then did SHIFT SHIFT [1 1/2] to see it as a top-heavy fraction, decided to go back so pressed menu key 5 again only to find that the menu selection had changed.

So my question is: should the selected menu row stay so that an item that is a toggle works naturally as a toggle, without having to press SHIFT SHIFT again?

As a point of comparison, the HP48 keeps the same menu page displayed when an item is selected - it doesn't jump back to the first page of a multi-page menu, which is what is effectively happening here.

[c3d]

(10-27-2024 07:32 PM)BruceH Wrote:  On the subject of shifted menu item behaviour: what do people feel about the highlighted row dropping back down to "unshifted" after selecting a menu item?

For example, I entered 3.5, went into the FRAC menu and pressed ->Frac to see it as a fraction. I then did SHIFT SHIFT [1 1/2] to see it as a top-heavy fraction, decided to go back so pressed menu key 5 again only to find that the menu selection had changed.

So my question is: should the selected menu row stay so that an item that is a toggle works naturally as a toggle, without having to press SHIFT SHIFT again?

The behaviour of shift with function keys is intended to be similar to the behaviour with regular keys. When you use shift-SIN, and then press SIN again, you expect SIN and not ARCSIN. So the behaviour is full intentional. The rationale is that function keys had some shift behaviour on the HP48, but that those were under-exploited, and not visible in the menu label.

That being said, if the behaviour annoys you, you can use the FlatMenus mode (Modes > UI > Flat), in which case the same function is shown for each function key irrespective of the shift state. The downside, obviously, is that there are more menu pages, so functions are not as easy to find.

Quote:As a point of comparison, the HP48 keeps the same menu page displayed when an item is selected - it doesn't jump back to the first page of a multi-page menu, which is what is effectively happening here.

No, there are also pages in DB48X menu, when more than 18 items need to be shown in a given menu (or 6 in FlatMenus mode). In that case, only 15 entries are shown per page (5 in FlatMenus mode), and the F6 / Shift F6 keys turn into Next / Previous. That page number does not change when you select a menu.

So again, think of the additional menu entries as being the same as the functions marked in yellow or blue on the keyboard of an HP48SX, not the same as the pages of a menu.

This is made plainly visible for the VariablesMenu (VAR key). For each variable, this menu offers three choices, Evaluate, Recall and Store. These are the same as in the VAR menu on the HP48, except that left and right shift are swapped because the right shift is more expensive (two hits of the shift key), so I used that for Store, which is more "dangerous". (Also, the HP48 always felt backwards to me, because I associate left to "back" or "past" and right to "forward" or "future", and to me, RCL associates more naturally to left and STO to right than the opposite, but I digress). For that reason, the VariablesMenu still displays on three rows even in FlatMenus mode.

Hope this helps and makes sense.

[LinusSch]

(10-27-2024 03:57 PM)c3d Wrote:  Whether you debug on error can be configured with the DebugOnError / KillOnError flags. HP calculators do not have such implicit debugging that I know of (i.e. you need to explicitly tell you want to debug a program). Maybe I should not have made DebugOnError the default.

DebugOnError is a very good thing to have, but yeah, it is probably not expected as default behavior. Kill and report the error is what is normally expected, I think.

[c3d]

Release 0.8.3 "Blindness" - User mode and custom header

This release focuses on various user interface aspects. It introduces support for the User mode (key assignments) and a custom header (for example if you want to show the path or other information in the header). Also, the builtin help now automatically adds hyperlinks for all the commands referenced in the documentation.

It also fixes a number of bugs, including a serious one that could cause memory corruption while editing.

[jibanes]

I wonder how far this project is from being able to run on hp50g?

[c3d]

(10-28-2024 10:23 PM)jibanes Wrote:  I wonder how far this project is from being able to run on hp50g?

Not as far as you might think.

Historically, I began tinkering newRPL, which does run on Prime and HP50. So I have a working development platform. I restarted DB48x from scratch with such a heavy focus on low-memory usage when it appeared that newRPL was about twice too big for the DM42.

I may restart the HP50G and HP Prime efforts if there is sufficient interest. But probably not before I reach 1.0 on the DM42.

[jibanes]

That's great news, thanks for sharing!

[nickapos]

I would love to have DB48X in physical form, and I do not have a DM42 but I do have a 50g so that would be a great option if it existed.

[LinusSch]

I too have no DMCP calc but I do have a spare 50g - originally bought half as a spare, half for tinkering with newRPL, as I really don't dare be without a standard 50g in working order. Yet.

I count three of us, so far. Not a lot, but I'll try to set up for working on this!

Not sure how much time I will find for this project, I certainly won't be able to keep up with the pace db48x has shown so far. But when/if it eventually works it should not be too much effort to keep new releases working, I hope.

[c3d]

(10-29-2024 11:17 PM)LinusSch Wrote:  I too have no DMCP calc but I do have a spare 50g - originally bought half as a spare, half for tinkering with newRPL, as I really don't dare be without a standard 50g in working order. Yet.

I count three of us, so far. Not a lot, but I'll try to set up for working on this!

Not sure how much time I will find for this project, I certainly won't be able to keep up with the pace db48x has shown so far. But when/if it eventually works it should not be too much effort to keep new releases working, I hope.

Thanks for bringing that to my attention.

I posted a poll on the topic. Please feel it to try and get a feeling for the numbers.

[Helix]

Thank you for the poll. I think that posting it in the Prime forum may lead to somewhat biased results.

Although I'm very interested in DB48X, I still haven't bought a DM42 for two reasons: it's expensive, and I really hate having to put stickers on the keys. So I’m more interested in a version for the HP50g.

[Maximilian Hohmann]

Hello!

(10-30-2024 11:11 AM)Helix Wrote:  Although I'm very interested in DB48X, I still haven't bought a DM42 for two reasons: it's expensive, and I really hate having to put stickers on the keys. So I’m more interested in a version for the HP50g.

Same here, but with one difference: I don't want this to be on an HP50g with stickers either. After seeing and touching the calculator with my own hands last weekend, I want HP, or Moravia, to bring this out. On dedicated hardware. If they are able make something like the HP-15C CE, then why not a DB, or rather HP48X?

Regards
Max

[floppy]

Exact. For me,
- the DMx path is way too expensive
- the other direction (most impressive for me this year) is the RPN83 way: with very very cheap HP83 or HP84 hardware, you can have an RPN calculator.
So, please, we need now the calculator for the poor, and not only calculators for the rich.