DM32 Prototype Unboxing and Introduction (HP 32Sii upgrade)

[EdS2]

To be fair, though, surely they could use the algorithms, so long as they don't use the code. It would be polite to credit the person they got the algorithms from, for sure. (Edit: that said, I wouldn't want to prejudge whether or not this new product will be open source software. Maybe the experience with the DM42 has shown SM that's there's no great revenue risk from copycats.)

[Vincent Weber]

(09-20-2022 07:40 AM)Thomas Okken Wrote:  

(09-20-2022 06:32 AM)Vincent Weber Wrote:  From this I conclude that DM32 does not reuse Free42 core portions, for instance for the SOLVE and INTEG algorithms, and that DM32 was written 100% from scratch.

Just throw a few tricky cases at SOLVE and INTEG, and look at which points are being sampled, that's as good as a fingerprint when it comes to identifying the algorithms used.

I would need a DM32 for that... The product is not released yet !

[Marco Polo]

(09-17-2022 02:14 AM)Steve Simpkin Wrote:  Logan West has a short video on his YouTube channel showing a prototype SwissMicros DM32 Unboxing and Introduction (HP 32Sii upgrade). It looks very clean with its crisp 3-color keyboard printing. Check out this early preview of what is to come.

https://youtu.be/HPAwQXcJUj0

It seems a very nice calculator.
Frankly speaking i would rather prefer the HP32S keyboard in order to have less cluttered keyboard and use the additional keys row to rearrange the keyboard and get directional keys (similar to 48s/g arrangement): the up/down under shift of 32Sii keyboard is quite unpractical to be used in equation environment and edit.
I find more practical the 35s arrangement, except for the STO/RCL key

[rprosperi]

(09-20-2022 06:32 AM)Vincent Weber Wrote:  From this I conclude that DM32 does not reuse Free42 core portions, for instance for the SOLVE and INTEG algorithms, and that DM32 was written 100% from scratch.

This is correct, DM32 is being written from scratch, and uses no code (or other copying) from DM42. David, like most programmers, can develop, debug and support code from his mind, better than trying to force fit someone else's code.

There is no information available on the algorithms, etc. but it''s possible this can be made available later, once released. That said, and as Thomas implied, this crowd will no doubt push and test it enough that the technique(s) used will probably be revealed pretty quickly. Behavior is indeed based on the improved ROM, and the goal is to reproduce all behavior as closely as possible to the 32Sii, with the exception of cases where the improved precision leads elsewhere (which in fact occurs in more places than one may initially expect).

[Vincent Weber]

Many thanks Bob for the clarification, much appreciated.

So for fractions, it is confirmed that flag 9 (which was flawed in v1 ROM) works as expected in v2 ROM? see Craig Finseth page for v1 bugs description :

http://www.finseth.com/hpdata/hp32sii.php

[rprosperi]

(09-20-2022 12:25 PM)Vincent Weber Wrote:  Many thanks Bob for the clarification, much appreciated.

So for fractions, it is confirmed that flag 9 (which was flawed in v1 ROM) works as expected in v2 ROM? see Craig Finseth page for v1 bugs description :

http://www.finseth.com/hpdata/hp32sii.php

Craig's notes were one of the seminal documents at the start of the project (yes, he's aware of the DM32 and is happy about it). I can say that the Fraction feature has been thoroughly reviewed and tested (not done yet) and am confidant Joe's (and other folks) testing will satisfy the most ardent Fraction users.

[Vincent Weber]

Many thanks Bob, I just don't get the "not done yet" as previously you say that it is been toroughly tested?

Cheers

[Joe Horn]

(09-20-2022 12:25 PM)Vincent Weber Wrote:  So for fractions, it is confirmed that flag 9 (which was flawed in v1 ROM) works as expected in v2 ROM? see Craig Finseth page for v1 bugs description :
http://www.finseth.com/hpdata/hp32sii.php

Yes, flags 8 and 9 work in the DM32 as on the debugged HP 32SII... at least insofar as all beta testing to date has been able to confirm. I can say this with confidence since I was the guy who first discovered the flag 9 bug in the original 32SII.

(09-20-2022 12:35 PM)Vincent Weber Wrote:  Many thanks Bob, I just don't get the "not done yet" as previously you say that it is been toroughly tested?

We DM32 beta testers have tested the fraction features in every way we have been able to invent, so in that sense the testing has been thorough. However, the DM32 is still in development, and as you know, modifying firmware always has the potential of introducing new bugs. Therefore, bug hunting will continue not only during this beta phase, but even after product introduction, since the firmware is flashable, which makes post-introduction upgrades a possibility. Even if there are no bugs at all today, new ones might appear tomorrow.

All of which is a long way of saying that the fraction code has been tested thoroughly but we're not done yet.

[Vincent Weber]

Many thanks Joe! Crystal clear now

[rprosperi]

All non-trivial software has bugs, it's just a matter of how much testing (especially insightful testing) one wishes to do. I have my own threshold and that's called "Joe Horn says it's fine". In point of fact, my own personal threshold is usually well below that, but for a new product like this, I spend more time than usual, ideally asymptotically approaching the Horn limit, but usually missing by a more measurable gap.

[rprosperi]

(09-19-2022 02:37 PM)Ross Barnes Wrote:  Does anyone know whether the solve and integration limitations described on page 14-10 of the HP 32SII Owner's Manual will be enforced?

Yes, these same limitations re: nested/recursive calls will be maintained in the DM32. There are multiple reasons, but limited memory is the main driver.

[Vincent Weber]

One improvement idea: since the up and down arrows will be unshifted on the top row, maybe they could be used as left and right arrows while in the equation editor, to allow correcting an equation without having to delete everything down to the mistake and re-typing what should be kept, as in the real 32SII. This was a major drawback... And since equations on the 32SII are tokenized (as opposed to character-based as in the 27S and Plus42), maybe this review could be tokenized as well, e.g. when pressing the left arrow when the cursor is after SIN(, this would go directly before the S ?

[johnb]

(09-20-2022 07:20 PM)rprosperi Wrote:  ... ideally asymptotically approaching the Horn limit ...

I propose that this become the official name (and official measure) of accuracy+precision with regard to an HP simulator.

[Ross Barnes]

(09-20-2022 08:22 PM)rprosperi Wrote:  

(09-19-2022 02:37 PM)Ross Barnes Wrote:  Does anyone know whether the solve and integration limitations described on page 14-10 of the HP 32SII Owner's Manual will be enforced?

Yes, these same limitations re: nested/recursive calls will be maintained in the DM32. There are multiple reasons, but limited memory is the main driver.

Your presentation (thank you) mentioned 1.5 megabyte of RAM...the 32SII manual claims 33.5 bytes are needed for solve, 140 bytes are needed for integrate and each use one pending subroutine return. Since we didn't have access to the solve or integration scratch variables in the original calculator (did we?) I would think using a few more bytes of RAM and a pending subroutine would be a worthwhile tradeoff for an extra nested or recursive call. I'm ignoring the other multiple reasons for not implementing this option and would be happy to get a modern hardware 32SII with 384 bytes...but I won't turn down the extra memory. Thanks again for your presentation.

[Eric Rechlin]

(09-29-2022 04:44 AM)Ross Barnes Wrote:  

(09-20-2022 08:22 PM)rprosperi Wrote:  Yes, these same limitations re: nested/recursive calls will be maintained in the DM32. There are multiple reasons, but limited memory is the main driver.

Your presentation (thank you) mentioned 1.5 megabyte of RAM...the 32SII manual claims 33.5 bytes are needed for solve, 140 bytes are needed for integrate and each use one pending subroutine return. Since we didn't have access to the solve or integration scratch variables in the original calculator (did we?) I would think using a few more bytes of RAM and a pending subroutine would be a worthwhile tradeoff for an extra nested or recursive call. I'm ignoring the other multiple reasons for not implementing this option and would be happy to get a modern hardware 32SII with 384 bytes...but I won't turn down the extra memory. Thanks again for your presentation.

To be fair, he said it only had 768 KB of RAM, not 1.5 MB, and I believe he also said 512 KB of that was used by the OS (DMCP), leaving 256 KB for the 32SII application. Just running the calculator application may take a good deal of that 256 KB (I honestly have no idea though). Maybe a little could be spared, but there's not as much memory as you think.

[Dave Britten]

Even 256 KB on a 32SII would be many times more than enough for most people I think.

[Sylvain Cote]

(09-29-2022 04:33 PM)Eric Rechlin Wrote:  To be fair, he said it only had 768 KB of RAM, not 1.5 MB, and I believe he also said 512 KB of that was used by the OS (DMCP), leaving 256 KB for the 32SII application. Just running the calculator application may take a good deal of that 256 KB (I honestly have no idea though). Maybe a little could be spared, but there's not as much memory as you think.

Remember that in the MCU world, code are run directly from MCU internal NOR Flash and MCU internal SRAM is only used for data.

Memories (from: STM32U575RI home page)

• 2-Mbyte Flash memory with ECC, 2 banks read-while-write, including 512 Kbytes with 100 kcycles
• 786-Kbyte SRAM with ECC OFF or 722-Kbyte SRAM including up to 322-Kbyte SRAM with ECC ON
• External memory interface supporting SRAM, PSRAM, NOR, NAND and FRAM memories
• 2 Octo-SPI memory interfaces
  

[rprosperi]

Update: The RAM that is likely to be available for DMCP apps on the new platform will actually end up being closer to, but not less than 128KB, as the new SOC uses RAM differently for various stacks, heap, etc. But that is still an enormous leap beyond the 384 bytes (!) in the 32Sii, and will likely be far more than can be readily used (that is, for non-pathologic use).

[Eric Rechlin]

I had forgotten it was running off NOR flash. That makes sense that it would have a lot more memory available. And in that case, with 128 KB of memory available, and only a small portion of it used by extra registers, it does seem surprising that lack of memory is the main driving factor behind not increasing the stack space for recursive calls.

[Ross Barnes]

Thanks to everyone for setting me straight about the available RAM on the upcoming DM32. I'm looking forward to 32sii compatibility (functions, memories, programming steps) with additional options to save and restore state.