DB48X: HP48-like RPL implementation for DM42

[c3d]

(05-20-2024 05:03 AM)sunpazed Wrote:  Hi Christophe — you might be interested in this little side project of mine. As a proof-of-concept, I built a version of your simulator that runs in the web-broswer (and therefore on mobile devices). I found that Qt runs fairly sluggishly after some time, so that was part of my motivation. It's also quite nice to use db48x in the palm of your hand (as I don't yet have a dm42!).

Here's what it looks like on my iPhone;


Try it in your browser here — the simulator can be run fullscreen by selecting "Add to Home Screen" on iOS or your Android device;
https://sunpazed.github.io/db48x-wasm/bin/index.html

Be warned that there are many bugs, with the simulator hanging when accessing system services (help, save state, system menu) which are not implemented .

And finally here's the repo for review; https://github.com/sunpazed/db48x-wasm — apologies in advance for butchering your excellent code.

This is amazingly cool. I will see if I can merge your code with the main repo in a meaningful way, so that you don't have to reapply the patches every time. Also, I found a few bugs here and there, and it would be nice if the fixes specific to wasm and the main branch were kept in sync easily.

That being said, I don't recommend this approach for mobile devices, since it's bound to consume a lot more resources, which are a bit scarce. So while I fully intend to leverage your work for example to integrate in the web site, I think that we need to have native versions for mobile phones.

For Android, I have not reinstalled the SDK in a while, but my recollection was that targeting the Android SDK with Qt was relatively easy. Like for Windows, it would be nice to have someone familiar with the platform picking that up. Otherwise, I'll do that myself "sometimes in the future™".

For iOS, I have a native version that is working on both iPhone and iPad. I need to spend the time to go through the hoops to get it published on the Apple Store. This is one of the reasons why there is colour support in the simulator ;-)

[spiff72]

Seeing this project show up for iOS I'm the App Store will be an exciting day for me! Does that make me a full-fledged calculator nerd?

And this web based side project is pretty cool!

[c3d]

(05-20-2024 06:39 AM)Steve Simpkin Wrote:  

(05-20-2024 05:03 AM)sunpazed Wrote:  Hi Christophe — you might be interested in this little side project of mine. As a proof-of-concept, I built a version of your simulator that runs in the web-broswer (and therefore on mobile devices). I found that Qt runs fairly sluggishly after some time, so that was part of my motivation. It's also quite nice to use db48x in the palm of your hand (as I don't yet have a dm42!).

Here's what it looks like on my iPhone;


Try it in your browser here — the simulator can be run fullscreen by selecting "Add to Home Screen" on iOS or your Android device;
https://sunpazed.github.io/db48x-wasm/bin/index.html

Be warned that there are many bugs, with the simulator hanging when accessing system services (help, save state, system menu) which are not implemented .

And finally here's the repo for review; https://github.com/sunpazed/db48x-wasm — apologies in advance for butchering your excellent code.

I can't tell you how awesome your side project is! I have been wanting to play with the DB48X project for so long but did not have access to a Mac or linux computer. Thank you very much!

I have added some links and general information about the HP48X project along with your side project to the features comparison table and photo gallery site I maintain.
https://sites.google.com/view/hp-plus-ca...sykspy4p3m

Great page. Thanks a lot for maintaining it!

[c3d]

(05-20-2024 12:49 PM)spiff72 Wrote:  Does that make me a full-fledged calculator nerd?

You had any doubt about this?

[sunpazed]

(05-20-2024 12:46 PM)c3d Wrote:  This is amazingly cool. I will see if I can merge your code with the main repo in a meaningful way, so that you don't have to reapply the patches every time. Also, I found a few bugs here and there, and it would be nice if the fixes specific to wasm and the main branch were kept in sync easily.

That being said, I don't recommend this approach for mobile devices, since it's bound to consume a lot more resources, which are a bit scarce. So while I fully intend to leverage your work for example to integrate in the web site, I think that we need to have native versions for mobile phones.

For iOS, I have a native version that is working on both iPhone and iPad. I need to spend the time to go through the hoops to get it published on the Apple Store. This is one of the reasons why there is colour support in the simulator ;-)

Thanks Christophe — I'm glad you like it! Also happy to hear that you have native apps in the works — this will be much better for performance, and will make it easier to save and manage state when the app closes, etc.

Also, I found an interesting bug while developing this. Evaluate '65!/8888' and the calculator only displays the fractional part which is '58/101'. "SHOW" also only displays the fractional part. The integer part is still there — you can divide by 65 to see it. I believe this is a display issue caused by large numbers with many digits.

[c3d]

(05-21-2024 02:04 AM)sunpazed Wrote:  Also, I found an interesting bug while developing this. Evaluate '65!/8888' and the calculator only displays the fractional part which is '58/101'. "SHOW" also only displays the fractional part. The integer part is still there — you can divide by 65 to see it. I believe this is a display issue caused by large numbers with many digits.

Thanks the bug report. Tracked as issue 945. The fix will be in the next release.

[mahi]

First of all I'd like to express my thanks to Christophe for developing DB48X/DB50X! I had given up hope on a new physical RPL calculator, but this project looks very promising.

I discovered a few quirks I did not see in the github issues (I might not have looked very well). I'm using version 0.7.6.

In the syntax below [xx] indicates a button or soft key.

1 2 / [+/-] has a visualization bug: There are 2 minus signs in the fraction

2 [+/-] [+/-] gives 2, but '2' [+/-] [+/-] gives -(-2). Repeatedly pressing [+/-] just adds additional negation symbols instead of inverting the previous. Same issue happens with [1/x]. In fact, it also happens when alternating between square root and power of 2, log and 10^x, asin and sin,...

When you put a symbolic constant on the stack, like π, and press the [E] button (EEX), you get "cycle error: bad argument type". I understand that DB48X does not have an alternative representation for these, but it should not give an error. Pressing [E] on a variable name works fine (toggles between 'variable' and variable).

I like the idea of the [E] button cycling between visualizations and units, but it's not always consistent. For example 2_in [E] gives 50 4/5 mm and 5 2/25 cm, while in this case decimal notation would be preferred. A direct conversion to mm with [→mm] gives the same effect. So, I need an extra [→Num] operation to get the decimal value, whereas when I enter 50 4 5 / + [E], it shows me 50.8 immediately. I can work around this by entering 2._in, but it's bit strange in my opinion. Maybe I shouldn't be using the calculator in symbolic mode?

By the way, owners of an existing overlay may not like it, but I really think [→Num] should be accessible directly from the keyboard (update: already a github issue)

Entering 1000000_mm and then repeatedly pressing [E] alternates between 1000000 mm, 100000 cm and 39370 10/127 in. However, entering 1_km (which is exactly the same) reacts completely different to the [E] button: 1 km, 1/1000 Mm, 1/1000000 Gm, 0.000001 Gm, 0.001 Mm, 1.km, 10. hm, 100. dam, 1000. m, 10000. dm, 100000. cm, 39370.07874...in, 1000000. mm (from here pressing [E] keeps alternating between the last 3).

Entering 0.005_A and then repeatedly pressing [E] cycles between 0.005 A, 0.05 dA, 0.5 cA, 5. mA, 5000. µA, 5000000. nA, 5000000 nA, 5000 µA, 5 mA, 1/2 cA, 1/20 dA, 1/200 A, 1/2000 daA, 1/20000 hA, 1/200000 kA, 1/200000000 MA, 0.000000005 MA, 0.000005 kA, 0.00005 hA and 0.0005 daA. That's an awful lot of notations, and prefixes like centi, deci, deka and hecto are not that common with many (most?) units.

I'm not really sure what the best solution is for this, but maybe a toggle can be added to show only engineering prefixes?

When you have an expression on level 1 of the stack, pressing [E] also changes the rendering of expressions at deeper stack levels. I think I understand why it does that, but it's weird because if a non-expression is in level 1 you can't change the rendering of expressions on deeper levels.

Create a list 1 2 3 3 [→List]. Executing 4 [Get] gives index out of range (as expected), but 4 4 [Put] gives an out of memory exception. I don't think it's supposed to do that.

Maybe I looked over it, but one feature I miss when it comes to stack manipulation is the Up arrow behavior of the HP 48/50 series. Pressing Up on the HP 48/50 allows you to quickly pick or echo an item at a deeper stack level. I know you can do <num> [Pick], but sometimes you want an older item that is no longer in the viewable area of the stack. Similarly, the Up arrow lets you quickly create a list (like <num> [→List]).

[mahi]

I discovered a bug with the solver. It doesn't work when certain constants are in the equation.

For example 'E=m*c²' returns error "bad guess" when solving E or m. When substituting constant c for π (pi) or e, it does work.

Update: And another issue (maybe). Set 'E=m*c²' for the solver with [>Eq] soft key, then recall with the [Eq>] soft key. The equation changed to 'E-m*c²'. While mathematically correct, that's not the equation I saved. Or is this intentional?

I had another weird issue but I cannot reproduce it. I had several equations on the stack containing constants and was playing with the solver. At one moment I noticed that equations deeper in the stack no longer showed the constant name but it was substituted with "Chem".

[c3d]

(05-27-2024 08:37 PM)mahi Wrote:  First of all I'd like to express my thanks to Christophe for developing DB48X/DB50X! I had given up hope on a new physical RPL calculator, but this project looks very promising.

I discovered a few quirks I did not see in the github issues (I might not have looked very well). I'm using version 0.7.6.

In the syntax below [xx] indicates a button or soft key.

I appreciate the feedback, but it would make my life easier if you filed issues on GitHub instead of reporting here. I will file what you described here. Let me just address one thing I will not file because it's intentional.

Quote:I like the idea of the [E] button cycling between visualizations and units, but it's not always consistent. For example 2_in [E] gives 50 4/5 mm and 5 2/25 cm, while in this case decimal notation would be preferred. A direct conversion to mm with [→mm] gives the same effect. So, I need an extra [→Num] operation to get the decimal value, whereas when I enter 50 4 5 / + [E], it shows me 50.8 immediately. I can work around this by entering 2._in, but it's bit strange in my opinion. Maybe I shouldn't be using the calculator in symbolic mode?

This is intentional. This is intended to demonstrate customizable cycles, and I used for that demonstration a scenario that @spiff72 uses often, the conversion between mm and inches.

There are two cycles configured in the units.csv file:

"=Cycle"
"in", "mm"
"mm", "cm"
"cm", "in"
"USD", "EUR"
"EUR", "CHF"
"CHF", "USD"

So when you enter one of in, mm or cm unit, then the cycle takes priority over the normal behaviour. Same if you enter USD, EUR or CHF.

Quote:By the way, owners of an existing overlay may not like it, but I really think [→Num] should be accessible directly from the keyboard (update: already a github issue)

Yes, it's done now, it's on the "ASN" (which I remember as "As Number").

Quote:Entering 1000000_mm and then repeatedly pressing [E] alternates between 1000000 mm, 100000 cm and 39370 10/127 in. However, entering 1_km (which is exactly the same) reacts completely different to the [E] button: 1 km, 1/1000 Mm, 1/1000000 Gm, 0.000001 Gm, 0.001 Mm, 1.km, 10. hm, 100. dam, 1000. m, 10000. dm, 100000. cm, 39370.07874...in, 1000000. mm (from here pressing [E] keeps alternating between the last 3).

See explanation above. A configured cycle in the units file takes precedence.

Quote:Entering 0.005_A and then repeatedly pressing [E] cycles between 0.005 A, 0.05 dA, 0.5 cA, 5. mA, 5000. µA, 5000000. nA, 5000000 nA, 5000 µA, 5 mA, 1/2 cA, 1/20 dA, 1/200 A, 1/2000 daA, 1/20000 hA, 1/200000 kA, 1/200000000 MA, 0.000000005 MA, 0.000005 kA, 0.00005 hA and 0.0005 daA. That's an awful lot of notations, and prefixes like centi, deci, deka and hecto are not that common with many (most?) units.

The problem is that there are very common cases, e.g. cm, whereas almost nobody uses the cs or the cA. Teaching that to a calculator is a bit complicated.

Quote:I'm not really sure what the best solution is for this, but maybe a toggle can be added to show only engineering prefixes?

The solution has to allow cm to work. It's an extremely common unit outside of the US.

Quote:When you have an expression on level 1 of the stack, pressing [E] also changes the rendering of expressions at deeper stack levels. I think I understand why it does that, but it's weird because if a non-expression is in level 1 you can't change the rendering of expressions on deeper levels.

It toggles between the four possible graphical rendering states (result and other levels). Every cycle toggles graphical rendering for the result level. Every second cycle toggles graphical rendering for the rest of the stack. That is intentional, e.g. to reduce the space used for fractions.

[c3d]

(05-28-2024 11:52 AM)mahi Wrote:  I discovered a bug with the solver. It doesn't work when certain constants are in the equation.

The solver with equation is still being actively worked on, and support is still very incomplete. This was mentioned in the release notes IIRC. Support for units is deficient, support for constants is not there, and more.

Quote:For example 'E=m*c²' returns error "bad guess" when solving E or m. When substituting constant c for π (pi) or e, it does work.

That's because c has a unit. It's the support for units in the solver that is the most deficient part at the moment (and the primary focus for the next release). That specific issue was #947.

Quote:Update: And another issue (maybe). Set 'E=m*c²' for the solver with [>Eq] soft key, then recall with the [Eq>] soft key. The equation changed to 'E-m*c²'. While mathematically correct, that's not the equation I saved. Or is this intentional?

Fixed as part of #944.

Quote:I had another weird issue but I cannot reproduce it. I had several equations on the stack containing constants and was playing with the solver. At one moment I noticed that equations deeper in the stack no longer showed the constant name but it was substituted with "Chem".

I suspect this is related to another issue where I was opening the units and constant files at the same time. See, the DM32/DM42 firmware lets you open only one file at a time, so processing equations that contains constants with units has to be careful about that (3 files involved).

[c3d]

DB48X pre-release v0.7.7 is out.

This release keeps marching towards full support for an equation library. The primary focus was support for units in equations.

New features

solver: Accept equations in solver menu
solver: Add shortcut to solve an equation from the library
solver: Display the current equation above the stack
solver: Solve expressions containing units
solver: Add units for solver variables when entering them
equations: Add option to list variables with units
programs: Enforce numerical values for solver / plotter
constants: Implement programmatic lookup
fonts: Add support for fixed-width digits
keyboard: Interpret ASN as AsNumber (convert to decimal)
complex: Allow insertion of angle while entering phasors
complex: Implement auto-complex promotion
graph: Render abs(X) with bars (e.g. |X|)
functions: Automatic simplification of expressions
Bug fixes

arithmetic: Avoid null-dereference in complex operations
help: Close help file if topic not found
solver: Do not store tag for tagged values
graph: Gracefully fallback if fraction integral part does not render
units: Avoid null-dereference if unit simplification fails
units: Count parentheses while parsing units
put: Fix null-dereference checking the index
fractions: Do not render two negative signs in graphical mode
Improvements

cycle: Update behaviour for several data types
menu: Replace abs with |z| in complex menu
ui: Micro-optimization to avoid reading object type twice
parser: Accelerate and improve object parsing
recorder: Add recorder entries for evaluation
build: Remove any leftover references to Intel decimal library
tests: Add ▶ entry in tests
tests: Increase default wait time to 1000ms
tests: do not error out if teval takes less than 100ms
equations: Rename PerfectGas equation to IdealGas
menus: Adjust size of menus to make descenders visible
solver: Replace SolverPrecision with SolverImprecision

[spiff72]

I just updated this morning and found what I think is a significant bug.

I can't enter a decimal value that's less than zero on the stack without using a leading 0 before the decimal point. I get a syntax error if I enter .375 ENTER , but 0.375 ENTER works.

[mahi]

I can confirm the leading zero issue reported by spiff72 (#965)

I think all of the issues I reported in this topic have been fixed apart from:

(05-29-2024 08:31 AM)c3d Wrote:  

(05-28-2024 11:52 AM)mahi Wrote:  For example 'E=m*c²' returns error "bad guess" when solving E or m. When substituting constant c for π (pi) or e, it does work.

That's because c has a unit. It's the support for units in the solver that is the most deficient part at the moment (and the primary focus for the next release). That specific issue was #947.

This issue is supposedly fixed in 0.7.7, but I still get a "bad guess" error (or nothing) when trying to solve the mass-energy relation.

'E=m*c²' [>Eq] [Solve]
2 [>m] (I also tried with 2_kg)
[E?] gives either nothing or "bad guess"

[c3d]

(06-03-2024 06:29 PM)mahi Wrote:  This issue is supposedly fixed in 0.7.7, but I still get a "bad guess" error (or nothing) when trying to solve the mass-energy relation.

The support for constants with units was not complete. What was supposed fixed in the previous release was just units in variables.

This should be fixed in v0.7.8 (at least, works for me).

[c3d]

Pre-release v0.7.8 is out.

This release keeps marching towards full support for an equation library.
The primary focus was support for constants in equations, including constants with units like the speed of light, as well as fixing various user-reported issues.

Please give it a try.

[bdb]

I've discovered this project last week. I've read the whole thread. I've watched some videos. This is amazing! Exactly what I like to use.
A few questions (apologies if I missed some answers given before):
- am I understanding correctly that the code for interfacing to the DM32 or DM42 (let's call this hardware abstraction layer) is decoupled from the calculator "application" itself?
- if so, is it possible to modify DB48X to run as an REPL (read eval print loop) in a terminal?
- would it make sense to port the work of B. Parisse (Erable/XCAS) on DB48X?
- how much faster would an HP Prime G1 or an HP50g be? I don't know the microarchitectural/instruction per cyle differences between the ARM processors of the HPs and the Cortex M33F/M4 of the DM32/42.
- finally, what would be the ideal keyboard for a purpose-built calculator? (An Android version could help try with different scenarios).

[c3d]

(06-19-2024 07:46 PM)bdb Wrote:  I've discovered this project last week. I've read the whole thread. I've watched some videos. This is amazing! Exactly what I like to use.

Thanks. You are the reason for this project to exist.

Quote:A few questions (apologies if I missed some answers given before):
- am I understanding correctly that the code for interfacing to the DM32 or DM42 (let's call this hardware abstraction layer) is decoupled from the calculator "application" itself?

To some extent. There are several layers:
- The application itself
- Some abstraction code I put in place to help with the simulator
- The DMCP platform provided by SwissMicros, which I reimplemented in part for the simulator
- The underlying hardware operating system, which as far as I know is different for the DM32 and DM42. This is essentially hidden behind DMCP, and I believe it's different for the DM32 and DM42.

Quote:- if so, is it possible to modify DB48X to run as an REPL (read eval print loop) in a terminal?

No real effort was put to facilitate that. At the moment it would be a little more difficult than it should, because the goal is to make the application as streamlined and small as possible given the DM42 memory constraints. But in theory, sure.

Quote:- would it make sense to port the work of B. Parisse (Erable/XCAS) on DB48X?

Not for the DM42 or DM32. I discussed that with Bernard Parisse directly, and the baseline for his work is about 2M. DB48X must run in 700K. I'm essentially reimplementing a CAS all by myself. There is another reason for that too: it's interesting and fun to do.

Quote:- how much faster would an HP Prime G1 or an HP50g be? I don't know the microarchitectural/instruction per cyle differences between the ARM processors of the HPs and the Cortex M33F/M4 of the DM32/42.

It would be significantly faster. The HP50G can be overclocked, and the Prime is naturally much faster. I don't have actual results on these platforms, but I did some measurements of the simulator on iPhone 12, and there, the iPhone is more than 150 times faster.

Quote:- finally, what would be the ideal keyboard for a purpose-built calculator? (An Android version could help try with different scenarios).

It depends on what you call "ideal". SwissMicros, for example, is in the business of "almost identical to the original". In that case, the ideal layout would be that of an HP48 or HP50 depending on which model you want to emulate. SwissMicros actually told me that they would have preferred if I had asked them for an extra row of keys before starting the project. If/when they do a model with an extra row of keys, we'll use these keys, it won't be hard.

DB48X is not at all in this "replica" philosophy, though. The goal is to make the most of an exciting existing hardware platform. I see it as being more "in the spirit of HP", rather than "similar to HP". HP was known to be innovative and care a lot about what you could do with their calculators.

Also, I am trying to preserve muscle memory for DM42 users. This is because I expect people who use DB48X to be familiar with the DM42. I could not do the same for the DM32 keyboard layout, which is just too incompatible with an RPL machine.

[c3d]

Hi Franco,

(05-20-2024 05:03 AM)sunpazed Wrote:  Hi Christophe — you might be interested in this little side project of mine. As a proof-of-concept, I built a version of your simulator that runs in the web-broswer (and therefore on mobile devices). I found that Qt runs fairly sluggishly after some time, so that was part of my motivation. It's also quite nice to use db48x in the palm of your hand (as I don't yet have a dm42!).

Here's what it looks like on my iPhone;


Try it in your browser here — the simulator can be run fullscreen by selecting "Add to Home Screen" on iOS or your Android device;
https://sunpazed.github.io/db48x-wasm/bin/index.html

Be warned that there are many bugs, with the simulator hanging when accessing system services (help, save state, system menu) which are not implemented .

And finally here's the repo for review; https://github.com/sunpazed/db48x-wasm — apologies in advance for butchering your excellent code.

Your idea and a lot of your code (notably the index.html and emcc.h files) were integrated in the main repository. I could not merge your code directly because you started with an initial commit that had a different structure. To test it, just use "make wasm", and this should be all you need.

I hope you won't mind if I added you to the list of authors. I tagged the first WASM commit with "Co-authored-by" to give you some credit.

Then, I did another iteration where I used the pthread emulation in emscripten.

The upside is that it fixes most of the issues you reported in your proof of concept, e.g. the system menus not working.

The downside is that it requires the web server to enable HTML COOP and COEP, otherwise the necessary WASM features are disabled by the browser. This is semi-trivial to do, and a simple Python web server doing that is included in that commit, but it't worth keeping in mind.

Another aspect that I'm looking into is that the JavaScript event loop is a bit busy, since it calls window.requestAnimationFrame. You had some code that rate-limited the fetching of the LCD buffer. I replaced that with a mixed use of window.setTimeout to fetch keyboard / LCD status, and only calling window.requestAnimationFrame when the screen actually changed. This improves things a little bit, but I still see my desktop browsers pegged at high CPU (tested with Safari and Brave).

My concern here is that this makes it a "dangerous" solution for mobile phones, where this application is likely to train the battery at high speed. I'm likely to throttle the refresh rate on the JavaScript side in a way similar to what happens on the RPL side, i.e. decrease the polling frequency over time.

In any case, if you have time to review and comment, I'd appreciate it. And obviously, if you want to keep improving this aspect of the work, we can do that on the main DB48X repo (unless of course you have reasons to want to keep your own fork).

[jeanwilson]

Here are some questions about state saving and calculator precision (db50x v0.7.8).

Is there a simple RPL function or program that would output the actual precision which is actually set in the display menu? I am currently working on developing a pseudo-random generator (PRNG based on linear multiplicative congruence algorithms) for the db48x-db50x RPL environment that can both run as quickly as possible while still taking advantage of adjustable calculation precision in order to maximize the repetition period. For the purposes of statistical tests, I am constructing the cumulative distribution function from samples. Such precision output would be useful because the parameters of the PRNG algorithm will explicitly depend on the number of digits chosen in the Display menu of the calculator.

Concerning, the state saving function, I observed that I am not able to save the calculator state under a new name (useful if a want to communicate the precise configuration of a given problem). Doing Setup>State>Save state, leads to <New Files>; I then correctly enter a new Filename, but the calculator then prompts with - [R/S] to Confirm. And there I am stuck because the [R/S] key is inaccessible since the DM32 key template is gone. I tried any key (including [=]) with no success. One indirect way to circumvent this is to create copies of given states in the computer and upload them afterwards into the calculator. And then save my new states under these pre-existing named ones.

Thanks for your help.

[c3d]

(06-27-2024 04:06 AM)jeanwilson Wrote:  Here are some questions about state saving and calculator precision (db50x v0.7.8).

Is there a simple RPL function or program that would output the actual precision which is actually set in the display menu?

Yes, you can use

'Precision' RCL

(This works for any setting; STO will update the setting, and PURGE will reset it to default)

Quote: I am currently working on developing a pseudo-random generator (PRNG based on linear multiplicative congruence algorithms) for the db48x-db50x RPL environment that can both run as quickly as possible while still taking advantage of adjustable calculation precision in order to maximize the repetition period. For the purposes of statistical tests, I am constructing the cumulative distribution function from samples. Such precision output would be useful because the parameters of the PRNG algorithm will explicitly depend on the number of digits chosen in the Display menu of the calculator.

I'm very interested in how you implement that, since this should be a built-in function, and it's one I did not think about yet, so having someone working on the algorithm will definitely help.

Quote:Concerning, the state saving function, I observed that I am not able to save the calculator state under a new name (useful if a want to communicate the precise configuration of a given problem). Doing Setup>State>Save state, leads to <New Files>; I then correctly enter a new Filename, but the calculator then prompts with - [R/S] to Confirm. And there I am stuck because the [R/S] key is inaccessible since the DM32 key template is gone. I tried any key (including [=]) with no success. One indirect way to circumvent this is to create copies of given states in the computer and upload them afterwards into the calculator. And then save my new states under these pre-existing named ones.

Thanks for your help.

Weird. This is indeed a bug, and indeed, the = key is the one you should use. But I can confirm it does not work, whether on DM42 or DM32. This is a regression, I'm pretty sure it used to work. I filed an issue.

Thanks for reporting!