43S News

[H2X]

Was thinking to make the space above STO & RCL more calculation related, ie. possibly EXP FIN % d%. This would bring RCL in line with 42S.

I agree regarding the [RCL] key.

Regarding the [STO] key, I do feel that this is the prime candidate for the SAVE, but mostly because of the semantic connection between "storing" and "saving" something. It just feels like the natural place to start looking for SAVE, and it would feel good to find it there. The same thing goes for ASN (assuming it stands for "assign" - I have PDF problems on my iPad...)

In this particular case, the semantic connection wins - for me.

I also like the pattern which is beginning to emerge that the (f) shifted labels are yellow (like on the DM42 and almost like the HP42S). Finding (f) shifted labels at the familiar places and in the familiar colour must be a good thing.

Coindentally, the (f) shifted options are also more accessible in terms of key, suggesting that (g) shifted options be reserved for lesser used functions - unless there is strong affinity between (f) and (g) shifted options (such as % and d%, R< and >P, etc.) which makes it logical to find them om the same key.

[Jaymos]

Was thinking to make the space above STO & RCL more calculation related, ie. possibly EXP FIN % d%. This would bring RCL in line with 42S.

I agree regarding the [RCL] key.

Regarding the [STO] key, I do feel that this is the prime candidate for the SAVE, but mostly because of the semantic connection between "storing" and "saving" something. Even if this takes up one great position for a more calculation related label. I am not sure what the other shifted label of [STO] should be yet.

I also like the pattern which is beginning to emerge that the (f) shifted labels are yellow (like on the DM42 and almost like the HP42S). Finding (f) shifted labels at the familiar places and in the familiar colour must be a good thing.

Coindentally, the (f) shifted options are also more accessible in terms of key, suggesting that (g) shifted options be reserved for lesser used functions - unless there is strong affinity between (f) and (g) shifted options (such as [R<] and [>P]).

I’ll let it simmer for a few days. I have a work trip coming up. Maybe there will be more comments before I change things the weekend.

I try to have the more familiar (read 42S) functions on [f] even though on second thought, the double tap [g] is becoming second nature, so I don’t think double tap [g] will be much of an inconvenience. I see my own operation on the emulator improving already with double tap. I find ‘new’ muscle memory easier to train than changing it from something known, to something similar. I also find that the vertical f and g separation on the soft menus are easier to navigate with the double tap shift rather than f and g shift buttons horisontally spaced for vertically spaced functions. It’s like tap for one up and double tap for two up on the soft buttons.

[H2X]

I find ‘new’ muscle memory easier to train than changing it from something known, to something similar.

I totally agree!

BTW, I see that you already quoted my post while I was making some edits. I'll try to avoid posting prematurely in the future, but for now I just wanted to let you know that if ASN stands for "assign" (due to PDF problems right now I cannot look it up in the manual), I think it sits well on [STO] for the same reason as SAVE.

Have a nice trip, eager to see what comes next!

[H2X]

... the double tap [g] is becoming second nature, so I don’t think double tap [g] will be much of an inconvenience.

Glad to hear it, but you're allowed to reconsider after a few more elaborate calculations!

[dlachieze]

Hi Jaymos & H2X, your discussion about alternate keyboard layouts and interface are interesting but they may deserve a dedicated thread, keeping this one for the official 43S News and bug reports.

[Over_score]

5. [CC] error discovered. Reproducible as follows:

[RESET]
[5] [ENTER] 1 [EXIT] produces Y=5 and X=1.
Now, [CC] produces 5 + i*1 correctly.
Now, [CC] produces Y=1 and X=5 which has the order in reverse.
Now, [CC] produces 1 + I*5 which is not the same as we started with.

[RESET]
[5] [CC] 1 [EXIT] produces X = 5 + i*1 correctly.
Now, [CC] produces X=5 and Y=1 which has the order in reverse again.
Now, [CC] produces 1 + I*5 which is not the same as we started with.

This issue is fixed.
Thank you for reporting.

[Jaymos]

Hi Jaymos & H2X, your discussion about alternate keyboard layouts and interface are interesting but they may deserve a dedicated thread, keeping this one for the official 43S News and bug reports.

Will do.
J

[Walter]

Thanks, Jaco & H2X, for your ideas and bugs found. I concur with Didier thinking you are actually starting something new, deviating significantly from what our 43S was and is meant to be. Thanks for your will to keep it separate in future.

[homebrew]

Any idea when a 43S will be available for purchase?

[Jaymos]

Hi Walter,

Some comments and ideas:


1. # Base change:

Currently to change base, you press [f][#][H] or [f][#][D] or [f][#][2] or the obvious for any number base in range.

Why is B not defined to be a shortcut for binary?

Either way, upon pressing [#], on the emulator, appears a menu with ->, VARS, ST ... and it goes into entry mode with no indication that you are expected to press to change base. I know you always say that one should know what you want to do, but the rest of your calculator is ergonomically optimised, why not make this clear too?

If there would have been no indication (at all), one needs to remember, but with irrelevant text and keys marked, it is misleading. The IJKL registers, ST.X..through ST.D, and the VARS item and the [->] do not work if you press it and do not belong there.

On the real hardware, it may be less of an issue, but still an issue, as the misleading data is less, and only the unresponsive menu line with --> VARS ST.X ST.Y ST.Z ST.T would appear, which is misleading.

I would have liked to see an indication on a menu for HEX, DEC, BIN, OCT and # instead of this. I realise this possibly will mean a menu rather than going straight to the TAM input screen. Maybe a menu with:

HEX, DEC, OCT, BIN, NN
where NN in turn calls the existing function which brings up the TAM screen or a modified one for custom bases.

Possibly on the [f] shift of the menu, the common WSIZEs as in
4 b, 8 b, 16 b, 32 b, 64 b, NN
where NN again calls the existing WSIZE input TAM screen or a modified one for custom sizes.


2. R <> P

[RESET] [3] [4] [>P] does not show the text on the left "r" & "angle" any more. p. 120 of the OM shows the texts.

[>R] does correctly show "x =" and "y =" on the left hand.



3. OM p. 114

" ... converts rectangular coordinates to polar ones (cf. pp. 19f)". The link is incorrect.


4. RBR

I noticed the pattern in your menu names X.FN, P.FN, a.FN. An idea may be to consider the name "RBR" in the same way to "R.BR" or something like that, if maintaining the pattern is important to you.


5. STATUS

The global bit status view command STATUS (in the FLAGS menu) for the 112 flag bits has a very similar role than RBR for the 112 registers. Both are very useful and powerful tools indeed, to such an extent that you may want to bring the bit viewer to a key, with similar type of naming.