New firmware for the Swissmicros DM15L

[Helix]

(11-02-2024 03:01 PM)jebedeo Wrote:  

Quote:A very minor remark though:
I think you could remove the line "PrgMemory:" in the output, because when I save the output with Hterm this line is included. Then I have to remove this line from the file for a subsequent load (I can send directly a file with Hterm, no need to copy and paste a sequence of codes!). But it’s not a big deal.

The calculator ignores anything that is not a number, return key, or space, so you can send the file directly with the text header and it should work just fine.

At least with Hterm, it doesn’t work as you describe.
If I insert a letter between two numbers, the program is loaded up to this letter, and the remaining instructions are not transmitted.

[jebedeo]

Hi All,

Here's another beta with some minor bug fixes for display weirdness and a first pass at implementing f INTEGRATE

The integration works with one major difference with respect to the original HP15C: the function that you want to integrate gets computed at the interval endpoints (so if you try to integrate 1/x^2 between 0 and 1 you're going to get a divide by 0 error). I plan on changing this but the algorithm for the integration on an open interval is a bit more complicated than I can fully understand, so it's going to take me some time.

Integration can take a looooong time so pressing any key during it stops it and shows you the last approximation available.

Till next time!

[Helix]

What algorithm do you use? Not only it's desperately slow, but it's even unable to integrate a linear function or a constant! I've tried for example the program LBL0 1 RTN.

The ability to stop the calculations according to the display format, as the HP 15C does, should be implemented.

[jebedeo]

Hi Jean-Charles, I found a very silly bug that was making everything slow and less precise: the step size for the integration at the very first pass was wrong, so the main loop was struggling to converge since it had a factor of 2 to fight against. Thanks for pointing out that it didn't converge fast even for a constant function, that led me to find the bug!

I fixed it now, and boy it is fast!

The precision 'n' set by the user with FIX/SCI/ENG is used to stop the integration when the estimated error is < 10^-n, as in the HP15C.

I am using a Romberg integration (Romberg) of order 0, equivalent to a trapezoidal integration.

Cheers!

[Helix]

I’m glad it was a bug, because the first implementation was very disappointing

However, I still find some oddities.
If I try the example of the Owner’s Handbook p.195 (LBL0 SIN COS RTN between 0 and π), but with FIX 12 mode, the result appears almost immediately, which is impressive. For comparison, the HP 50g with 12 FIX requires 9 seconds to evaluate the integral. The 12 significant digits are of course identical.

But if I try to integrate the square function (LBL1 ENTER * RTN) between 0 and 1 with FIX 6 mode, your firmware requires 13 seconds, and the result is 0.333333492.
In comparison, the HP 50g evaluates the integral in about 1 second, and all 12 significant digits are exact (0.333333333333).
I don’t own a genuine HP 15C, but based on my estimates with the Nonpareil emulator, I think the execution time should be very close to your firmware, and all 10 significant digits are exact. So it performs better than your firmware.
Perhaps it’s a limitation of the trapezoidal rule?

I suppose you know this article about the algorithm used in HP calculators:
https://drive.google.com/file/d/1F19Wf2T...86r_j/view

[jebedeo]

New beta with a more refined integration routine
f INTEGRATE doesn't evaluate the function at the ends of the integrating interval, just like in the HP15C. So you can integrate sin(x)/x between 0 and pi with no problems.

Cheers!

[Helix]

It’s much better now !
It’s more or less comparable to the HP 50g, both in terms of precision and speed.

But if I try to push the firmware to its limits, the HP algorithm shows its superiority.
I’ve chosen the integration between 0 and 1 of LBL0 SQRT SQRT 1/X RTN.

With FIX 3, the result is given in about 13s, instead of less than 2s for same integration with the HP 50g (results: respectively 1.3323 and 1.3327)

With FIX 4, the execution time is about 3min 30s, compared to 12s for the HP 50g (results 1.333203 and 1.333305).

Apart from integration, your firmware is generally 10 times faster than the HP 50G.

[Johnh]

I'm very impressed with this endeavour! And Hp15 with two-line display and Alpha characters.

Can you summarize what you now have included out of the HP15c feature set? I saw it listed at the start of the thread but you've evidently gone a considerable way further. So in general terms what's included now?, and what remains feasibly to be done? and which features will not be possible?

cheers
John

[jebedeo]

Hi John, thanks!

As far as I understand the only thing missing is matrix support. There absolutely is not enough flash memory to implement that, and even if there were that would take me a while cause it doesn't interest me very much. Matrices on a pocket calculator are very cumbersome and in this day and age any PC would be way better for that purpose. For me a pocket calculator is all about speed when I am designing at my desk and need to do some quick math to see what the trade space is like. Perhaps people disagree and there is some cool use case for matrices on a pocket calculator, I am all ears.

That said, on this 15C project there is some room to improve things, especially the integrate algorithm. There might be enough flash memory left to make the step size selection dynamic, to improve performance. As Jean-Charles pointed out my implementation is slower than the 50g and that simply won't do

Other than that, I am sure there are still many bugs to be squished but in terms of functionality I think we're maxed out.

At some point I might measure current draw between the stock firmware and mine, to make sure that I am not leaving some peripherals on while idle.

As always, any input is appreciated. Thank you guys for all the feedback so far!

[Johnh]

hi @jebedeo

Thanks for that update. I think if you have complex numbers, solve and integrate, with programmability and the valuable enhancemts you have made to the display, then its a great package, maybe better than the Voyager sized '41?

I agree totally about the matrix functions. If we need to work with Matrices in this century, then a pocket sized calc with a small display isn't the right tool!

[Helix]

Now the firmware appears almost complete to me.
Matrix calculations are interesting on a graphical calculator like the Hp 50g, but not on a Voyager format in my opinion.
The only thing I would like to see fixed is the case of entire powers of negative numbers. The workaround is easy, but if this special case could be trapped by the firmware, that would be fine. Hopefully, this won’t require too much memory space.
I can live without an improved algorithm for integration.
I think now that this firmware deserves a more suitable hardware than my small DM15, and I will purchase a DM15L next year just for it.

[Johnp_g]

Hi all,

Sorry I've not been keeping up with the latest enhancements - life gets in the way sometimes!

I've just flashed the latest beta and I like it. I don't have a lot of use for integration, but use it occasionally, and it looks like the latest version does everything I would want!

Nice job.

Cheers,

John

[Johnp_g]

Weird behaviour with big numbers...

I was reminding myself of the maximum possible number that could be handled, by finding the factorial of larger and larger numbers until the calculator returned INF...

170 f x! gives 7.257416E306
171 f X1 gives INF

I guessed the max number possible was around 1E307...

so entering

1 EEX 307 ENTER gives 1.0000000E307

but multiplying by 10 doesn't give 1.000000E308, nor does it give "INF", it returns

0

(no decimal places displayed)

dividing now by 10

10 /

gets back 1.000000E307

It looks as though numbers between

2.0000 E 307 and 1.700 E 308 are displayed as

0

but are still available for calculation, and only numbers from 1.800E308 are shown as "INF" and are no longer valid for calculations.

A minor niggle - I don't recall ever needing to work with numbers of this magnitude.

Cheers,

John

[jebedeo]

Hi guys,

Another beta with some bug fixes:

1.

Quote:The only thing I would like to see fixed is the case of entire powers of negative numbers.

that should be fixed now, but give it a stress test!
2. Very small numbers are now displayed properly until they becomes zero. Earlier versions of the firmware had weird behavior with stuff smaller than 1E-318 or so
3. The quirks with very large numbers that John pointed out is also fixed, thanks for catching it!

Quote:I think now that this firmware deserves a more suitable hardware than my small DM15, and I will purchase a DM15L next year just for it.

well that's a compliment!

Another things that I still have to fix is that sin(180) is not 0 but some E-16 small number.

As you might notice the firmware is lighter than before, there are some extra 4kB available now!
I copied the math library into my source code rather than using the already compiled code that comes with the compiler, and that means that there is more room for optimization at compile time, hence more memory savings. The speed seems the same if not a touch faster, at least based on some of the benchmark numbers that John posted a while ago.

Thanks again!

[Helix]

There is something wrong since the recent release of the SwissMicros V33 firmware, that I've quickly tested.
I can flash the calculator with your firmware, but then nothing happens, it looks dead! I’ve even tried your previous firmware, and it doesn’t work anymore!
Only the SwissMicros firmware works.

I’ll try to post the problem on the SwissMicros forum.

[jebedeo]

I'll try on my end but something similar happened to me in the past and it turned out to be an almost dead battery. You might want to try and put a fresh one in if you haven't already.

[Helix]

Thank you for the tip. I’ve checked my battery, and it’s still plenty of power.

I’ve finally succeed after many many attempts! In fact, I’ve reinstalled the old V32 SwissMicros firmware, and then flashed again the calculator with your firmware. And this time, it worked!
I think something has changed internally in the V33 firmware that prevents your firmware from working...

[Johnp_g]

Hello,

I'm not sure what the problem is that Jean-Charles is having changing between Swiss Micros V33 and this beta firmware. I flashed V33 (M1B version) yesterday morning, then flashed the (at that time) current beta 241217, then went back to V33 for a longer test and now I've just flashed the latest beta 241221. No problems encountered going in either direction.

I use the Swiss Micros Windows "Firmware Update" tool, as I've been using a Windows laptop for work related things recently, and not my usual Linux machines, and perhaps this is part of the issue?

I notice that when I use the SM Update tool and load their V33 firmware into it prior to flashing to the calculator that it reports:

"Warning: data not aligned to 32 bits, padded (length was E749, now E74C)"

which doesn't appear for any other firmware (official or 3rd party) that I've flashed. V33 loads and runs correctly despite this warning though.

Reverting to your firmware is behaving "normally" when using the SM updater even when the DM15L is running SM V33 (M1B variant).

John

[Johnp_g]

(Today 07:47 AM)jebedeo Wrote:  Hi guys,

Another beta with some bug fixes:

1.

Quote:The only thing I would like to see fixed is the case of entire powers of negative numbers.

that should be fixed now, but give it a stress test!

The "integer powers of negative numbers" seems to work now, giving a real result and no tiny imaginary part.

However non-integer powers (where the power is greater than 1) of negative numbers now doesn't work....

2 CHS ENTER
2.5
Y^x

gives "NAN" instead of "0 + 5.66i"

Fractional powers (roots) (e.g. 1/3) of negative numbers still work

8 CHS ENTER
3
1/x
y^X

still correctly gives "1.000 + 1.7321i"

I'm impressed that there's now some space to play with - are you going to be able to squash the Sin 180 = 0 issue?

Cheers,

John