DM32

[jonmoore]

Plus42 running on DM42 hardware is my second most wanted hardware calculator. It's interesting to compare the design strategy of Plus42 vs other 42 inspired designs.

Some take the "everything but the kitchen sink" approach to improving on the 42S, whilst Thomas has chosen a smart selection of enhancements that already exist across various HP calculator implementations, each of which is a proven toolset. In daily use, it's still a 42S. The new modifications are a keystroke away but they don't get in the way of the 42s interaction model we know so well.

I'd like to see deeper programming integration between the new modifications and the classic 42S programming approach but Thomas has promised this for a future iteration.

My most wanted hardware calculator is a 48GX clone; one with a modern hi-resolution display (and faster processor). RPL may be the antithesis of classic RPN for many, but I'm fine with it. I think it's useful if you get to grips with RPL on the 28S first, and then on a vanilla 48 (when the language was relatively small, and the symbolic capabilities were still minor in comparison to what they became in the 50g). I'm talking UserRPL here. SystemRPL and assembly, that's a whole other rabbit hole!

[Thomas Okken]

(05-10-2022 12:05 PM)jonmoore Wrote:  I'd like to see deeper programming integration between the new modifications and the classic 42S programming approach but Thomas has promised this for a future iteration.

Suggestions are always welcome!

(05-10-2022 12:05 PM)jonmoore Wrote:  RPL may be the antithesis of classic RPN for many, but I'm fine with it.

With the big RPN stack, big RTN stack, and local variables, Free42 and Plus42 getting close to RPL in terms of programming capability. Having done the equation-to-RPN compiler for Plus42, I think an RPL-to-RPN compiler isn't totally out of the question, either. Or HP-BASIC-to-RPN... The Free42 programming environment is actually a wonderfully easy target for compiler back-ends.

[Marco Polo]

(05-10-2022 12:05 PM)jonmoore Wrote:  Plus42 running on DM42 hardware is my second most wanted hardware calculator. It's interesting to compare the design strategy of Plus42 vs other 42 inspired designs.

Some take the "everything but the kitchen sink" approach to improving on the 42S, whilst Thomas has chosen a smart selection of enhancements that already exist across various HP calculator implementations, each of which is a proven toolset. In daily use, it's still a 42S. The new modifications are a keystroke away but they don't get in the way of the 42s interaction model we know so well.

I'd like to see deeper programming integration between the new modifications and the classic 42S programming approach but Thomas has promised this for a future iteration.

More or less the same feeling for me.
Despite Thomas' huge and awesome effort, I am still playing with Windows version because Plus42 it cannot yet totally replace the 48/50 i use daily:
- no Multiple Equation Solver (the 48/50 even handles units; at present, it is a "no-go" limitation for me)
- somewhat limited Unit management (i could live with it)
- less flexibility than the HP RPL series (this is from the real 42s)

Quote:My most wanted hardware calculator is a 48GX clone; one with a modern hi-resolution display (and faster processor). RPL may be the antithesis of classic RPN for many, but I'm fine with it.

Totally agree. I greatly prefer the RPL due to the consistency in object handling.
The 48gx for me is the best compromise between the "spartan" 48sx and the too much pimped 50g

[Thomas Okken]

(05-10-2022 02:09 PM)Marco Polo Wrote:  - no Multiple Equation Solver (the 48/50 even handles units; at present, it is a "no-go" limitation for me)

That is something I would like to add. I don't know anything about suitable algorithms, though.

(05-10-2022 02:09 PM)Marco Polo Wrote:  - somewhat limited Unit management (i could live with it)

Oy vey! What did I miss?

[Marco Polo]

(05-10-2022 02:30 PM)Thomas Okken Wrote:  Oy vey! What did I miss?

I think you did not miss anything.
The use of Custom menu with units is quite limited, compared to the "48 way".

I think it is more a limitation of 42s architecture: you cannot add, for example, a program directly to a custom key but you first have to write and name it into PRGM area

On the 48 i added to CST menu 1_ft^2*°F*h/Btu (heat exchanger fouling factor) very easily: i just created: {'1_ft^2*°F*h/Btu'} 'CST' STO

On Plus42 i shall define the variable "Foul" (or whatever) containing the unit combination and add to Custom menu.
But in this way i get, for example 0.02_Foul while i would prefer to get 0.02_ft^2*°F*h/Btu (like on 48)

I cannot exclude i am doing something wrong/stupid :-)

BTW, thanks to 48 custom menu flexibility, i completely rearranged the Units menu for my needs: you can throw in custom menu virtually anything without saving a single variable/program/etc.

[Thomas Okken]

I see. Yes, that does look like a better way of doing things.

The Free42 / Plus42 CUSTOM works exactly like the one in the HP-42S, where a key assignment is nothing but a character string of up to 7 characters. Whether this string refers to a LBL, variable, or built-in function, is resolved only when the key is pressed. I implemented it that way for 100.000% backward compatibility, and with all the new capabilities in Plus42, that architecture is starting to feel a bit awkward!

[John Keith]

(05-10-2022 12:05 PM)jonmoore Wrote:  Plus42 running on DM42 hardware is my second most wanted hardware calculator. It's interesting to compare the design strategy of Plus42 vs other 42 inspired designs.

...

My most wanted hardware calculator is a 48GX clone; one with a modern hi-resolution display (and faster processor). RPL may be the antithesis of classic RPN for many, but I'm fine with it. I think it's useful if you get to grips with RPL on the 28S first, and then on a vanilla 48 (when the language was relatively small, and the symbolic capabilities were still minor in comparison to what they became in the 50g). I'm talking UserRPL here. SystemRPL and assembly, that's a whole other rabbit hole!

I would like to see SM (or someone) make a hardware platform comparable to the Prime G2 in processor speed and memory capacity, along with a larger keyboard. This would not only allow NewRPL and/or EMU48 to have a proper hardware platform but also allow Plus42 to have the RAM and processor speed to really take advantage of its new capabilities.

I would also prefer the keyboard layout of the 48G but I see no reason not to have the full 50g functionality.

[Marco Polo]

(05-10-2022 03:25 PM)Thomas Okken Wrote:  I implemented it that way for 100.000% backward compatibility, and with all the new capabilities in Plus42, that architecture is starting to feel a bit awkward!

I see your point.
All the new features of Plus42 are pushing towards an extension of the base system over Free42.
For example, Plus42 makes use of Lists, but AFAIK there is no way for the user to handle them.
Of course i can create and modify on a pc an then copy/paste, but having such capabilities on the app would open the way for many improvements.
But such development path seems to me to converge to a sort of 48s "RPN Edition" :-D

[Thomas Okken]

(05-10-2022 05:45 PM)Marco Polo Wrote:  For example, Plus42 makes use of Lists, but AFAIK there is no way for the user to handle them.

Not yet...

[andylithia]

(05-09-2022 06:46 AM)ijabbott Wrote:  

(05-08-2022 11:37 PM)andylithia Wrote:  wait... I thought the 32SII ROM code has never been extracted.

Look for the latest addition at Pictures at an exhibition of essentials.

Haha! Such wonderful works of art! I was so obsessed that I have to stand on my head.

[Steve Simpkin]

(05-11-2022 01:56 AM)andylithia Wrote:  

(05-09-2022 06:46 AM)ijabbott Wrote:  Look for the latest addition at Pictures at an exhibition of essentials.

Haha! Such wonderful works of art! I was so obsessed that I have to stand on my head.

I now have a good understanding of the PNG file format and am very familiar with Hex editors. Despite this, all of my experiments only produce a blank LCD. If someone could PM me with some additional tips
, I would be grateful.

[ Edit - Someone sent a PM with the answer. Thank you! ]

[jonmoore]

(05-10-2022 02:06 PM)Thomas Okken Wrote:  

(05-10-2022 12:05 PM)jonmoore Wrote:  I'd like to see deeper programming integration between the new modifications and the classic 42S programming approach but Thomas has promised this for a future iteration.

Suggestions are always welcome!

(05-10-2022 12:05 PM)jonmoore Wrote:  RPL may be the antithesis of classic RPN for many, but I'm fine with it.

With the big RPN stack, big RTN stack, and local variables, Free42 and Plus42 getting close to RPL in terms of programming capability. Having done the equation-to-RPN compiler for Plus42, I think an RPL-to-RPN compiler isn't totally out of the question, either. Or HP-BASIC-to-RPN... The Free42 programming environment is actually a wonderfully easy target for compiler back-ends.

Totally agreed that the enhancements added in Plus42 are bringing us closer to RPL, and best of all this is achieved without sacrificing the immediacy of keystroke programming.

On the first point regarding suggestions, I'm not ignoring the request, but I'd rather answer it when I've lived with Plus42 a little longer. But taking a holistic view, what I'd like to see in general terms is no sense of 'walled gardens' with regard to the new areas of functionality to the classic RPN keystroke programming toolset.

I'd also like to see some of the stack manipulation tools from RPL to be added too. Once you have an extended 'big RPN' stack', simple R▼ and R▲ controls can end up being inefficient. A good point of reference is Bill Wickes 'Insights and Principles of the HP 28C/S'. Some of what he talks about is the manner in which the RPL stack doesn't feature stack lift, or truly empty stack registers (empty stack registers in classic RPN calculators are filled with zeros); but there are great insights into the wider set of stack manipulation tools that were added to RPL from the 28C/S onwards (Bill's 48 insights book is worth checking too as the stack manipulation tools went through generational tweaks.

[Thomas Okken]

(05-11-2022 11:49 AM)jonmoore Wrote:  I'd also like to see some of the stack manipulation tools from RPL to be added too. Once you have an extended 'big RPN' stack', simple R▼ and R▲ controls can end up being inefficient.

Most of those are already there. I think only UNDO is missing:
https://thomasokken.com/free42/#big-stack

[jonmoore]

(05-11-2022 04:38 PM)Thomas Okken Wrote:  

(05-11-2022 11:49 AM)jonmoore Wrote:  I'd also like to see some of the stack manipulation tools from RPL to be added too. Once you have an extended 'big RPN' stack', simple R▼ and R▲ controls can end up being inefficient.

Most of those are already there. I think only UNDO is missing:
https://thomasokken.com/free42/#big-stack

Cool. I definitely need to live with Plus42 a little more having missed that!

Although having said that, I think these extended stack manipulation tools are a little too buried two levels in either direction of the Catalog set of soft menus. Much as I like %CH having a top-level presence in the new top shifted menu options, I believe STK is more deserving of that prime position. Both %CH and SST△ seem a little wasteful in the sense that they are single operations rather than shifted keys that open a further selection of operations.

With regards to %CH, is there any reason that the shifted % key couldn't be made to open a soft menu with %, %CH & %T. That shouldn't break backwards compatibility should it? Programs that use % recognise it as a symbol/ID rather than the specific key location on the faceplate.

[Thomas Okken]

Until I implement an HP-41-like full-keyboard ASSIGN, every layout I come up with will be sub-optimal for some people, I'm afraid! %CH, R↑, X<>, and VIEW were all specifically requested, I felt DIRS, DIR.FCN, UNITS, UNIT.FCN, EQN, EQN.FCN, PLOT, and TVM all needed to be on the keyboard because they are basically what Plus42 is all about, SST↑ is something I personally really want on the keyboard (professional deformation on my part), and everything else is where it is for the sake of HP-42S compatibility. For me personally, the stack-related functions didn't need to be on the keyboard, because I regard them primarily as programming functions, and for everyday use, I tend to stick with the 4-level stack.

[Vincent Weber]

I feel that Thomas has found the holy grail: merging the best of the 42S, 41CX, 27S, 19BII, 32SII and 35S in one unit, without loosing anything from the 42S philosophy.

Going beyond that is a slippery rope and dangerous IMHO. If I want a 48 (which happens to me once in a while, the 48SX was my student calculator, I will always cherish it), I fire Emu48 and I have everything about the 48...

The only feature I initially didn't welcome at all in Plus42 was precisely the infinite stack. I felt this was paving the way for RPL, which I certainly didn't want on the ultimate heir of a long tradition of simple 4-level RPN calculators ! Well, I cooled off a lot when I understood that the infinite stack was instrumental in implementing equations that can blend nicely with RPN programs, so Thomas was right to do it; whether or not he was right to expose the functionality to the users, and therefore wet the appetite of proponents of a full 48 simulator, is another debate...

There are a few additions that would (will - they are on the way I think) desirable:
-a full alpha keyboard (although the need is reduced by all the clever shortcuts for commands in equations);
-L and ALPHA optionnally visible on screen (à la DM42);
-A full list editor, since the type is there, and since the 27S/19BII also has it;
-A full screen matrix editor;
-Scattered points and histogram bar graph types, as in the 19BII;
-One-line complex number entry, à la 35S;
-Fraction type, à la 32SII/35S.

Going much being that would denature Plus42 and change the gold into lead, IMHO...

My 2 cents.

[rprosperi]

Guys - suggest you move the Plus42 discussion to the Plus42 thread where folks will expect to see such posts. Feedback and discussion of proposed new features in particular are helpful to Plus42 users and folks reading there would appreciate seeing these comments. I'd move them, but it's less disruptive if the conversation just moves there by itself.

[Eddie W. Shore]

Initial thoughts of the DM32:

1. Glad to see the color scheme. My favorite color scheme is the orange/blue instead of green/purple. Personal choice only.

2. How will the labels be handled?
(a) Classic 32S/33S Method: by letter only
(b) 35S Method: Letter plus step number, like A001
(c) Something different: for example, labels up to three/four letters, LBL "AREA", LBL "SPC", etc.

3. I expect USB connectivity. I will be surprised if it doesn't.

4. Will there be any extras? Example: Boolean functions (AND, OR, NOT, XOR).

5. I expect memory to be higher than 32,000 bytes, certainty higher than the original 390. Again, I will be surprised if it doesn't.

6. I expect that I will be purchasing one close to the day DM32 is sold to the public.

[ctrclckws]

(05-12-2022 12:49 PM)Eddie W. Shore Wrote:  6. I expect that I will be purchasing one close to the day DM32 is sold to the public.

Probably will also, just because...

[Dave Britten]

(05-12-2022 12:49 PM)Eddie W. Shore Wrote:  Initial thoughts of the DM32:

1. Glad to see the color scheme. My favorite color scheme is the orange/blue instead of green/purple. Personal choice only.

2. How will the labels be handled?
(a) Classic 32S/33S Method: by letter only
(b) 35S Method: Letter plus step number, like A001
(c) Something different: for example, labels up to three/four letters, LBL "AREA", LBL "SPC", etc.

3. I expect USB connectivity. I will be surprised if it doesn't.

4. Will there be any extras? Example: Boolean functions (AND, OR, NOT, XOR).

5. I expect memory to be higher than 32,000 bytes, certainty higher than the original 390. Again, I will be surprised if it doesn't.

6. I expect that I will be purchasing one close to the day DM32 is sold to the public.

#2: I'm definitely curious about this as well. At the very least, I'm assuming there will be a mechanism to swap between RAM images, which could act as an ersatz global label/program area.

#3: Given, since the device will need to support firmware updates.

#4: I hope so! The lack of Boolean operators is one of the biggest shortcomings of the 32SII in my opinion. But if there's lots of RAM, we can at least add this functionality with programs.

#5: No doubt. I'm sure we won't be limited to 384 bytes or whatever. But the way in which it's handled remains to be seen.