DM42 News

[Massimo Gnerucci]

(01-29-2017 05:48 PM)rprosperi Wrote:  Massimo - if this makes sense and I haven't broken something dumb, feel free to pass it to Michael, he did ask for layout suggestions.

The obvious suggestion to use operator keys was dismissed with:

Quote:Using the operators would mess up everything. I'd rather put a blind ENTER on one of the operators.

I will forward Thomas's and yours observations to Michael.
Let's wait for his reply...

[Massimo Gnerucci]

A quick reply from Michael!

Quote:Hi Massimo,

Thanks, it's much appreciated.
Attached it the updated layout as I understand the suggestions.

   

[rprosperi]

(01-29-2017 08:01 PM)Massimo Gnerucci Wrote:  A quick reply from Michael!

That's exactly what I meant; seems like timing of this discussion was just right.

Thanks!

[Mark Hardman]

(01-29-2017 05:48 PM)rprosperi Wrote:  Also note that assuming one can use Shift-Letter to get the lowercase of that letter is also not always correct, as Shift-STO ("G") is used for ASTO and Shift-RCL ("H") for ARCL while in Alpha mode. One could argue Shift-Letter should be allowed for all other lowercase letters, while using the 42S-standard method when needing lowercase "g" and "h", but that could be confusing.

Actually, ASTO and ARCL are on the unshifted STO and RCL keys. This creates a conundrum because the % character is entered as shift-RCL (%). There are other keys used by the unshifted alpha keyboard. PI is entered as shift-RDN. Another special case is the small capital E used for the exponent in numbers. This is entered as the unshifted EEX key. Numbers, period and the /, *, - and + operators are all on their corresponding unshifted keys in alpha mode.

This is important because there is no way to enter these characters using the the ALPHA menus. Most of these conflicts can be resolved by abandoning shift-<character> to enter lowercase letters, and instead mapping the original unshifted value to require it be prefixed with the shift key--very much like it is done on the 41c. The problematic case is the % character. Also keep in mind that shift-SHOW is ASHOW in alpha mode.

Mark Hardman

[Thomas Okken]

(01-29-2017 08:01 PM)Massimo Gnerucci Wrote:  A quick reply from Michael!

Nice!

But if I may offer one more suggestion: of course you'll want the shifted letters to be lowercase, but the five keys that now have non-alphabetic characters assigned to them could have shifted assignments as well, e.g. Shift-period for comma.

Something else just hit me: what about digits? Those aren't in the ALPHA menu. Of course the ALPHA menu could be expanded, there's nothing sacred about it having only two rows, but having to use the ALPHA menu to type digits in ALPHA mode is not ideal.

EDIT: I didn't read Mark Hardman's post since we were apparently writing at the same time. It is starting to look problematic to use shift for lowercase. The % and exponent-E could be added to the ALPHA menu, but it would not be a good thing if ASTO, ARCL, and ASHOW weren't on their current keys.

[Guenter Schink]

I've just send a proposal to Michael how to resolve these alpha conflicts.

• Leave the layout as it is
• Add "%" "PI" and the small E to the arithmetic function keys
• Have the shift key produce lower letters
• Invoke the original functions ENTER ASTO ARCL and the digits and +-/* characters by a long press of the relevant key
  

This should be doable by the software. I think it would be a reasonable compromise and consistent.

Comments?
Günter

[Thomas Okken]

(01-29-2017 09:45 PM)Guenter Schink Wrote:  I've just send a proposal to Michael how to resolve these alpha conflicts.

• Leave the layout as it is
• Add "%" "PI" and the small E to the arithmetic function keys
• Have the shift key produce lower letters
• Invoke the original functions ENTER ASTO ARCL and the digits and +-/* characters by a long press of the relevant key
  

This should be doable by the software. I think it would be a reasonable compromise and consistent.

Comments?
Günter

The long-press to allow the letter mappings and the original ones to coexist sounds pretty elegant, but why not go all the way and apply this to %, pi, and small E as well? I think that would be perfect.

Also, I'd still recommend not assigning any characters to ENTER and EXIT. They are both used a lot in ALPHA mode, and using them should not be made more cumbersome by requiring shift or long-press to get their standard functionality.

EDIT: on second thought, maybe all the original functions should be short-press, with letters entered by short-press only where they do not clash with a pre-existing meaning, e.g. the SIN key. This has the advantage that you won't get unexpected behavior when your HP-42S muscle memory is on autopilot.

Of course arguments could be made for other arrangements, and those could be implemented as well, with some way for the user to choose between them.

EDIT 2: Long-press would sabotage auto-repeat, at least for the short-press meanings of keys with long-press. Not a big loss since that's mostly a Free42 feature, not an original HP-42S feature, except on the "up" and "down" keys.

[Mark Hardman]

(01-29-2017 09:45 PM)Guenter Schink Wrote:  Invoke the original functions ENTER ASTO ARCL and the digits and +-/* characters by a long press of the relevant key

Comments?
Günter

After a serious accident, I no longer have the manual dexterity to do shift-hold-<character> without using two hands. Even then it is awkward (I know from how I have had to re-adjust to using the 50g). At the very least, the ALPHA menus should be expanded to include all of the numeric characters and operators.

Another consideration, currently when the 42s is in ALPHA mode, all shifted keys with menus will terminate ALPHA entry and open the menu.

[ETA] Finally, the R/S (and shift-PRGM) key is problematic. In ALPHA mode, R/S will continue a running program. This allows for the entry of characters in a program. The shift-PRGM key terminates ALPHA entry and toggles the programming mode.

[Guenter Schink]

(01-29-2017 11:03 PM)Thomas Okken Wrote:  The long-press to allow the letter mappings and the original ones to coexist sounds pretty elegant, but why not go all the way and apply this to %, pi, and small E as well? I think that would be perfect.

Once the user interface is changed, consistent behaviour is very important for ease of handling. If the shift key invokes lower characters, then there is no place for "%" instead one would expect an "h" similar for "Pi" and the small "E"

Quote:Also, I'd still recommend not assigning any characters to ENTER and EXIT. They are both used a lot in ALPHA mode, and using them should not be made more cumbersome by requiring shift or long-press to get their standard functionality.

ESC doesn't have a character mapped to it, and long ENTER would only be used to confirm the alpha input. I think that's different from entering characters and may justify different behaviour.

Quote:EDIT: on second thought, maybe all the original functions should be short-press, with letters entered by short-press only where they do not clash with a pre-existing meaning, e.g. the SIN key. This has the advantage that you won't get unexpected behavior when your HP-42S muscle memory is on autopilot.

I think there shouldn't be different behaviour. Again consistency is of major importance. The user should not have to think about in which cases long or short presses have to be used.

Quote:Of course arguments could be made for other arrangements, and those could be implemented as well, with some way for the user to choose between them.

EDIT 2: Long-press would sabotage auto-repeat, at least for the short-press meanings of keys with long-press. Not a big loss since that's mostly a Free42 feature, not an original HP-42S feature, except on the "up" and "down" keys.

I believe that auto-repeat is not really important. Michael tries to achieve a more useful enhancement of alpha input. Some minor caveats have to be accepted I think.

Thanks for the input,
Günter

[yoshi74ls181]

How about putting some toggle keys on the first row of the alpha menu?
Perhaps "ALPHA" for uppercase alphabets, "alpha" for lowercase alphabets, and "ORIG" (or "123", "123+-", "NUM", ...can't think of a good name) for the original characters/functions of the HP-42S's alpha mode.
I would still prefer not assigning any characters to ENTER and EXIT, and SHIFT can still be used to toggle uppercase/lowercase for the next character only.
I imagine the default mode should be "ALPHA".
Then, it might be useful to assign "ASTO", "ARCL", and "ASHOW" to the remaining 3 menu keys on the first row.

[lrdheat]

Any chance that the DM-42 will be able to take an odd root of a negative number and provide a real result?

[Harald]

(01-30-2017 05:40 AM)lrdheat Wrote:  Any chance that the DM-42 will be able to take an odd root of a negative number and provide a real result?

No. It will always provide the root with the largest real part. To obtain a real number you will have to rotate the result accordingly.

Edit: At least that is what the HP42s does and what the DM42 should also do.

PS: Only some calculators that can't handle complex numbers will give a real result to a root of a negative number when possible.

[rprosperi]

Thanks to Thomas, Günter and Mark for the corrections to my suggestion and additional suggestions.

If it's true that long-press is an option, I revise my proposal, as seen in the image Massimo posted from Michael, per the following.

All of the 'special' alpha characters, which are available on the 42S keyboard while in Alpha Mode are listed on p. 37 in the manual and illustrated on p. 39.

I propose the alpha keyboard works as follows:

• Layout for capitals as per Michael's latest image, with minor changes noted below
• Lowercase letters are via shift-letter
• All special alpha keys are via long-press of the same keys used on the original 42S
• Un-shifted Characters "-", ":", "." and " " retained as shown
• Shifted characters "-", ":", "." and " " would be the same as un-shifted
• The [R/S] key (both shifted and un-shifted) would not generate any character, to retain the ability to continue program operation, per the real 42S. The "?" character originally proposed for here is available in the Alpha menu
  

This approach is suggested for these reasons:

• Consistency with 42S Alpha keyboard for special alpha-key access (which we all use now without thinking about where they are)
• No characters need to be added to the original Alpha Function key design (less development)
• A few of the most common non-letter keys are easily accessed
  

Of course, this is all predicated on availability of long-press. If that turns out to be not available, I would still prefer to have the special characters available via Shift-key, meaning all lowercase access is via Alpha menus. I believe consistency with the 42S keyboard outweighs the relatively rarely used lowercase. It would indeed be nice to retain auto-repeat, but given the other requirements, it seems prudent to drop it.

[Guenter Schink]

(01-30-2017 09:47 PM)rprosperi Wrote:  Thanks to Thomas, Günter and Mark for the corrections to my suggestion and additional suggestions.

If it's true that long-press is an option, I revise my proposal, as seen in the image Massimo posted from Michael, per the following.

All of the 'special' alpha characters, which are available on the 42S keyboard while in Alpha Mode are listed on p. 37 in the manual and illustrated on p. 39.

Yes, I concur with this proposal, think I didn't understand Thomas' remark on that correctly

Quote:I propose the alpha keyboard works as follows:

• Layout for capitals as per Michael's latest image, with minor changes noted below
• Lowercase letters are via shift-letter
• All special alpha keys are via long-press of the same keys used on the original 42S
• Un-shifted Characters "-", ":", "." and " " retained as shown
• Shifted characters "-", ":", "." and " " would be the same as un-shifted
• The [R/S] key (both shifted and un-shifted) would not generate any character, to retain the ability to continue program operation, per the real 42S. The "?" character originally proposed for here is available in the Alpha menu
  

This approach is suggested for these reasons:

• Consistency with 42S Alpha keyboard for special alpha-key access (which we all use now without thinking about where they are)
• No characters need to be added to the original Alpha Function key design (less development)
• A few of the most common non-letter keys are easily accessed
  

I don't see the necessity to not assign a character to R/S. It's not to much a burden to continue program execution by long press of R/S. How often does this occur. And no change to the keyboard layout would be necessary. Preventing us from further delay Instead I would assign "=" to shift R/S.

Given Michael can accept these proposals I'd see no change to the current layout. However direct access to characters could be expanded. E.G. take the first (old) row, no longer needed for access of the alpha menu that could be used for the various brackets ([{}]) via long press, "< # >" could be assigned to long press of SIN COS TAN respectively. Arrows could be assigned to shifted "+-/*" Other ideas not needing changes to the layout could be thought of.

Quote:Of course, this is all predicated on availability of long-press. If that turns out to be not available, I would still prefer to have the special characters available via Shift-key, meaning all lowercase access is via Alpha menus. I believe consistency with the 42S keyboard outweighs the relatively rarely used lowercase. It would indeed be nice to retain auto-repeat, but given the other requirements, it seems prudent to drop it.

Let's wait and see, if and how Michael reacts to my proposal.
Günter

[rprosperi]

(01-30-2017 10:45 PM)Guenter Schink Wrote:  I don't see the necessity to not assign a character to R/S. It's not to much a burden to continue program execution by long press of R/S. How often does this occur. And no change to the keyboard layout would be necessary. Preventing us from further delay Instead I would assign "=" to shift R/S.

As usual Günter, your comments make sense. I personally agree using long-press for [R/S] is acceptable, I simply was trying to keep as much as possible consistent with the real 42S. Also, using "=" is a better idea than "?" as well, if easy for Michael to change.

(01-30-2017 10:45 PM)Guenter Schink Wrote:  Given Michael can accept these proposals I'd see no change to the current layout. However direct access to characters could be expanded. E.G. take the first (old) row, no longer needed for access of the alpha menu that could be used for the various brackets ([{}]) via long press, "< # >" could be assigned to long press of SIN COS TAN respectively. Arrows could be assigned to shifted "+-/*" Other ideas not needing changes to the layout could be thought of.

I do not think these are bad specific suggestions, however I personally do not think these other character symbols are used often enough to a) justify spending more development and testing time, and b) actually be something one will remember with no label or hint (like ASTO is on STO).

[mfleming]

To turn the calculator off, use the following sequence

<long press><doubletap><pirouette><whistle-Dixie>CHS-key

Sorry! Couldn't resist

[Dave Britten]

I'd really rather not have to juggle long-press, press-and-hold, double-press, etc. Just put the most common characters directly on the keyboard, maybe making use of the shift key for a second plane, and put the rest in the 42S-style alpha menus.

Possible compromise: a submenu within the alpha menu that switches the keys into various modes: lowercase, numeric, Greek, etc.

[Guenter Schink]

(01-31-2017 02:19 AM)mfleming Wrote:  To turn the calculator off, use the following sequence

<long press><doubletap><pirouette><whistle-Dixie>CHS-key

Sorry! Couldn't resist

You're welcome

I think it is time to recap some major objectives of the DM42

• Ensure compatibility to the HP42S as much as possible
• Use Free42, because that has proven to achieve this goal already
• Add some enhancements that make use of modern technology. E.G. large screen, direct alpha input from the keyboard
• give more flexibility by adding an additional row of keys, thus enabling the old top row to be usable all the time
• improved I/O capabilities
  

Now to the alpha input.
1. the old alpha menu structure will be still available regardless of the possible direct input of alphabetic characters. So if you prefer to press a couple of keys for one single character, you may do so
2. as the original keyboard layout doesn't provide for direct character entry some compromise has to be found.
3. there are not enough keys available to serve all alphabetic characters without conflict of the legacy behaviour. The ENTER ASTO ARCL AVIEW, the digits and the arithmetic +-/* also have to be taken care of. This doesn't work or the direct alpha entry would have to omitted completely. What a nonsense if reasonable ways of achieving the underlying goal is possible.
4.The normal entry (other than alpha mode) is not affected at all.
5. When in alpha mode those alphabetic characters printed to the right of the keys are directly accessible. Using the shift key gives you direct access to the lower caharacters of what is on the keyboard.
6. But still there is a need for ENTER ASTO ARCL Digits ASHOW R/S % PI and the small "E". How do we achive that not having another shift key the easiest way? What is so wrong by saying, you can do that simply with a long press of the respective key?
7: Imagine you wish to enter "The anwer is:" that would be 26 key strokes plus one long press of ENTER, less if you keep the shift key pressed where appropriate. It's 41 key strokes when going through the alpha menu plus one normal press of the Enter.
8. Having additional characters at the (old) top row doesn't force you to use it but not using the available real estate for more convenience would be a waste in my eyes.

All above is not saying it will be so, because Michael perhaps has not decided yet. But I believe it would be a working concept everybody could easily adapt. And of course there are some caveats. You'll have to leave alpha either by EXIT or by ENTER(long press) before invoking one of the other menus.

Günter

[jch]

(01-31-2017 12:13 PM)Dave Britten Wrote:  Possible compromise: a submenu within the alpha menu that switches the keys into various modes: lowercase, numeric, Greek, etc.

1 +

[Dave Britten]

(01-31-2017 09:07 PM)jch Wrote:  

(01-31-2017 12:13 PM)Dave Britten Wrote:  Possible compromise: a submenu within the alpha menu that switches the keys into various modes: lowercase, numeric, Greek, etc.

1 +

And to ramble further as to how it might work, suppose the normal behavior is exactly the same as a 42S: no direct alpha input, with all the digits, AENTER, ASTO, ARCL, etc. being mapped exactly as they were originally.

But add a new final page to the Alpha soft menu with menu items that enable the direct input modes, which can then quickly be reached via Shift, Alpha, Up Arrow:

A, a, SYMB, GREEK, ...

Press one of those, and a little bullet appears next to it, like toggling options in the MODES menu (DEG, RAD, GRAD, for example), indicating that particular key plane is now active. Or press the selection that's already active (or maybe ON/EXIT) to disable all of them, and switch back to 42S-style input. And maybe add an option in MODES so that pressing Alpha goes to that page by default and automatically activates A (uppercase characters).

I know a soft-menu full of shift keys sounds like some kind of insane HP 67 fever dream, but I think it could work here.