DM32 review

[Dave Britten]

(05-31-2023 09:52 AM)Vincent Weber Wrote:  The more I use it, the more I like it!
I think the DM32 has the potential of becoming the "35S done right".
I have been thinking of 2 kinds of improvements : non-intrusive ones, gently expanding the functionality while retaining full compatibility. And intrusive ones, that would break compatibility, probably through a new special mode.

I) Non-intrusive:

- Double the numbers of labels and directly accessible registers with lowercase letters (using shift keys) ;
-Increase the number of indirectly accessible registers. Just store 100 in i, and RCL(i) would be valid. Don't bother with the double indexing (I and J) of the 35S, too disruptive for little benefit;
-Introduce labels that are local to a lettered program (00...99) using shift keys;
-Enhance equation editing not to have to delete from the right, with left and right arrow keys, that could simply be mapped to 2 of the F-keys;
-Enhance equation functionality to match the 35S', by allowing STOring into temp variables, and pressing RDN to use (read-only) REGX, REGY, REGZ, REGT and possibly REGL (alternative would be to use LASTX as allowed in the 35S);
-Expand COMPLEX to support ENTER, X<>Y, LASTX, RDN, RUP... for full 2-level complex stack, as pointed by JF;
-Expand complex functions to reverse trigs and hyperbolics;
-Introduce vectors? Not sure, they are pretty useless on the 35;
-Introduce physics constants in a separate menu.

II) Intrusive:

This would mainly dealing with introducing one-line complex numbers, to bring the functionality closer to the 42S', maybe without the little flaw of having to use 2 stack levels to enter a complex number. Maybe COMPLEX, in this mode, could accept One-line entry, like 1 COMPLEX 2 on one line would generate 1+2i. Some thinking has to be done, probably we would need a polar mode and annunciator, and a way to extract parts from a complex number, unlike the biggest design flaw of the 35S!

What do you guys think?

All fine ideas, though I would probably be a bit more conservative. I always liked the 32SII as is, it just needs (lots) more memory. And that problem has already been solved here!

- I would definitely add more storage registers by extending the range of indirect addressing, as you've suggested. MAYBE add an additional flag to enable/disable this if there are program compatibility concerns.
- Originally I thought adding local labels, more global labels, etc. would be a good idea, but I think the quick swapping of active states is a more elegant way of doing it. It's like having multiple program cards for your HP 67, or the program areas of the (unreleased) 95C, but with more convenience and storage space. So I'd keep the labeling as it is now for simplicity and direct compatibility with the 32SII.
- However, I would like to see the option of swapping states while retaining the current storage registers, i.e. having one set of shared storage registers and only swapping out the program/equation storage. And maybe the option of swapping states under program control. Not must-haves or anything, but it would be a nice enhancement.
- Expand complex support - definitely, no reason not to, in my opinion.
- Equation-editor enhancements - yes, arrow keys on the top row function keys would be a nice addition.