New firmware for the Swissmicros DM15L

[jebedeo]

Hi All,

Thanks for all the bug reports!

Here's what I have fixed:
1. The R/S weird behavior should be fixed. I never got to seeing the calculator turning off as a result of it, so please check on your end if you still see that weirdness. Also, any key pressed is going to stop the program from running, so essentially behaving like R/S. I am not sure if that's the behavior that we want, it seems to me the most intuitive, but let me know if you think otherwise.
2. ->H, ->HMS, FRAC bugs should be fixed. That time conversion is pesky man! Took me way too long to figure it out. Please stress test it again, especially with large numbers as there are some type casts in my code that might cause trouble there.
3. The calculator is now set to turn off after 10 minutes of inactivity. Too little? Too much?
4. Try those benchmarks again, the old version of the firmware was running at 12MHz, now it's at 48MHz.
5. About program editing. There is a "go to line" function, it's available if you long-press GTO while in program mode. Again, it seemed to me more intuitive than GTO CHS nnn but I am open to changing it if people have strong preferences, it probably could be accessed both ways too. Also, should that function be available also while not editing a program? Another feature is that you can clear program memory completely if you long-press f (CLEAR) PROGRAM. Also, long-press for SST and g BST let's you scroll through instruction at different speeds, pretty cool
6. If you start at the top of the program memory the instruction is added above the first instruction, however there is a bug: after that the behavior goes back to inserting instruction under the current line by default. I need to do some more work there. Ideally I am trying to replicate the HP42 behavior but that might be too involved, so I might tie the behavior to the last pressed step function: if you last pressed g BST you will insert new instruction above current line, if you pressed SST the new instruction will be placed below the current line. How does that sound?
7. Still no ISG/DSE

Have a great weekend!

[Johnp_g]

Excellent!

The H.MS/HR and FRAC bugs are gone, as far as I can tell.

The R/S problem is now absent, I can use R/S to stop the same benchmark prog that I was testing previously after 61 seconds without the calculator turning off.

Speed.... wow!

The HP Museum benchmark tests are SUBSTANTIALLY faster now - faster even than the DM42 and DM32!

The stock DM15L at 48MHz does 676 loops of the "math" benchmark in 60 seconds

The DM42 does 24,701
The DM32 does 46,265
Your previous firmware on the 15L did 1,346

The new firmware does 68,791

https://www.gm4slv.org.uk/dokuwiki/doku....ng#results

I see a new BUG though :-(

Previously I was testing for the cube root of negative numbers, such as -8

8 CHS ENTER
3 1/x
y^x

and the answer would be 1.000 + 1.732i (or in polar 2 <60 )

Now with the latest firmware the result is : NAN

The same for any other negative number raised to 1/3 power - when previously it gave the correct "1st quadrant" complex result.

Otherwise, it's a great step forward.

The more I use it, the less I like having to terminate STO and RCL with ENTER, though!

Cheers,

John

[jebedeo]

John,

great to hear that the speed has improved that much! I was doing something very dumb in the loop that executes operations from program memory, but I didn't think it was 50x dumber lol

I fixed the bug you found with powers of negative numbers, thanks!

Quote:The more I use it, the less I like having to terminate STO and RCL with ENTER, though!

Alright, I added auto-termination for STO/RCL and similar functions to the list of things to change

[Johnp_g]

Nice work!

The bug fix works perfectly.

I note you've moved the location of the Polar annunciator to the top row, to prevent the movement when f or g shift is active - it looks much nicer now!

The speed improvement over stock DM15L is remarkable, although depends very much on the choice of benchmark program and the functions used.

The HP Museum's https://www.hpmuseum.org/speed.htm test shows your firmware is even faster than the DM32.

https://www.gm4slv.org.uk/dokuwiki/doku....ng#results

Using a different benchmark test, from https://www.thimet.de/CalcCollection/Cal...mance.html shows less of a boost in speed relative to the DM32/DM42, although still much faster than the stock DM15L.

https://www.gm4slv.org.uk/dokuwiki/doku....g#results2

I'm really happy with the functionality now - I know some would like the solver and integrator to be added, and I'd also find that a worthwhile addition, although not something I'd use often, to be honest.

As for the STO/RCL issue - you must do what you feel happiest with - the firmware must be pleasant for you to use, and meet your design goals, you can't change it just please everyone else, and I don't want to throw you off your original design plans! It just feels awkward using ENTER in this way - but that's possibly just something I need to get used to :-)

Thanks for the great work. My DM15L is now my go-to pocket calculator.

John

[Johnp_g]

Sorry,

A new bug has come to light.

The 10^x function doesn't work correctly. I hadn't checked it on an earlier version, but in the latest beta240921 it returns odd values.

clear stack (0 enter enter enter)
1
10^x

gives 0.00000

1 enter (puts 1 in X and Y)
10^x

gives 1.00000


2 (leaves 1 in Y and 2 "open" in X)
10^x
gives 1

2 enter (puts 2 in X and Y)
10^x
gives 4 (leaves 2 in Y, 4 in X)
10^x
gives 16 (leaves 2 in Y, 16 in X)
10^x
gives 65536

It seems to matter what's in Y AND in X, and never gives 10^x in any circumstance. Almost operates like Y^X but not quite, as the stack doesn't drop.

Just tried with beta240914, beta240916 and 10^x works correctly with those versions.

beta240920 has the 10^x bug, as does the latest beta240921

There's always something!

John

[RPNerd]

(09-21-2024 07:53 PM)Johnp_g Wrote:  The 10^x function doesn't work correctly. I hadn't checked it on an earlier version, but in the latest beta240921 it returns odd values.

It looks like it's doing y^x instead of 10^x.

[Johnp_g]

(09-21-2024 08:14 PM)RPNerd Wrote:  

(09-21-2024 07:53 PM)Johnp_g Wrote:  The 10^x function doesn't work correctly. I hadn't checked it on an earlier version, but in the latest beta240921 it returns odd values.

It looks like it's doing y^x instead of 10^x.

Except in Y^X the stack drops after execution, but not in this buggy 10^x, where Y remains as it was, otherwise yes, that's what it looks like.

[Helix]

(09-21-2024 01:32 AM)jebedeo Wrote:  2. ->H, ->HMS, FRAC bugs should be fixed. That time conversion is pesky man! Took me way too long to figure it out. Please stress test it again, especially with large numbers as there are some type casts in my code that might cause trouble there.

4.1 → H.MS gives 4.056 instead of 4.06
I also notice that the full precision is not used for time conversions, only about 10 digits. I don’t think it’s a problem, but this should be specified in a future documentation.

Quote:3. The calculator is now set to turn off after 10 minutes of inactivity. Too little? Too much?

Perfect!

Quote:4. Try those benchmarks again, the old version of the firmware was running at 12MHz, now it's at 48MHz.

This change was immediately noticeable to me: I had to change the battery.
But it was depleted.

Quote:5. About program editing. There is a "go to line" function, it's available if you long-press GTO while in program mode. Again, it seemed to me more intuitive than GTO CHS nnn but I am open to changing it if people have strong preferences, it probably could be accessed both ways too. Also, should that function be available also while not editing a program? Another feature is that you can clear program memory completely if you long-press f (CLEAR) PROGRAM. Also, long-press for SST and g BST let's you scroll through instruction at different speeds, pretty cool

I didn’t know the long-press GTO. It works nicely, as the long-press SST/BST.

I don’t use my DM-15, and I haven't even read the entire HP 15C manual! But I think that for debugging, in some cases it could be useful to jump to a specific line number in Run mode, without having to enter program mode to type this command.

For clearing the entire program memory, I’ve found that the f prefix is not necessary: a long press on R↓ has the same effect

Quote:6. If you start at the top of the program memory the instruction is added above the first instruction, however there is a bug: after that the behavior goes back to inserting instruction under the current line by default. I need to do some more work there. Ideally I am trying to replicate the HP42 behavior but that might be too involved, so I might tie the behavior to the last pressed step function: if you last pressed g BST you will insert new instruction above current line, if you pressed SST the new instruction will be placed below the current line. How does that sound?

The current solution is not satisfying, as it’s impossible to insert an instruction between the first and the second line.
The other proposed solution seems complicated to me, as one has to remember if the last movement was SST or BST. That sounds confusing.
I don’t know how to solve this problem, but I note that the HP solution is very good: the step 000 is a convenient way to go to the very beginning of the program memory.
Also, keying BST from that step jumps directly to the last instruction in program memory. Currently there is no easy way to do that, apart from leaving permanently a dumb label at the end of the programs, or doing a long-press SST.

[Helix]

Another bug:
1 ENTER 2 ENTER 3 ENTER 4 and then R↓ R↓ R↓ R↓ should give successively 3 2 1 4 on the X register.
Currently, 4 remains on the X register, and the Y register shows 2 1 3 3

[jebedeo]

Thanks for finding all those bugs!

1. -> H.MS now checks for carry and formats things right. Hopefully I finally got it right lol
2. The bug in Roll down is fixed
3. Go To Line is now also accessible from run mode. Also, you really need to long press f CLEAR PROGRAM now to fully wipe program memory, not just Roll down
4. The program editing is now just like in the other hp calculators, where instruction 0 is always empty and is used to insert instruction above the beginning of memory. Thank you for pointing out that easy solution!
5. Program editing now wraps around the memory, meaning if you are at the end SST will bring you back to program memory address 0, and viceversa BST if you are at the beginning.
6. 10^X was fixed
7. Some nasty bugs were squished that could cause operations in program memory to be displayed as a different operation. If you put GTO 6 in the middle of a program on an older firmware you will see things get confusing... anyways, that should be fixed now.

Thanks everyone for your input!

[Johnp_g]

(09-23-2024 03:54 PM)jebedeo Wrote:  Thanks for finding all those bugs!

1. -> H.MS now checks for carry and formats things right. Hopefully I finally got it right lol

Sorry to say :

Although 4.1000 -> H.MS now gives 4.0600 correctly

I found that following this with ->H gives 4.1111111111 rather than 4.1000

In general

1.0600 ->H gives 1.1000
2.0600 -> H gives 2.1000
3.0600 ->H gives 3.1000

but higher numbers 4 upwards the Hours conversion is now wrong

4.0600 ->H gives 4.11111111111
5.0600 ->H gives 5.111111111111
6.0600 ->H gives 6.1111111111

etc.


Otherwise congratulations on the other bug fixes and enhancements. I don't have time this week to check exhaustively, but certainly it seems the 10^x and Rolldown bug are fixed.

Cheers,

John

[Helix]

(09-23-2024 03:54 PM)jebedeo Wrote:  4. The program editing is now just like in the other hp calculators, where instruction 0 is always empty and is used to insert instruction above the beginning of memory.

Thank you for the enhancements and bug fixes.
However, a long press GTO n displays the lines n-2 and n-1. It should display the lines n-1 and n.

[Helix]

(09-23-2024 03:54 PM)jebedeo Wrote:  2. The bug in Roll down is fixed

Here is another one
1 ENTER 2 ENTER 3 ← 4 and then R↓ R↓ should give 2 then 1 on the X register, but it gives 2 and then 2 again.
In fact, the HP behavior can be replicated with two presses on ←, but I find this confusing. When the leftmost digit is cleared with backspace, the X register should be 0, without stack lift on the next entry.

[jebedeo]

Hi All,

Thanks for all the bug hunting!

1. I fixed, again, the -> H and -> HMS, knock on wood.
2. Fixed the wrong stacklift behavior with digit entry, backspace, and rolldown.
3. Fixed the GTO pointing to the wrong line number
4. STO/RCL, FIX/SCI/ENG, flag check/set/clear, and GOT/GSB now supports index register I and (i)

Working on ISG/DSE next...

[Helix]

1.
300000 →HMS gives -129496.7296

2.
In RUN mode, a long press on SST shows the current program line, as expected, except if the previous line was a digit.
Consider for example the program LBL A 5 * RTN
In RUN mode, after GTO A, a long press on SST shows:
1 LBL A
3► 5
Which is OK

But the second press on SST shows:
3 5
X: 5_

3.
In SCI mode, 1E3 is displayed 10E2, same problem with 1E6, 1E9, 1E12...
In FIX mode, 1E18 is displayed 10E17, same problem with 1E21, 1E23, 1E24…
In ENG mode, 1000 is unchanged (I think it should be displayed 1E3), 1E6 is displayed 1000E3…

4.
FIX mode should be limited to FIX 14, because with FIX 15, 1E-15 is displayed 0.

5.
Imagine RCL is pressed inadvertently instead of STO, then ← clears the X register.
Same problem with GTO, GSB, FIX, SCI, ENG, etc.
Perhaps a solution is to mimic the HP 15C, where f PREFIX cancels any prefix (p.19 of the owner’s handbook).

[jebedeo]

Hello,

Here is another beta, Thanks for all the bug findings Jean-Charles!

1. display with FIX/SCI/ENG should now be fixed
2. SST not displaying the second line of code when something is in the i/o buffer is now fixed
3. STO/RCL et cetera, which I call settings in my code, can now be canceled by a backspace, without deleting the X register. Since every setting can be cancelled that way, I am not sure what f PREFIX should do. perhaps an extra functionality if there is memory left?
4. DSE/ISG are now implemented. I tried the example from the manual and it works, but I am sure there are bugs somewhere, so I will test some more in the next few days.
5. fixed the overflow bug in -> H and -> HMS that you found, thanks for spotting it!

[Helix]

This one is rather weird:
If I enter this program : LBL A 1 + RTN
Then in RUN mode : 1 ENTER 2 ENTER 3 ENTER 4 f (LBL) A gives 4 in the X register instead of 5.
R↓ R↓ R↓ then gives 2 1 1 in the X register, instead of 3 2 2.

In FIX mode, when the integer part of the number has 15 or 16 digits, there is no period. I find that confusing.

(09-28-2024 05:10 PM)jebedeo Wrote:  3. STO/RCL et cetera, which I call settings in my code, can now be canceled by a backspace, without deleting the X register. Since every setting can be cancelled that way, I am not sure what f PREFIX should do. perhaps an extra functionality if there is memory left?

f PREFIX has another very useful role in the HP 15C: it shows the mantissa of the X register, so 10 digits regardless of the FIX/SCI/ENG mode. It would be nice to see the 16 digits provided by your firmware.
Since you don’t use BCD arithmetic, f PREFIX could even display more digits, allowing to see a more precise approximation of the stored number (I mean 0.1 for example is stored internally as a number that is not exactly 0.1).

[Johnp_g]

Nice work again!

I've been able to use the "Savage" benchmark which requires DSE and it worked correctly.

The speed is also impressive at 6.3 seconds. This compares to 4 minutes 48 seconds for a normal DM15L at 48MHz, 6.3 seconds for a DM32 and 14.9 seconds for a DM42

I was checking the LastX functionality and I think I've found a bug.

1
ENTER
+
3
gLSTx

should raise 3 to Y, 2 to Z and bring 1 from LastX to X

I see that with 3 in the "open" X register that when gLSTx is pressed that 3 remains "open" in X, Y becomes "0" and the stack raises 2 into Z, and the "1" in LastX doesn't get recalled.

ie. LastX isn't recalled to X if there's a number "open" in X.

If X has been "closed" by ENTERing a value then gLSTx works - but this isn't what you want if you don't want the stack to raise before calling LSTx

Follow the example on P.40 of the HP15C manual to see another example of this mis-behaviour

Otherwise it's working nicely.

One issue I found, but I'm not calling it a bug, until I do some more investigation.

I tried a long and complicated program I'd previously written (to calculate Butterworth Filter coefficients and component values) which uses a lot of calls to I and (i), Subroutines and ISG looping but when I ran it I got "Out Of Memory". It runs fine on a stock DM15L (and DM41x, DM42 etc). so I guess there's still something not quite right with the firmware, but this program is rather convoluted and not good for bug finding. I'll try something simpler.

Cheers,

John

[Johnp_g]

Further to Jean-Charles' example of a simple program not using the "open X" value I've found the same bug in a small utility I use frequently (because I'm lazy, and anyway, that's what programmable calculators are for...)

It's a simple way of converting between UK Digital TV channel number and centre channel frequency - entering a low number (<305) means it's a "Channel Number" and we want to calculate the corresponding frequency, and entering a high number (>305) means it's a Frequency and we want the corresponding Channel number.

Simple enough

Code:


LBL D
3
0
5
x<>y
X>Y?
GTO 01
8
*
3
0
6
+
RTN
LBL 01
3
0
6
-
8
/
RTN

A number less than 305 in X should cause the calculation of (X * 8) + 306
A number of greater than 305 in X should cause the calculation of (X - 306) / 8

With the stack full of ZEROs

32
f D

(no Enter after 32, i.e. 32 remains in the buffer (?) not entered in X and duplicated in Y)

The result is

y: 305
x: 306

If I repeat now typing 32 and fD the correct answer of

y:305
x:562

It seems that the contents of the stack (zero or non-zero) have a bearing on whether the value in X is used, or taken as zero, when the program is called with fD

The same effect occurs if I clear the stack to zeros and do

562
fD

The first answer is

y:305
x:306

repeating now with 562 fD gives the correct answer of

y:305
x:32
This "stack handling" business is tricky, isn't it!

Otherwise I'm really enjoying this lates version, with the worst of the bugs now squashed!

John

[jebedeo]

Hi guys,

Thanks for the feedback. Here is a bunch of new things and bug fixes:

1. STO/RCL and all the other settings now auto-terminate. So STO 11 does not require ENTER anymore. Same for STO I and such.
2. In program mode, when using TEST the scroll menu works like before although the arrows have moved, but now you can also use numbers to pick which test to use, like in the 15C. For example, TEST 5 will insert a X = Y? operation. So if you know your TEST codes by heart you can go faster
3. Fixed the stack lift weirdness related to LastX and when using labels to call programs. If anything is in the buffer it should behave properly
4. Numbers are all terminated with a period now, to tell the user that there either are more digits but they can't be displayed, or the precision is set to 0.

Glad to hear that the firmware is still fast, John! I'm a bit puzzled on how can it be as fast as the DM32, as those swissmicros calcs use an MCU with a floating point unit so they should be way faster. Perhaps a benchmark with a lot of logs, trig functions and such would show a difference?

Also, try that Butterworth Filter coefficients program with the new firmware, hopefully the cause of the crash was one of the bugs with the buffer and the stack lift. "Out of memory" is an error that is raised either when the calculator runs out of program memory (seems unlikely in your case and should only happen during program editing, not while running a program) or when the indirect register returns something out of bounds. For example if the index register is 120 and you try to do RCL (i) you will get that error, because register 120 doesn't exist. Also, the program stops execution after an error, so if you go into program mode after a crash it should be on the line that caused trouble, or right after it.

Thanks!