New firmware for the Swissmicros DM15L

[Johnp_g]

A quick fix again!

On the speed thing, your firmware is fast on the benchmarks I've tried so far - and the SAVAGE benchmark does have LN and e^x

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

Code:


LBL A
RAD
2499
STO 0
1
ENTER
ENTER
ENTER
LBL B
X^2
SQRT
LN
E^X
ATAN
TAN
+
DSE 0
GTO B
RTN

It runs this as fast as a DM32, in 6.3 seconds.

I found another benchmark at https://www.thimet.de/CalcCollection/Cal...mance.html

in which LC15C is not quite as fast as DM42/32.

A previous firmware version (not the latest) did 1000 loops in 42.8 seconds, compared to DM42 in 21 seconds and DM32 in 13 seconds.

The stock DM15L only managed 10 loops in 12 seconds, I didn't try 1000 loops!

So it's still very much faster than stock DM15L.

(09-30-2024 03:31 AM)jebedeo Wrote:  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.

I've tried again and find it still fails with "Out of Memory". It appears to give up on the first instance it tries to recall the contents of I. Checking the I register it had correctly had the contents 1.005, so the program was able to STO I correctly, but not RCL I

I've written a small test program

Code:


LBL A
1
0
x
STO I
GSB 2
RTN
LBL 2
RCL I
RTN

This should multiply X by 10 and STO in I, then simply RCL I to the stack.

It fails with "Out of Memory" and then, going back into the prog. (had to press gP/R once to clear the "Out Of Memory" and again to enter PRG mode) I see the pointer is at the line "RCL I"

Starting with 3 in X and running the prog, it fails with "Out of Memory", but inspecting I manually shows it's correct at 30 - again proving STO I works programmatically, but not RCL I


Also, I notice that the program lines jump mostly in 2's with the occasional step of 1. Most confusing!

Cheers again,

John

[jebedeo]

Hi John,

Thanks for catching that! Indeed "RCL "I was not working but only as a running program. It's fixed now

Quote:Also, I notice that the program lines jump mostly in 2's with the occasional step of 1. Most confusing!

Some operations such as STO/RCL take up two memory cells, one for the operation and one for the data it needs to, like the register number. So the line number in reality is the program memory cell.

[Johnp_g]

Thanks for the quick fix of the "RLC I" bug.

My little test prog. works properly now.

Trying the "big and badly written" Butterworth Filter program.... after once more typing it all it laboriously.....

It now does not bail out with "Out of Memory" and appears to be running.... displaying

Code:


Running
...

but then it never completes, just seems to hang, and the keyboard can't be used to interrupt it - not with R/S and no other keys are responsive. The only thing I could do was to use the hidden Reset button. Which wipes the program. I don't really want to type it all in again, so I'll see if I can make some smaller progs to test various functions it uses to see if I can find out where the issue is.

It might have quirks that didn't matter on the DM15L but which aren't compatible with your firmware - and I was just lucky to get it working in the first place on the DM15L.... I'll dig deeper into it myself and see if it can be massaged into running.

Otherwise, the firmware is now as feature rich as I need for everyday use. Everything commonly used works, as far as I can tell:

SIN/COS/TAN and inverses
LN/LOG and inverses
SQRT and SQ
ABS / INT / FRAC
Complex Numbers (are fantastic!)
Polar/Rect mode
H.MS / H
>Rad/>Deg
Statistics & Linear Regression all work as expected
Probability functions
ISG/DSE
Indirection (i)/I now work too!

I'll continue to dig into things but so far I haven't spotted any oddness with the Stack handling/roll-up/LastX.

Speed is fast.

On some measures it's as fast as a DM32 or DM42. On others it's not quite so fast, but still MUCH faster than the stock DM15L @ 48MHz

I like the new STO/RCL mechanism.

Are you planning a method of backing up stored programs, as per the DM15L? It would be great to be able to save, or to input, programs via serial port.

And are you planning to utilise the RTC?

Anyway, well done so far, it's a great improvement, as far as I'm concerned, on the native 15C operation. Especially for complex number operations.

Cheers,

John

[Johnp_g]

(09-30-2024 01:42 PM)Johnp_g Wrote:  ISG/DSE

I spoke too soon!

There's a bug with the "Loop Control" for DSE/ISG.

Simple Test prog

Code:


LBL A 
PSE
RCL I
DSE I
GTO A
RTN

I wanted to test my understanding of the different parts of the Loop Control number.

I found, though, that there's a bug in the handling of Loop Control.

Storing 10.00001 in I and running the prog with fA shows a count down from 10 in steps of 1.

Starting with 10.00002 in I and running fA also counts down in steps of 1, when it should be steps of 2.

Starting with the following different numbers in I and running the prog.

10.00003 counts down correctly in steps of 3
10.00004 counts down correctly in steps of 4

etc.

However I found 50.00006 counts down incorrectly from 50 in steps of 5 (not 6 per the control number)

looking closer...

30.00006 counts down in 6's
31.00006 counts down in 6's

but

32.00006 counts down in 5's
33.00006 counts down in 5's

etc...

There may be other errors in step size and decrement (and possibly with ISG too?) but I haven't checked every combination of starting number and increment value.

Perhaps this is enough to work with to find the bug?

John

[Helix]

The firmware evolves nicely. Thank you Jebedeo!

The firmware is now functional for me, except on one point: I really miss the f PREFIX feature.
If I’m working in FIX 4 Mode for example, and want occasionally to see more significant digits, I have to key: f FIX 9 ENTER for example, and then f FIX 4 ENTER to return to the previous mode. This represents 8 keystrokes, while this could be done in only 2 keystrokes with f PREFIX.
Can you implement this function?

[Helix]

(09-30-2024 01:42 PM)Johnp_g Wrote:  It might have quirks that didn't matter on the DM15L but which aren't compatible with your firmware - and I was just lucky to get it working in the first place on the DM15L.... I'll dig deeper into it myself and see if it can be massaged into running.

It could be due to the fact that this firmware uses binary numbers, while the HP 15C uses binary-coded decimal numbers. Try for example 0.1 ENTER ENTER + + 0.3 -
You can test your programs with this simulator, which by default uses for floating point numbers the same format as the new firmware.

[Helix]

With the program: LBL A x=Y? 1 2 RTN
0 ENTER 1 does nothing, instead of giving 2
0 ENTER gives 2 instead of 12
I’ve not checked the other tests.

[jebedeo]

Great finds guys, I really appreciate your debugging. Here's a new firmware with:

1. RAN # was working but the there was no ability to STO/RCL the pseudo-random number generator seed. Now that functionality is implemented. The advantages of trying all the examples in the owner manual...
2. Jean-Charles, there was indeed a bug in the TEST function. thanks for catching that!
3. John, the loop control number was buggy, nice job! I squished that bug.
4. f CLEAR PREFIX now fills the display with digits. I gotta admit it's pretty handy to have this functionality

Quote:It could be due to the fact that this firmware uses binary numbers, while the HP 15C uses binary-coded decimal numbers.

That's a good point. In fact the TEST operation does comparisons of the raw floating point numbers. So X = Y? is actually using the C code 'if (X == Y)' which comes with all sorts of problems. I am not a C expert but my understanding is that it's a hard thing to do. I probably should rewrite that piece and enforce some level of precision.

Quote:Try for example 0.1 ENTER ENTER + + 0.3 -

This is a weird behavior indeed. On the free42 calculator the same operation returns 0, rather than the floating point representational error. Perhaps that code is enforcing the precision to the displayed digits, like in the original 15C?

Quote:Trying the "big and badly written" Butterworth Filter program.... after once more typing it all it laboriously.....
...
I don't really want to type it all in again, so I'll see if I can make some smaller progs to test various functions it uses to see if I can find out where the issue is.

Sorry about that John. If you could send me the code either here or as a direct message I would appreciate it. I can run the calculator code on my desktop so debugging a big program would be easier, and I can also load it as a long string so that's fast. Eventually I plan releasing this stuff too so it's easier to debug for everyone.

Quote:Are you planning a method of backing up stored programs, as per the DM15L? It would be great to be able to save, or to input, programs via serial port.

Yes. The serial port is working properly and I can run commands through it. It's already possible to dump the program memory to serial console, but the problem is that it's not user friendly at all. There isn't enough flash left for a command line interface like in the original firmware, so I might at some point write a companion python script to talk to the calculator. Anyways, the backup feature is in the works but not ready yet.

Quote:And are you planning to utilise the RTC?

I'm not sure. I know there is a buzzer and in theory you could use the RTC and the calculator to set alarms like on the 41X, but you really gotta hate yourself to use that over your phone in 2024 All jokes aside, I'm open to suggestions but with the little memory that is left there isn't much that can be done I'm afraid. writing an interface to set and get the RTC would probably cost too much flash. I'm considering adding a new instruction for program mode, something to measure execution time or something like that. I am picturing something simple that put's execution time in ms to the X register. That would not use the RTC but just the CPU clock, which at 1% precision is more than enough.

Talk soon,

Jebe

[RPNerd]

(10-01-2024 06:10 AM)jebedeo Wrote:  This is a weird behavior indeed. On the free42 calculator the same operation returns 0, rather than the floating point representational error. Perhaps that code is enforcing the precision to the displayed digits, like in the original 15C?

Which Free42 calculator? There are two of them. One uses binary FP routines and the other uses BCD. If you're trying this on the BCD variant then an exact answer is to be expected.

[Johnp_g]

(10-01-2024 06:10 AM)jebedeo Wrote:  

Quote:Trying the "big and badly written" Butterworth Filter program.... after once more typing it all it laboriously.....
...
I don't really want to type it all in again, so I'll see if I can make some smaller progs to test various functions it uses to see if I can find out where the issue is.

Sorry about that John. If you could send me the code either here or as a direct message I would appreciate it. I can run the calculator code on my desktop so debugging a big program would be easier, and I can also load it as a long string so that's fast. Eventually I plan releasing this stuff too so it's easier to debug for everyone.

I'm not proud of it, there are probably many ways to do it much more efficiently.... it evolved from an attempt at using Indirect calls and subroutines on the DM42. I've got a version running on DM41X and this DM15L version also ran perfectly well on the stock DM15L firmware.

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

The DM15L serial port memory dump is there, so you can copy/paste it into a stock DM15L via serial session, to check how it should work.

Expanding the link below the dump listing ":Decode of Dump above" should give the keycode/RPN code, created using Swiss Micros decoding web tool from the memory dump.

For the LF15C I changed references to Labels and Registers above 9 from (eg) .9 to 19 and .0 to 10, otherwise typed it in as displayed on my Wiki.

I'll try it again with the latest version of firmware (thanks for the new bug fixes - the loop control appears to work correctly now!) later today.

To run it enter an odd number (positive or negative) into Y and a frequency in Hz in X and run with fA

e.g.

Code:


5 CHS ENTER
14 EEX 6
fA

This finds the 5 component values for a Butterworth Low Pass 5th order filter with cut-off of 14MHz. The values should be returned in registers R1,R2,R3,R4,R5

Answers from my DM41X version:

R1 = 140.5 EEX -12 (140.5pF)
R2 = 919.7 EEX -9 (919.7nH)
R3 = 454.7 EEX -12 (454.7pF)
R4 = 919.7 EEX -9 (919.7nH)
R5 = 140.5 EEX -12 (140.5pF)

You can check the results against an online calculator https://www.jotrin.com/tool/details/BTOWSPLDTLBQJSQ which agrees with these calculated values given the same start conditions:

Cutoff Freq : 14 [MHz]
Impedance Zo : 50 [ohm]
Number of components : 5

John

[Johnp_g]

(10-01-2024 06:10 AM)jebedeo Wrote:  Great finds guys, I really appreciate your debugging. Here's a new firmware with:

1. RAN # was working but the there was no ability to STO/RCL the pseudo-random number generator seed. Now that functionality is implemented. The advantages of trying all the examples in the owner manual...

Nice.

I just wrote a small prog. to accumulate random numbers in the statistics registers from where I could check the Mean and Standard Deviation of the accumulated statistics.

On 1,000,000 accumulated RAN# numbers:

the mean was 0.4999581578

That's pretty close to a mean of 0.5

For a Uniform Distribution between 0 and 1 I believe the Variance should be 1/12 and the standard deviation would be SQRT(1/12) which is 0.28867513459

the standard deviation of the accumulated statistics of 1,000,000 RAN# was 0.28851391066

Your RAN# generator looks pretty good - although this isn't an area I'm very familiar with, so I might not be the best judge.

John

[Helix]

(10-01-2024 06:10 AM)jebedeo Wrote:  4. f CLEAR PREFIX now fills the display with digits. I gotta admit it's pretty handy to have this functionality

Thank you for implementing this functionality!
However, it doesn’t work as expected.
For example, in FIX mode, 10 7 / appears as 1.42857142857143
But in SCI mode, the same number is displayed 1.428571428571E-1, so here we lose 2 significant digits.

In SCI mode 1E-10 7 / is displayed 1.42857142857E-11, so we lose 3 significant digits.
And in FIX mode, the same number is displayed 0.00000000001429, and we lose 11 significant digits!

In fact, in all the examples above, the display should be 1428571428571429, i.e. with at least 16 digits, without period, and regardless of the FIX/SCI/ENG mode and the exponent value.

[Helix]

(10-01-2024 06:10 AM)jebedeo Wrote:  

Quote:It could be due to the fact that this firmware uses binary numbers, while the HP 15C uses binary-coded decimal numbers.

That's a good point. In fact the TEST operation does comparisons of the raw floating point numbers. So X = Y? is actually using the C code 'if (X == Y)' which comes with all sorts of problems. I am not a C expert but my understanding is that it's a hard thing to do. I probably should rewrite that piece and enforce some level of precision.

I’m not an expert in C either, and I'm not sure what you're referring to.
But it’s normal that 0.1 3 * and 0.3 are considered different by the X=Y? test. It’s not a flaw of the test if 0.1 cannot be exactly represented in binary format. It's up to the user to be careful.

We have the same problem with BCD format, but with other numbers.
For example with the HP 15C (and most calculators), 3 1/x 3 * is different than 1. The advantage of BCD is that these rounding effects are more intuitive, but they are unavoidable.

[Helix]

(09-30-2024 03:31 AM)jebedeo Wrote:  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?

The DM32 uses BCD format, which is slower than binary format, and uses 34 digits instead of ~16, so this explains the difference.

My reference for speed is the HP 50g, even if it’s an RPL machine, so a different animal.
On the Performance Index, your firmware is 3 times faster than the HP 50g.
On the Summation Benchmark, for n=10000 the result is given in 24.5 seconds, so this is 12.6 times faster than the HP 50g.
And the N-Queens benchmark is achieved in about 1.5 second, which is 15 times faster than the HP 50g.

It outperforms the new HP 15C Collector’s Edition in the same proportions. I’m really impressed!

[jebedeo]

Hi John,

thank you for sending over the code. I found the bug that was causing the hard crash. I fixed it but while the code now runs it doesn't put things into the R registers as expected. There might be another bug somewhere. I end up with one of the coefficient in the X register, but that's it.

I created a firmware with the program already loaded so you don't have to type it all, would you take a look at it? I'll keep debugging on my end but since you wrote the code it might be easier for you to spot the problem.

Quote:Thank you for implementing this functionality!
However, it doesn’t work as expected.
For example, in FIX mode, 10 7 / appears as 1.42857142857143
But in SCI mode, the same number is displayed 1.428571428571E-1, so here we lose 2 significant digits.

Ah, I'll take a look. Right now f PREFIX is equivalent to FIX/ENG/SCI 18 depending on which mode the calculator already is in. I might have to do something different to show all the precision there is. Thanks for pointing this out!

[Johnp_g]

(10-02-2024 07:55 AM)jebedeo Wrote:  I created a firmware with the program already loaded so you don't have to type it all, would you take a look at it? I'll keep debugging on my end but since you wrote the code it might be easier for you to spot the problem.

Thanks a lot for this, it makes things much much simpler to debug!

I found the same as you, the program exits early after only calculating one component value, instead of looping around for "n" times, and putting 1 to "n" in R01...R0n

I put some PSE instructions in strategic places to see what's happening and found a bug with the ISG command.

Assuming an order of 3

The first time ISG is used is in LBL1. Reg I is set to 1.003 in subroutine LBL6 (3 being the number of components to calculate/the number of loops to perform).

In LBL1 after the first loop completes, and stores its value in R1 the ISG should increment Reg I to 2.003 and loop again until it's done all 3 and Reg I hits 3.003 and the loop exits (GTO8)

However after the first loop the ISG I command increased Reg I to 101.003 and the loop therefore exits immediately. 101 being significantly greater than 3 ;-)

I made a small test program

Code:


LBL A
RCL I
PSE
ISG I
GTO A
RTN

Initially storing 1.003 in Reg I and running fA the prog returns immediately and checking the I register shows 101.003

Initially storing 1.100 in I and running fA the prog counts:

1.100
2.100
3.100
4.100

and returns. Inspecting Reg I shows : 104.100

Very odd behaviour.

Hopefully this is enough to find the bug in ISG.

It looks like DSE is still working normally.

Cheers and thanks - the DM15/LF15C is now my carry-everywhere calculator!

John

[jebedeo]

Hi John,

found the bug and got rid of it, thanks! your program now works properly, it's a pleasure to see it run. Thanks for the help!


Back to f PREFIX and other stuff

[Johnp_g]

(10-02-2024 03:19 PM)jebedeo Wrote:  Hi John,

found the bug and got rid of it, thanks! your program now works properly, it's a pleasure to see it run. Thanks for the help!


Back to f PREFIX and other stuff

Wow!

Thanks for the very quick fix!

I just typed my program in again and it runs flawlessly on the various test case examples I've got in my notebook.

And it seems very fast too.

Although I don't use this filter prog very often I thought it was a good vehicle for checking many aspects of the firmware as it has lots of GTO and GSB calls, uses I and (i) for looping and storing results and even does a bit of mathematics in the process.

If this mess of a program, and the various benchmarks I've tried, run okay then I think there can't be much wrong to affect normal everyday use.

The prog. is convoluted because I wanted one prog. to solve for both High Pass and Low Pass filters, so needed many tests to choose the necessary action(s) to calculate coefficients and convert them to physical component values.

Your firmware running it properly now is the icing on the cake!

I look forward to the next iteration.

Is the SOLVER and INTEGRATION still on the table, or is there no space left. Although I don't use them often, it would be a shame for a "15C" not to have them if it's at all possible.

Good luck with the fPREFIX fix.

John

[dm319]

I'm imagining ISG and DSG would be very tricky to implement using binary representations as you are counting up and down in fractions of 10 and 100, which can't be represented easily in binary. I've been playing with the Rogue HP-12c and trying to trick it to revealing to me whether it is binary or BCD-based. It's tricky, but I think it's BCD underneath.

One way to get around it would be to convert to decimal then round to, say, 14 digits (well within the 16 decimal digits that double floating point should be able to represent) before checking for equivalence.

Or maybe change the function so that it only works on an integer value?

[jebedeo]

Hey guys, here's another beta. Not much to it, just the f CLEAR PREFIX fixed.

Quote:In fact, in all the examples above, the display should be 1428571428571429, i.e. with at least 16 digits, without period, and regardless of the FIX/SCI/ENG mode and the exponent value.

f CLEAR PREFIX now shows all the precision that we can fit in the display. I am not sure how many significant digits is too many. To display the mantissa I simply multiply or divide by 10 until the integer part of the number to display has 18 digits. So the original floating number will multiply as much as you want, if the display was long enough you could display 100 digits but that would clearly not make sense.

For example, sqrt(2) = 1.41421356237309504880... but if you do it with this firmware and use f CLEAR PREFIX you will see "X: 1414213562373095168. ", so the first 16 digits are correct, and after that it's just noise. So perhaps that's all the calculator should show. I'll read up on floating point numbers a bit more, but for right now know that you can't trust all those digits

Quote:Is the SOLVER and INTEGRATION still on the table, or is there no space left. Although I don't use them often, it would be a shame for a "15C" not to have them if it's at all possible.

Yeah, I am still shooting to do that but it might be a while. I want to run through the manual and check all the examples to make sure I don't have any more major bugs and that all the functionality up to ISG/DSE are implemented.
After that I can go back and do some optimization to free up some flash memory. Right now the firmware takes up 98.28% of the available flash, so we're tight! The solver shouldn't be too crazy to implement, it's a newton method to find roots and that might even fit in that ~1% left. The INTEGRATION seems more complicated, or maybe I am just not so familiar with it. Anyways, I'll keep posting updates as they come.

Thanks for the help!