New firmware for the Swissmicros DM15L

[jebedeo]

Hello Everyone,

it's been a long time but I have been making progress. Here is another beta of my new firmware, with way more features.

Key facts:

| -------------------------- | --- HP15C --- | --- LF15C ---- |
| -------------------------- | ------------- | -------------- |
| Internal Data ------------ | BCD --------- | double complex |
| Precision Digits --------- | 10 ---------- | ~ 17 [1] ----- |
| Programming mode --------- | op codes ---- | human readable |
| Stack Size --------------- | 4 ----------- | 4+ ----------- |
| Register Size ------------ | 21 ---------- | 100 ---------- |
| Program Memory ----------- | up to 672 --- | 2000 --------- |
| Program Labels ----------- | 25 ---------- | 100 ---------- |

[1] Following https://math.stackexchange.com/questions...calculator



Current implemented features:

| --------------------- | HP15C | LF15C |
| --------------------- | ----- | ----- |
| Complex numbers ----- | - x - | - x - |
| Programmability ----- | - x - | - x - |
| Statistical Functions | - x - | - x - |
| Integrate ----------- | - x - | ----- |
| Solve --------------- | - x - | ----- |
| Matrix -------------- | - x - | ----- |



I am tidying things up and will create a github repo for this at some point, but for right now give it a try and let me know if you like it!

[Helix]

I’ve successfully installed this firmware on my credit card size DM-15. I like a lot this idea!
It’s not only more precise, but also faster than the SwissMicros Firmware.

A few remarks though:

- What is the meaning of "ser" at the right of the display?

- The font is nice, except for the 3, because if lighting conditions are not optimal it can easily be confused with an 8. I know this is the font chosen by HP, but it’s an unfortunate decision in my opinion.
Casio, Sharp and TI have a very different 3, to avoid this confusion:
http://www.thimet.de/CalcCollection/Calc...602P-M.JPG
http://www.thimet.de/CalcCollection/Calc...500A-M.JPG
https://upload.wikimedia.org/wikipedia/c..._TI-74.jpg

For my HP 50g, I modified the 3 by removing one pixel in the central bar, and this makes a clear difference:


- Some important functions are missing, like f PREFIX or g MEM, but I suppose they are not yet implemented.

- There is a bug with arctan(1)

[jebedeo]

Hi Helix,

Thanks for the feedback! Great to know that it works also on the pocket version of the calculator, I wasn't sure if the hardware was exactly the same besides the form factor.

"ser" indicates that the serial port is open, you can toggle it by long-pressing STO. I usually keep it enabled since I'm always debugging, but I fixed it and it's off by default now. From the serial port you can "inject" keypresses, but it's just for testing right now and it will probably go away at some point.

I fixed the font for the 3, great suggestion!

arctan(1) returning a NaN + i INF is a bit puzzling to me. Internally, I am using catan() from the C math library. The same code compiled and executed on my desktop machine does not have the bug that you found, so I need to do some more digging, thanks!

That's right, f PREFIX or g MEM are not yet implemented. Also, some of the way the calculator handles memory and registers is different from the 15C, half way between that and the HP42s. I am still working on a bunch of stuff so things are changing but hopefully I will have time to solidify and document things soon.

[Helix]

Thank you !
Now there is another bug: the annunciators f and g appear only with the following keystroke, which is of course disturbing.

[Johnp_g]

Thanks for the interesting new firmware!

I like the view of X and Y, and the complex number handling too!

I'm just getting used to using it and find the F and G shifts operation a little confusing, the annunciators appearing only after the shifted function itself is pressed, and not clearing until ENTER is pressed (even when it isn't really needed).

For the programming its nice at last to have readable instructions instead of Keycodes, but I think I found a bug,

I wanted to test with a simple formula

"multiply X by 8 and add 306 to the result"

The program

Code:

LBL A
8
x
3
0
6
+
RTN

but it appears the "0" isn't interpreted (is ignored).

For X = 25

the prog gives 236 which is 25 x 8 plus 36

Changing the prog to

Code:

LBL A
8
X
3
1
6
+
RTN

I get (for X = 25) an answer of 516 which is correct (for adding 316)

It looks like ZERO is ignored!

For Storage registers I note that you need to terminate a STO or RCL with ENTER, is this intended? It isn't intuitive, but you could get used to it in time.

I look forward to more testing!

Thanks again,

John

[jebedeo]

Thanks for pointing out those bugs!

They should be fixed now. I found the root cause of the arctan(1) bug and it comes from using an old version of the c library for arm MCUs, newlib. It's not fixed yet but I have a path for it.

The 0 was indeed being ignored during a program, nice catch!

John, STO and RCL need to be terminated with ENTER on purpose. It's a behavior from the hp42, and the reason is that we have 99 registers so more than one digit is needed. Also, if you make a mistake while picking the register, you can just press the <- button.

[Johnp_g]

(09-16-2024 03:19 PM)jebedeo Wrote:  The 0 was indeed being ignored during a program, nice catch!

John, STO and RCL need to be terminated with ENTER on purpose. It's a behavior from the hp42, and the reason is that we have 99 registers so more than one digit is needed. Also, if you make a mistake while picking the register, you can just press the <- button.

Thanks for the quick update!

I haven't had a chance to try this version yet, but I'm amazed at how quickly you've fixed the first bugs.

Regarding the STO/RCL behaviour - I don't have a genuine HP42 but my DM42, and Free42 itself, don't require ENTER for two digit registers, they terminate after the second digit. The ENTER can be used to terminate a single digit register number (rather than explicitly typing a leading ZERO).

The DM41X (and therefore I presume the HP41CX etc) need both digits (and no ENTER).

I agree that your method allows for correction of a mis-typed second digit for the register address and that might be quite a valuable feature, but it's going to take practice to remember to press ENTER each time when you're used to "STO nn" (even when the first n = zero)

It might be worth the new muscle memory, for the other benefits, of course! :-)

I'm going to try this version later today, when I get back home. I'm particularly glad about the Complex number handling/display. I'll try some programming with complex numbers later, should be fun!

Cheers,

John

[Johnp_g]

jebedeo,

This is great!

Aside from the STO/RCL issue - which is a personal choice and I have no problem with whatever method you choose.

I'm really enjoying the Complex number handling!

I just discovered that with a complex number on the stack that:

f (i) -> complex conjugate
f I -> splits the complex number out to Re and Im on y and x stack
f Re<>Im swaps the Real and Imaginary parts of the complex number

I note that in complex number mode that ->R and ->P operate as a way of :

1) changing a complex number already on the stack between Rect. and Polar
2) alter how a new complex number is presented, eg. after pressing g ->P it follows that all new complex numbers are created as Polar (and vice versa).

This is very fine!

However I found that for "normal" real numbers in x and y that ->P and ->R don't function as in the HP15C - no conversion from x & y to Arg / Angle takes place.

But confusingly. after trying a conversion to Polar with g ->P (which silently fails to do anything) still means that any new complex numbers be created in Polar format.

Perhaps a new annunciator could be added to indicate R or P to make it obvious which mode new complex numbers will appear as?

A second "bug" is with the ->H.MS and ->HR functionality.

Firstly H.MS and HR only operate after ENTER has added the number to the stack - which duplicates it into Y and raises the stack - not what you necessarily want.

Secondly the conversions don't calculate correctly

1.3030 (1 hour, 30 minutes, 30 seconds) g -> HR gives 1.50833 which is correct
1.50833 (1.50833 hours) f ->H.MS gives 1.3050 (1 hour 30 minutes 50 seconds) which is incorrect

Looks like the handling of the seconds is wrong - and we have "50" (for 0.5 minutes?) where there should be 30 for 30 seconds.

Various other test numbers produce similar effects.

Otherwise I'm very impressed and very happy to use this new firmware!

Well done!

John

[jebedeo]

John,

Thanks for the encouragement, I'm glad you like it!

I fixed the bug of ->H not using the buffer and requiring data on the stack, and I also fixed the bug you found in ->H.MS, thanks for finding those

Also, the arctan(1) bug is now fixed!

I added an annunciator for the polar mode, P, thanks for the suggestion.

As far as the rectangular/angular conversion for real number, I'm not sure what's the best way to handle it. Since the calculator is always in complex mode (the display doesn't show the imaginary part if it's 0, but the stack is always complex) I made the P and R button just a way to select the display mode, akin to FIX or SCI.
The idea is that the user can do that conversion if they need to, by using the complex number. I could implement some sort of R/P conversion for real numbers which checks that X and Y on the stack are real before converting, but as I am already at 97% of flash memory usage I gotta save every byte I can. I am of course open to suggestions!

Thanks again,
-jebe

PS. I am from now on going to upload the latest firmware to the top of the thread only, so it doesn't get too confusing.

[Helix]

Thank you for the update.
I agree that the behavior of the STO / RCL functions is not very intuitive. I would prefer a STO nm and a STO 0n format, without the need of ENTER. On the other hand, it’s not a big deal. Since flash memory is limited, the best solution is certainly the one that requires the least memory.

The g TEST function in program mode is brilliant! It’s especially useful for me, as there is no reminder on the back of the small DM-15 calculator.
The only very minor drawback on this version is that the two arrows are misplaced: the left arrow is between the 7 and the 8, and the right arrow is above the 9. I didn’t understand at first why they didn’t work
Perhaps a solution could be to enable the 9 key to behave like the CHS key, so that the firmware would be suited to both calculator formats. Again, it’s not mandatory.

Another very minor quirk: in program mode, the annunciators appear on both lines.
EDIT: this occurs when the label program has 2 digits. For example:
f LBL 10
g x²

[Johnp_g]

Now I understand the R/P issue a little better I think it's best to leave it alone unless you have a major lightbulb moment!

I tried a version of the SAVAGE benchmark which uses DSE and loop control register to control the number of loops performed and I found i impossible to fathom out how the I register and DSE (or ISG) work. Storing a number in I seems to put that number in Reg 25 and using DSE (or ISG) doesn't touch the number in Reg 25 and seems to do nothing at all. Have Indirect register behaviour and loop control value functions significantly changed, or are they not implemented (yet?)

There also seems to be an issue with starting/stopping a running prog. with R/S, but I'm still testing to make sure I understand the symptoms before describing it.

I'll go now and flash your last version, it's a privilege to be allowed to test this new firmware.

(EDIT, later after flashing the newest version, with more observations of STO(i)/RCL(i))
The latest version (with the Polar annunciator) crashes - locks solid needing the RESET button press - if you try to STO (i) or RCL (i). The previous version actually allowed STO and RCL to (i) but the (i) wasn't a register pointed to by "I" as I expected, and I don't know what the relationship between I and (i) were. Now STO(i) and RCL(i) simply lock up the calculator instead.

I assume from your comments about flash usage that Matrix and Integrate/Solve may not make it? TBH that's no great problem to me, as 99% of my use is with the functionality you've got working now, and especially the wonderful complex mode!

Cheers,

John

[Johnp_g]

(09-17-2024 06:25 AM)Johnp_g Wrote:  There also seems to be an issue with starting/stopping a running prog. with R/S, but I'm still testing to make sure I understand the symptoms before describing it.

I tried the HP Museum benchmark https://www.hpmuseum.org/speed.htm

This entails running the program for 60 seconds, then using R/S and inspecting a storage register for the number of completed loops in the 60 seconds.

I found occasionally that the calculator would turn off when pressing R/S, and now after many tests it seems that running the program for 60 seconds is fine, R/S stops the execution. However running for 61 seconds or more leads to the R/S button both stopping execution AND turning the calculator OFF.

Turning back on and all is normal.

Sometimes I also see that R/S has no effect until pressed a second time, but I can't find a pattern.

I do find that using this benchmark your firmware is somewhat faster than the stock DM15L firmware!

Stock V32_m1b firmware at 48MHz : 676 loops complete
LF15C_beta240916 firmware : 1346 loops complete

https://www.gm4slv.org.uk/dokuwiki/doku....nchmarking

Thanks again,

John

[Johnp_g]

(09-16-2024 09:25 PM)jebedeo Wrote:  I fixed the bug of ->H not using the buffer and requiring data on the stack, and I also fixed the bug you found in ->H.MS, thanks for finding those

Nice, although I still see some errors (rounding issue?)

1.0030 (1 hour, zero minutes, 30 seconds)

->H

1.0083333333

->H.MS

1.002900

We've lost a second in the reverse conversion

continuing....

->H

1.008055556

->H.MS

1.002800

and another...

But oddly starting with zero hours, zero minutes and 30 seconds:

0.0030

->H

0.0083333333

->H.MS

0.003000

we don't lose the second this time!

John

[Helix]

3 1/x →H gives 0.5591666666666… instead of 0.559259259

7 1/x →H.MS gives 0.0834 instead of 0.083428571

[jebedeo]

Hi guys,

thanks for the feedback!

the I and (i) registers are not implemented yet, that's the next task on my list in terms of functionality, sorry about the confusion. There is some hooks in place, namely to enter them from the keyboard, but nothing else. I am planning on implementing them just like in the HP15C, besides some minor differences since we have more registers. From reading the HP15C manual it seems cumbersome to me since the value in register I is split between integer part and fractional part to do different things. If a longtime user of HP calculator has suggestions for a better interface don't hesitate to write it!

Ugh, I'm clearly doing something slightly off in that ->H and ->HMS algorithm, thank you for pointing out the bugs, I'll take another look at it.

The R/S should work fine, but I'm guessing it's interacting in a weird way with the auto shut-off feature. The calculator turns off after 60 seconds of no keypresses, and in theory running a program halts the timer, but there must be a bug and that's what you are seeing with running that program for 60 vs 61 seconds.

DSE/ISG are also not implemented yet.


In terms of what can be added from now on, the next goal is to finish the programmability side of things, namely inderect addressing and DSE/ISG. That might take me a while since it touches so many functions, but I'll keep you posted.

I fixed the bug of the double annunciator in program mode, thanks for pointing it out! I won't upload a new firmware for it since it's minor and I am doing some major surgery on it.

I am hoping that after the program mode is fully done I will have enough room to implement integrate/solve. At the end of the day, they are a program running and computing things, so I should be able to reuse a lot of the functionality that the program mode provides. I don't think that matrix support is going to make it. There is enough RAM left to do things, but writing the interface for the matrix might require too much flash. We'll see...

[Helix]

(09-18-2024 09:37 PM)jebedeo Wrote:  Ugh, I'm clearly doing something slightly off in that ->H and ->HMS algorithm, thank you for pointing out the bugs, I'll take another look at it.

I know that these functions are more difficult to program than they seem. Be prepared to cope with other bugs!

Quote:The R/S should work fine, but I'm guessing it's interacting in a weird way with the auto shut-off feature. The calculator turns off after 60 seconds of no keypresses, and in theory running a program halts the timer, but there must be a bug and that's what you are seeing with running that program for 60 vs 61 seconds.

Strangely, my calculator doesn’t turn off after 60 seconds. Even after 10 minutes it is still on. This was not the case with the previous firmware. (I must admit than 60 second is too short for me).

Quote:I am hoping that after the program mode is fully done I will have enough room to implement integrate/solve. At the end of the day, they are a program running and computing things, so I should be able to reuse a lot of the functionality that the program mode provides. I don't think that matrix support is going to make it. There is enough RAM left to do things, but writing the interface for the matrix might require too much flash. We'll see...

Even without matrix functions, this firmware will stay definitively on my DM-15. For matrix calculations I have better tools than a HP 15C.
In the worst case, integrate and solve can be left as user programs.

[Johnp_g]

(09-18-2024 10:54 PM)Helix Wrote:  Strangely, my calculator doesn’t turn off after 60 seconds. Even after 10 minutes it is still on. This was not the case with the previous firmware. (I must admit than 60 second is too short for me).

No, mine doesn't auto-turn off either.

And I agree that 60 seconds would be too short, and would become annoying very quickly

(09-18-2024 10:54 PM)Helix Wrote:  Even without matrix functions, this firmware will stay definitively on my DM-15. For matrix calculations I have better tools than a HP 15C.
In the worst case, integrate and solve can be left as user programs.

If the current bugs could be worked out, and indirect register/ISG/DSE implemented I'd be happy to keep this firmware for the DM15L. Solve and integrate would be nice to have, of course!

BTW is there an easy way of skipping to the end of program memory to add a new label/program. The HP15C uses "f (Clear Prog)" while in RUN mode to jump to the start of memory and new Label/Prog is entered "On top" of existing one(s) which are pushed downwards as new lines are added above. LF15C uses "f(Clear Prog)" in both Run and Prog mode to clear a specified program label. Moving to the start of memory seems not to be correct, as adding a new LBL there puts it BELOW the existing one, rather than above it. I find I'm using SST to scroll down to the end of existing progs to enter new ones. I may be missing something.

Thanks again.

John

[Johnp_g]

FRAC bug

I thought I'd work through the HP15C Owners manual as a quick way of testing out each function.

Section 2, page 25 shows the use of INT and FRAC and I found a bug with using FRAC on a negative number.

from the example

123.4567 gINT -> 123.00000 (correct)
g LSTx CHS gINT -> -123.000 (correct)

gLSTx (recalls x: -123.4567) fFRAC -> 0.5433 (incorrect) - should be -0.4567

fFRAC works on positive values of X but is wrong for negative values of X.

--

John

[dm319]

I have just seen this. It comes close to my dream calculator. I'm thinking of getting a DM-15L now!

How do you program it?

[Helix]

(09-19-2024 06:16 AM)Johnp_g Wrote:  BTW is there an easy way of skipping to the end of program memory to add a new label/program. The HP15C uses "f (Clear Prog)" while in RUN mode to jump to the start of memory and new Label/Prog is entered "On top" of existing one(s) which are pushed downwards as new lines are added above. LF15C uses "f(Clear Prog)" in both Run and Prog mode to clear a specified program label. Moving to the start of memory seems not to be correct, as adding a new LBL there puts it BELOW the existing one, rather than above it. I find I'm using SST to scroll down to the end of existing progs to enter new ones. I may be missing something.

I suppose that programming features are not yet complete. There should be a 000 step, and GTO CHS nnn should jump to the nnn line number.
In the meantime, there is a workaround: enter LBL 99 (for example) after the last instruction of your program, and in run mode enter GTO 99.
And then, g P/R g BST g BST.