WP43 Alternative key layout --> C43

This area is for discussion about these families of custom high-end Scientific Calculator applications for SwissMicros devices.
User avatar
Jaymos
Posts: 1635
Joined: Sun Nov 04, 2018 7:03 pm
Location: Cape Town

Re: 43S Alternative key layout --> WP43C

Post by Jaymos »

Dani R. wrote:
Tue Dec 08, 2020 11:30 am
I still like the shifting of superscript and subscript to g[Up] and g[Dn], latched, still.
It is like that now, for test. The conventional keys have not yet been removed. Both sets work.
Dani R. wrote:
Tue Dec 08, 2020 11:30 am
A question: Is HOME supported and needed in AIM? Otherwise we could use additional triple click for "Num Lock" on/off.
No harm in testing. It is like that for test now, in addition to the other sets of keys explained, HOME (triple f/g) does a simple Numlock on/off. Monitor it in the status line.
Dani R. wrote:
Tue Dec 08, 2020 11:30 am
I see no compelling reason why f[ENTER] and g[ENTER] should not be used in AIM, but maybe a certain restraint is quite appropriate.
I tried to keep the top three lines clean for ALPHA, including ENTER. No other reason.


In this contribution to download:

C43 Simulator for Windows: https://classic43.com/downloads/C43_EMU ... _Rel48.zip
Be sure to delete the binary.bin file from the C43 folder prior to running.
Thanks Dani for the help compiling!

C43 DM42 software image file: https://classic43.com/downloads/C43_48L2.zip
Be sure to do CLR/RESET after resetting the first time.
The C43 firmware still requires DM42 DMCP firmware 3.18 or 3.20.

I have the following changes:

I received a bug report showing that SIG display mode does not work for certain values. That was fixed. I was so happy to see more interest in the SIG display mode which I like so much.

Furthermore, I now detail the revision number directly in the stack as a string. This is useful to me having two DM42’s with differing firmware.

I updated the HOME menu keyboard replicas - it was a bit outdated, now fixed.

Then, the regarding the multitude of locks discussed here, the complicated text of yesterday can be simplified as follows:

f[Dn] and f[Up]: Case & num lock. This is a double lock function. First operation does case, then it does Numlock, as follows:
1. works as expected without Numlock, changing the case.
2. If you are in Upper case already, then the first f[Up] does Numlock.
3. If you have Numlock on, the first f[Dn] clears the Numlock, and back to rule 1.
Numlock is optional here. The normal f shift does the normal limited next digit as 43S-usual.

g[Dn] and g[Up]: sub/sup lock.
1. as expected, activates super- or subscript, locks this mode. Not as per WP43S-normal.
2. The first g[Dn], or clearing of Numlock, or changing of case, clears the super/sub lock as well. Back to rule 1. Setting Numlock does not clear the super/subscript.

An attempt was made to indicate in the place of the WP43S-normal ⍺/Α indicator in the status line, what is happening in terms of the modes.
“N/n” is used for number digits, indicating super- and subscript positions. N meaning locked, and n meaning next character only.
"Ω/𝛚" is used for greek, indicating case. Always next character only.
"A/a" is used for alphabetic.

Beware even if it shows "A" in superscript in the status bar, there remains only a few ("T" and all the numeric digits) in the font for that combination, and it will simply (as per WP43S-norm) disregard the superscript mode and print the normal character. Subscripts also have limited characters, but more more than superscript though.The lists of available characters is shown in the WP43S U V0.17 p196/328, see excerpt below.
.
Clipboard27.png
Clipboard27.png (23.6 KiB) Viewed 2978 times
Excerpt from the quoted WP43S OM. Very glad to see Walter quotes my mother tongue ...
.
Edit: add the snippet from the OM.
Edit²: corrected sloppy writing.
Last edited by Jaymos on Tue Dec 08, 2020 6:57 pm, edited 1 time in total.
Jaco Mostert
Elec Eng, South Africa
https://47calc.com C47 (s/n 03818 & 06199), WP43 (0015). In box: HP42S, HP32Sii, WP34S&C, HP28C, HP35s, EL-506P, EL-W506, PB700; ex: FX702P, 11C, HP67 & HP85; iOS: 42s Byron, Free42+, WP31S/34S, HCalc.
User avatar
Walter
Posts: 3070
Joined: Tue May 02, 2017 11:13 am
Location: On a mission close to DRS, Germany

Re: 43S Alternative key layout --> WP43C

Post by Walter »

Jaymos wrote:
Tue Dec 08, 2020 4:31 pm
Beware even if it shows "A" in superscript in the status bar, there remains only a few ("T" and all the numeric digits) in the font for that combination, and it will simply (as per WP43S-norm) disregard the superscript mode and print the normal character. Subscripts also have limited characters, but more more than superscript though.The lists of available characters is shown in the WP43S U V0.17 p196/328, see excerpt below.
Some background information:
The characters beyond the usual letters and digits were designed for the WP 43S to cover everything required for CONST, U->, L->, MATX, X.FN, etc. Some math symbols were fun designing, so I made them anyway. Other characters were just boring, so I skipped them unless required. If we could cover another language with two or three special letters, I added them.
In university math, subscript letters are more frequently used than superscript letters - hence the difference in the character sets designed for the WP 43S. Whoever can convince us we need a particular character not yet included has a chance to get it.
Jaymos wrote:
Tue Dec 08, 2020 4:31 pm
Very glad to see Walter quotes my mother tongue ...
You're welcome.
WP43 SN00000, 34S, and 31S for obvious reasons; HP-35, 45, ..., 35S, 15CE, DM16L S/N# 00093, DM42β SN:00041
Dani R.
Posts: 349
Joined: Fri May 05, 2017 10:23 pm

Re: 43S Alternative key layout --> WP43C

Post by Dani R. »

There is no recession from our food critic yet, so a few remarks already from me.


I think the status display works very well. Yes, if there is no contradiction, I consider the status display as very well done, no room for improvement.

If you switch off "Num Lock", "Caps Lock" falls back to ON ('A'), no matter if it was OFF ('a') before. "Num Lock" can be switched on and off with f(COS) alone, but also with the triple click of Shift. Using the f[Up] and f[Dn] it is clear that 'N' first falls back to 'A'.

Superscript and subscript can (still) be switched on parallel to g[Up] and g[Dn] via f(EEX) and f(Rv). The state is now latching. By pressing f(EEX) and f(Rv) again, the state cannot be switched off anymore, you have to call the corresponding other function. This is irritating, because "Caps Lock" and "Num Lock" via f(SIN) and f(COS) still have the on/off functionality.

In "Num Lock" I actually miss "+ - * /" directly on the keys. (Is there a symbol for 'E'(EX), like on the 42S?) In the current version of the pudding it is not yet mandatory to have "Num Lock". The display of 'n' in the status line is already a support to find the digits.


Intermediate result; You can, as now proven, superscript and subscript, use "Caps Lock" (and "Num Lock") without shortcuts on f(Rv) to f(EEX). If you still allow the traditional operation, I think you should also put the corresponding symbols on the front panel. In general, I am not very sensitive to the amount of salt in the food. Others add salt or complain about too much salt, where I do not yet taste any problem. So there is still a need for people with a finer tongue to taste it and comment.



Why did I start the current Palaver: Apart from the fact that I would actually like to find fewer symbols on the front panel if possible and if it doesn't disturb the functionality, I'm stuck on an AIM where I can write "fluently" in upper and lower case.

The idea with f[Up] and f[Dn] further thought: Two additional modes, 'C'(, only characters without numbers in upper case,) and 'c'(, only characters without numbers in lower case). In modes 'C' and 'c' the digits are no longer accessible, because Shift is now used as a shift key. Well 'n' can of course be placed on one of the Shift key position...
Sequence on f[Up] f[Dn]
'C' | 'N' | 'A' | 'a' | 'c'
Behavior of the Shift key in mode 'C'.
'C' | 'c' (| 'n') | 'OMEGA' or
'C' | 'c' | 'OMEGA' (| 'n')
Behavior of the Shift key in mode 'c'.
'c' | 'C' (| 'n') | 'omega' or
'c' | 'C' | 'omega' (| 'n')

Of course it is also possible to release the extensions 'C' and 'c' only after a configuration change.





EDIT:
. . f- g- h-
‚c‘ ‚C‘ ‚omega‘ ‚n‘
OR
. . f- g- h-
‚C‘ ‚c‘ ‚OMEGA‘ ‚n‘
C47(DM42) SN:00032 WP43 SN:00016
https://47calc.com
User avatar
Jaymos
Posts: 1635
Joined: Sun Nov 04, 2018 7:03 pm
Location: Cape Town

Re: 43S Alternative key layout --> WP43C

Post by Jaymos »

Thanx for the comments. I will work through it. Real work interferes right now though ...

Until then, let’s get some more comments please!
Jaco Mostert
Elec Eng, South Africa
https://47calc.com C47 (s/n 03818 & 06199), WP43 (0015). In box: HP42S, HP32Sii, WP34S&C, HP28C, HP35s, EL-506P, EL-W506, PB700; ex: FX702P, 11C, HP67 & HP85; iOS: 42s Byron, Free42+, WP31S/34S, HCalc.
User avatar
Jaymos
Posts: 1635
Joined: Sun Nov 04, 2018 7:03 pm
Location: Cape Town

Re: 43S Alternative key layout --> WP43C

Post by Jaymos »

Dani R. wrote:
Wed Dec 09, 2020 1:25 pm
I think the status display works very well. Yes, if there is no contradiction, I consider the status display as very well done, no room for improvement.
Thanx, I think it can stay.
Dani R. wrote:
Wed Dec 09, 2020 1:25 pm
If you switch off "Num Lock", "Caps Lock" falls back to ON ('A'), no matter if it was OFF ('a') before. "Num Lock" can be switched on and off with f(COS) alone, but also with the triple click of Shift. Using the f[Up] and f[Dn] it is clear that 'N' first falls back to 'A'.
This N to A is by design. I think it is less confusing if it falls back from N to A instead of A or a. I found that the additional complication of not knowing whether it will fall back to a or A is too much for my brain, so I changed it to fall back to the calculator default of A.
Dani R. wrote:
Wed Dec 09, 2020 1:25 pm
Superscript and subscript can (still) be switched on parallel to g[Up] and g[Dn] via f(EEX) and f(Rv). The state is now latching.
Question: I changed the whole sup/sub method to latching. Do we want the original yellow arrows to remain? If they remain, do we make those work like the 43S, i.e. non-latching while g[Up] and g[Dn] does latching?
Dani R. wrote:
Wed Dec 09, 2020 1:25 pm
By pressing f(EEX) and f(Rv) again, the state cannot be switched off anymore, you have to call the corresponding other function. This is irritating, because "Caps Lock" and "Num Lock" via f(SIN) and f(COS) still have the on/off functionality.
Please check again and give the exact sequence of error. I tried and it never gets stuck.
Dani R. wrote:
Wed Dec 09, 2020 1:25 pm
In "Num Lock" I actually miss "+ - * /" directly on the keys. (Is there a symbol for 'E'(EX), like on the 42S?)
I found a special E in the font, see below. It is on EEX in numeric font. Done.
I added the 4 operators in Num lock mode. Done.
See below:
.
Clipboard29.png
Clipboard29.png (4.29 KiB) Viewed 2790 times
.
Dani R. wrote:
Wed Dec 09, 2020 1:25 pm
Intermediate result; You can, as now proven, superscript and subscript, use "Caps Lock" (and "Num Lock") without shortcuts on f(Rv) to f(EEX). If you still allow the traditional operation, I think you should also put the corresponding symbols on the front panel.
I have not have any comments on this.
The question as above.
The "do nothing" option means the template stays as is, with the f[Up], f[Dn], g[Up], g[Dn] not marked.
My preference is to not mark any of the caps lock, num lock, and sub/sup lock keys and keep all of them.
Dani R. wrote:
Wed Dec 09, 2020 1:25 pm
IWhy did I start the current Palaver: Apart from the fact that I would actually like to find fewer symbols on the front panel if possible and if it doesn't disturb the functionality, I'm stuck on an AIM where I can write "fluently" in upper and lower case.
If I understand you right, an unmarked bezel with multiple ways to activate these give that fluent writing ability.

Suggestion: Dani, you could possibly consider to modify the simulator code to also show the num lock by changing the descriptions on the keys?? If you do, check with me which version to work on, because the stable version (48) and development versions are not compatible anymore. I would like changes in the later version if you do do it.

Dani R. wrote:
Wed Dec 09, 2020 1:25 pm
The idea with f[Up] and f[Dn] further thought: Two additional modes, 'C'(, only characters without numbers in upper case,) and 'c'(, only characters without numbers in lower case). In modes 'C' and 'c' the digits are no longer accessible, because Shift is now used as a shift key. Well 'n' can of course be placed on one of the Shift key position...
Sequence on f[Up] f[Dn]
'C' | 'N' | 'A' | 'a' | 'c'
Behavior of the Shift key in mode 'C'.
'C' | 'c' (| 'n') | 'OMEGA' or
'C' | 'c' | 'OMEGA' (| 'n')
Behavior of the Shift key in mode 'c'.
'c' | 'C' (| 'n') | 'omega' or
'c' | 'C' | 'omega' (| 'n')

Of course it is also possible to release the extensions 'C' and 'c' only after a configuration change.

EDIT:
. . f- g- h-
‚c‘ ‚C‘ ‚omega‘ ‚n‘
OR
. . f- g- h-
‚C‘ ‚c‘ ‚OMEGA‘ ‚n‘
I have trouble thinking that my brain will remember how to get in and out of the C mode, once I find myself in that mode. That is the reason that I made N fall back to A always, not A or a, because I want to remove a level of complication.

I think the shifting to a C mode using f[Up], where now the new 4 options are available is too much.


J
Jaco Mostert
Elec Eng, South Africa
https://47calc.com C47 (s/n 03818 & 06199), WP43 (0015). In box: HP42S, HP32Sii, WP34S&C, HP28C, HP35s, EL-506P, EL-W506, PB700; ex: FX702P, 11C, HP67 & HP85; iOS: 42s Byron, Free42+, WP31S/34S, HCalc.
Dani R.
Posts: 349
Joined: Fri May 05, 2017 10:23 pm

Re: 43S Alternative key layout --> WP43C

Post by Dani R. »

Jaymos wrote:
Tue Dec 15, 2020 10:32 pm
Dani R. wrote:
Wed Dec 09, 2020 1:25 pm
If you switch off "Num Lock", "Caps Lock" falls back to ON ('A'), no matter if it was OFF ('a') before. "Num Lock" can be switched on and off with f(COS) alone, but also with the triple click of Shift. Using the f[Up] and f[Dn] it is clear that 'N' first falls back to 'A'.
This N to A is by design. I think it is less confusing if it falls back from N to A instead of A or a. I found that the additional complication of not knowing whether it will fall back to a or A is too much for my brain, so I changed it to fall back to the calculator default of A.
I have a different opinion here. But this is not an issue anyway, because this other opinion does not refer to keyboard sequences and key bindings, but "only" to default behavior.

I think when it is sorted out which properties of the AIM should be kept as a separate status, it will become clearer when which status change should have influence on another status, and when not. But this takes time. And/or you get used to a certain behavior.
Jaymos wrote:
Tue Dec 15, 2020 10:32 pm
Dani R. wrote:
Wed Dec 09, 2020 1:25 pm
Superscript and subscript can (still) be switched on parallel to g[Up] and g[Dn] via f(EEX) and f(Rv). The state is now latching.
Question: I changed the whole sup/sub method to latching. Do we want the original yellow arrows to remain? If they remain, do we make those work like the 43S, i.e. non-latching while g[Up] and g[Dn] does latching?
Regarding the yellow arrows, I don't have a final opinion, except of course that I think if the keyboard sequence is supported, it probably needs the arrows. I have another idea though, more on that later.

Regarding latching, I think you can generally keep this behavior. The status line clearly shows what will happen on the next keyboard press. There is no surprise. And different behavior, whether you press g[Dn] or f[Rv], would overwhelm my brain.
Jaymos wrote:
Tue Dec 15, 2020 10:32 pm
Dani R. wrote:
Wed Dec 09, 2020 1:25 pm
By pressing f(EEX) and f(Rv) again, the state cannot be switched off anymore, you have to call the corresponding other function. This is irritating, because "Caps Lock" and "Num Lock" via f(SIN) and f(COS) still have the on/off functionality.
Please check again and give the exact sequence of error. I tried and it never gets stuck.
With branch "C-43-29-Working", commit #f68f6d95, I have the same behavior in the simulator and on the DM42. If I want to superscript a single digit, but then continue writing normally, the latching of the superscript is not intuitive. Sequence: "TEXT" f(EEX) f( 2 ). Superscript remains latching. f(EEX) does not turn off superscript, I have to call f(Rv), or otherwise make some arbitrary change to the input mode to get superscript to turn off again.
Jaymos wrote:
Tue Dec 15, 2020 10:32 pm
Dani R. wrote:
Wed Dec 09, 2020 1:25 pm
In "Num Lock" I actually miss "+ - * /" directly on the keys. (Is there a symbol for 'E'(EX), like on the 42S?)
I found a special E in the font, see below. It is on EEX in numeric font. Done.
I added the 4 operators in Num lock mode. Done.
See below:
.
Clipboard29.png
.
Now I got you! Num Lock mode ('N') and input f(0..9) ('n') are not the same mode! The special E will be available, I suspect, I don't see the commit yet, only in "Num Lock" ('N') mode ([EEX]), but '><' and '+-' remain on f(x<>y) and f(CHS). This does not make sense. Either one has all three symbols available in "Num Lock" ('N'), or none. If one has none of these symbols directly on the key, the special E would come to f(EEX). But f(EEX) is already occupied.

I still plead for having no symbols on the shift (f-) keys. Also, I would like to find all symbols in one menu, without exception. If there were no symbol on f(x<>y), then that position would be free for superscript. This is the idea announced above.
Then one could rather do without the additional yellow arrows.
Jaymos wrote:
Tue Dec 15, 2020 10:32 pm
Dani R. wrote:
Wed Dec 09, 2020 1:25 pm
IWhy did I start the current Palaver: Apart from the fact that I would actually like to find fewer symbols on the front panel if possible and if it doesn't disturb the functionality, I'm stuck on an AIM where I can write "fluently" in upper and lower case.
If I understand you right, an unmarked bezel with multiple ways to activate these give that fluent writing ability.
I mean, the introduction of the shift level h- would allow fluent typing. I realize it, the introduction of 'C' and 'c' is confusing. One should not overload f[Up] and f[Dn] even more. My suggestion: a configuration option to change the behavior of the shift key in AIM.
So far:
'A' -> 'n' -> 'OMEGA'
or
'a' -> 'n' -> 'omega'
With configuration enabled(, I don't have a shortcut yet to name it):
'A' -> 'a' -> 'OMEGA' -> 'n'
or
'a' -> 'A' -> 'omega' -> 'n'

I hope it's a little clearer now.

Jaymos wrote:
Tue Dec 15, 2020 10:32 pm
Suggestion: Dani, you could possibly consider to modify the simulator code to also show the num lock by changing the descriptions on the keys?? If you do, check with me which version to work on, because the stable version (48) and development versions are not compatible anymore. I would like changes in the later version if you do do it.
I saw. "Num Lock" is not yet supported in the simulator in the user interface in an appealing way. So first we have to define if "Num Lock" will definitely stay introduced and which keyboard mapping should be valid then. This is all so long ago, I forgot how I got the ALPHA layout in. So it will take a few days/weeks until I have the branch ready.
C47(DM42) SN:00032 WP43 SN:00016
https://47calc.com
User avatar
Jaymos
Posts: 1635
Joined: Sun Nov 04, 2018 7:03 pm
Location: Cape Town

Re: 43S Alternative key layout --> WP43C

Post by Jaymos »

Sorry, I forgot to push the code with the EEX character. Here it is: #aed058a, Rev48b,

I will work through the comments above and respond and update Rel48b during the weekend.

In the mean time, more comments please, I want to finalise, and my opinion currently is that the yellow shortcuts in the top 3 rows should not be on the template, so I need either support or objections to the loading of the arrow keys in alpha mode. And then if not marked on the keyboard, are they needed as unmarked options (like the unmarked setting contrast on unmarked + and - keys of some HPs, and some unmarked self test functions as well).

I am first in the process of importing new code from 43S side, which keeps me occupied a bit, as the new code breaks my old hacks ... :roll: :roll: :roll: but I will persevere... the end result will be simpler code, closer to the 43S, still having the same functionality we had before. The benefit of the labour now will come in easier to understand code and easier maintenance later.

j
Jaco Mostert
Elec Eng, South Africa
https://47calc.com C47 (s/n 03818 & 06199), WP43 (0015). In box: HP42S, HP32Sii, WP34S&C, HP28C, HP35s, EL-506P, EL-W506, PB700; ex: FX702P, 11C, HP67 & HP85; iOS: 42s Byron, Free42+, WP31S/34S, HCalc.
ferni123
Posts: 36
Joined: Tue Aug 08, 2017 11:24 am

Re: 43S Alternative key layout --> WP43C

Post by ferni123 »

Hello Jaymos,

I really like this project. I would like to ask you if there is any simulator for Linux that I could use for testing. I have seen some posts above a link to a Windows simulator.

I own a DM42, but I think that for quick testing a simulator is more useful.

Thanks,
Fernando
User avatar
Jaymos
Posts: 1635
Joined: Sun Nov 04, 2018 7:03 pm
Location: Cape Town

Re: 43S Alternative key layout --> WP43C

Post by Jaymos »

ferni123 wrote:
Mon Dec 21, 2020 1:56 pm
Hello Jaymos,

I really like this project. I would like to ask you if there is any simulator for Linux that I could use for testing. I have seen some posts above a link to a Windows simulator.

I own a DM42, but I think that for quick testing a simulator is more useful.

Thanks,
Fernando
Thank you.

Linux is the default OS for the main developer Martin I believe, and definitely you can compile a Linux simulator. I unfortunately have NO experience with Linux and I somehow think you have to compile it and it cannot be distributed as binary. Not sure though.

Walter has instructions though, for making the simulator in Linux, OSX & Windows. See the Reference Manual, p204 of 306, Appendix E. I only compile C43 on OSX. Dani compiles C43 for us on Windows: https://gitlab.com/Over_score/wp43s/-/t ... umentation. The instructions referred to above is for WP43S, but for this C43 fork, the git instructions will suitably change to refer to this project.

Currently on Git, I have various branches in progress, the basic structure is: The default "master" on Git is currently at C43-import-27 level which was released as Rel42 on 12 Oct 2020, and this Git "master" will be soon be updated to C43-29-Working which was released as Rel48 on 2020-12-08. I will do a final version 30 (Rel 49) to reflect the final key arrangements which currently are in flux, as stated in the last two weeks' posts. I will not update this release anymore after this, as this is the stable (pre-programming) test version, which has been superseded by THOUSANDS of code changes already and it makes no sense spending time to keep it updated. As said, the only sense is in finalising the shifts on the key layout.

I am constantly working on the new C43 branch which is based on the new WP43S PEM & XEQ version, called C43-PEM-XEQ-importXX. Currently I'm making changes to import15, which should be compilable from Git by the end of tonight, but it is not yet releasable (for a while) until I iron out most discrepancies aka bugs and clashes resulting from importing of the new 43S code.

See the Git repo at https://gitlab.com/Jaymos/wp43c/-/tree/C43-29-Working
Jaco Mostert
Elec Eng, South Africa
https://47calc.com C47 (s/n 03818 & 06199), WP43 (0015). In box: HP42S, HP32Sii, WP34S&C, HP28C, HP35s, EL-506P, EL-W506, PB700; ex: FX702P, 11C, HP67 & HP85; iOS: 42s Byron, Free42+, WP31S/34S, HCalc.
ferni123
Posts: 36
Joined: Tue Aug 08, 2017 11:24 am

Re: 43S Alternative key layout --> WP43C

Post by ferni123 »

Thank you for such detailed explanation. I will go through all the information provided and try to setup a testing environment in Linux. I hope that at some moment I can provide some useful inputs to the project.

Thanks,
Fernando
Post Reply