Dear 34s-Team,

if I've understood correctly, the process of creating a new layout has already started and there will be some kind of firmware split to accommodate users with old and new overlays alike. I do especially like this latter decision and want to explicitly thank you for it!

I'd like to make a wish nevertheless: Could the 'old' firmware be changed back to exactly match the 'old' overlays by bringing back the f- and g-shifted original behavior of the x<>y key? The 'new' behavior should be reserved for the 'new' firmware and its overlays.

In case there are other instances of firmware and overlay not matching that I have not discovered yet, my wish applies to them as well. ;)

I'm not judging the changes to be bad (or good, for that matter), it's more a question of aesthetics to me to have key presses on my dedicated "WP-34s Mark I" machine to do what is advertised on the outside.

Edited: 20 Oct 2011, 10:46 a.m.

You can of course stick to the files in the release package but I assume your wish isn't too exotic. Let Walter and Pauli comment on it.

v2.1 was the one distributed at HHC - it's the last official one matching the old overlays. The current v2.2 brought the matrix functions and the changed shifted x<>y. Since we'll have a major layout change in the next step (v3.0) discussed here and agreed on already, I suggested internally to stay with the old layout for the final v2.2 build. I did receive no opposing vote in some 30 hours :-) so I think that's what we're going to do.

V2.2 staying as it is now or reverting to the V2.1 layout of the x<>y key?

I 2nd this and it seems reasonable to keep x<>y the same for 2.2 and the old layout. I plan on having a 2.2 and a 3.0 machine.

even if we had it before. :-)

I have the exact same plan! :-)

FWIW, I would like 2.2 to keep 2.1 layout (as seen in HHC 2011), as it was difficult enough to obtain overlays just to throw them away before even applying them (I have now a 20B and a 30B to be reflashed and "re-overlayed" to 2.1 version). I understand that the MATRIX menu could still be accesed via some of the menus. I admit I should read the fine manual, but I'm having a very intense workload, so time for reading and reflashing has been scarce.

I was thinking that, if possible, layout changes would be more manageable if such changes are limited to keys and don't affect the faceplate. The latter is supposed to be very difficult to remove, and it there will also be adhesive traces that may be difficult to clean. It seems that changing the sticker over one or two keys would be much easier.

I accept that the time for suggestions expired some days ago, but this idea may just be considered. My suggestion to bring NULL to the 34S was rejected at first time, but I'm glad that NULL made its way through and is now available. So, let's hope there may be second chances...

If suggestions are still received, TONE and BEEP are my favorites and are still missing :-D

[As always, please disregard any idiomatic mistake]

Hmmmh, Gene, seems your short range memory has been better shortly ;-)

Anyway, here is what I found in the archive.

Edited: 20 Oct 2011, 3:24 p.m.

Yep, it fails quite often. ;-)

So the picture is the V3 leading candidate, with MATRIX on a key?

Me too.

It seems that the only changes to the faceplate are below x<>y and "Show", so the idea of issuing just a few key stickers to update layout from 2.x to 3.x seems feasible. These two differences on the faceplate versions are absolutely acceptable for someone (like me) who is not very fond of the idea of faceplate peeling. We can surely live with them for a while.

OK, I can reflash my 20B with WP-34 v2.x and current overlays; and wait for a 3.x overlay to be applied in the future to the 30B. Even the original HP model numbers would be aligned with this path. But new key stickers will be needed soon!

BTW, would you consider removing the full space between the deveopers' names in the status screen; so the last "r" in Walter may appear full size? I think that

PauliWalter

would be more readable than

Pauli Walte^r

Just my AR$ 0.1

Based on the results of said poll and internal agreements, it is. Now don't you tell me you don't know what you voted for ;-)

Edited: 20 Oct 2011, 3:48 p.m.

I think if you stay with 1722 (says 2.2 1721) you are good. It's the build just before the x<>y key was changed, and yet has the HP41-style press-and-hold hints.SVN revision 1722

There was a bunch of shift and calatlog handling re-working after that, but I'm not sure it is critical.

Marcus, can you tell us if it would be worth "porting" updates such as 1730 into such a build? Are there any other bugfixes we should have in that "2.2 classic" load?

cheers!

Edited: 20 Oct 2011, 4:18 p.m.

Who am I and what do I mean by 'Who am I?'

just kidding.

Good, I like the picture layout and it can be fixed with minimal adjustments to the overlays. I'm pretty confident that Eric can rattle off just the changed key positions with little effect on everyone.

The recent changes were:

Fix the emulator

Make room for more changes

I think, we can do a conditional compilation to reactivate the old x<>y key bindings. The team will decide upon this.

Walter,

If this is the final 3.0 layout, please give me your blessing to update my overlay design to reflect these changes, and I will then start producing overlays with the new design and replacement keys for those who might want them instead of a whole new overlay:

Eric

We are discussing to get rid of -> as a primary function. This would make room for another hotkey.

Nothing is final at the moment, Eric. Please wait before you invest in any designs! If we get the chance we will change more then what you can see on Walter's layout.

Quote:

---

We are discussing to get rid of -> as a primary function. This would make room for another hotkey.

---

Then I would even update my TVM solver, because with 5 hotkeys it could have the usual "N I PV PMT FV" layout. :-)

Franz.

Could STATUS live in MODE ? Perhaps the first (or last entry)?

Just curious.

STATUS isn't an executable command, more of a special state of the calculator. If it were a command, it would be alphabetically sorted-in somewhere.

Eric,

Please wait and watch. The only thing I'm 98% sure about so far is v2.2 will use the old layout.

Walter

In my experience this is a time to "branch by promotion". That is create a branch for "classic" WP34s. The aim being to take the 1722 build and make no more changes to it, except to fix bugs.

Would we call this 2.2 or 2.1? Or something else?

Quote:

---

Would we call this 2.2 or 2.1?

---

Hi all,

My late comment on the old and new layout.

./,

I think it can be moved to a MODE menu, it is the kind of thing that I set once every time I reset the calc.

For the alpha mode, the '.' can be enough to remind that it is here that you get some special chars.

FIX SCI ENG

I think they can be moved to a menu, it is the kind of thing that I set once in a while and stay for a good piece of time.

This would free some keys for more valuable things.

Patrice

Eric:

A generic recommendation (-or- A glimpse into the future):

As we are going to have multiple WP34s versions with appropriate overlays, it would be nice to have the version number printed on the overlay itself somewhere; for instance unobtrusively in one of the corners.

TomC
ps: I've already got two different WP34s's and a HP20b/HP45 clone.

Quote:

---

"classic" WP34s

---

Quote:

---

This would free some keys for more valuable things.

---

Walter

Patrice, I'm constantly voting for leaving the display mode settings on the keyboard. I agree with replacing './,' which is also available as an ON+'.' combination on the device. Maybe a good place for SHOW. It's in the same place as X which makes perfect sense.

My late comments:

I've never felt a need for y<> or z<> commands. If the thinking is that these are useful in programming then I'd argue that CLP is far more common and should remain on the keyboard.

I think || is much too specialized a function to take up keyboard space. If an engineer wants it they can write a short program using one of the hot keys. BTW, I saw this as a former electrical engineering student who had this exact function programmed on a 41C and assigned to shift-+.

So I'd leave CLP at [h]EEX and put pi on [g]/, thus moving || to a menu (probably X.FCN) or maybe remove || entirely. It would actually make a nice programming example.

I love this calculator.

Dave

I 2nd all of that. I also had little use for x<>a as well outside of programming.

I second that. I find CLP very useful in two instances:
1. To quickly get to the beginning of RAM if debugging.
2. To quicly clear all programs in RAM.
Just my opinion of course.
John

BTW- is the idea to move CLP into the P.FCN catalogue?

I 2nd that too.

CLP will go to the CLEAR catalogue. I'm with you with keeping it easily available. The run mode function is duplicated on RTN so this is not an issue. As for clearing RAM, maybe a shift-hold combination may do as a second way to reach the command.

look at Marcus answer, he got ideas.

Patrice

Hi Marcus,

Quote:

---

I'm constantly voting for leaving the display mode settings on the keyboard.

---

Patrice