▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
With the matrix functions in place, we are discussing a modified keyboard layout at the moment. This would include giving the matrix functions their own catalog(ue), moving OFF to h+EXIT and some other rearrangements.
We have not yet implemented this because I opposed to any change that would render Eric's overlays obsolete. At HHC many units have been flashed to the present layout and we would run into trouble if a user without a cable would receive a (new) overlay which no longer matches his/her software or the other way round (old overlay with current software.)
I herewith kindly ask Walter to prepare one of the bitmaps so we can discuss the changes here and hope that the community will comment on this so we can finally decide what we'll do. The ideas are good but I fear the implications may not be worth the improvements. That's why I'm asking YOU, our audience.
Marcus
Edit: Having read the answers so far I'm leaning towards changing the keyboard, but not in a hurry. Let's discuss the proposed changes with a graphic from Walter in place and we go on from there.
Edited: 7 Oct 2011, 10:26 a.m. after one or more responses were posted
▼
Posts: 429
Threads: 31
Joined: Jul 2011
I just ordered two overlays, so I am not very keen on having to order another set in the near future.
But I also don't think it wise to stop development only because there are some overlays out. In the contrary I would hate to see further improvements stalled for this reason.
Would it be possible and reasonably easy to have the firmware in two versions from here on out? One working with the old keyboard layout the other one with a possible new one.
Edited: 7 Oct 2011, 6:53 a.m.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
Are you volunteering to support one of the versions? :-)
I certainly don't want to support two different ones.
- Pauli
▼
Posts: 429
Threads: 31
Joined: Jul 2011
Quote:
Are you volunteering to support one of the versions? :-)
I certainly don't want to support two different ones.
- Pauli
I would if I were able to, but I'm not. So I will just stick to the latest firmware that supports the old keyboard layout.
Posts: 185
Threads: 20
Joined: Apr 2007
I just ordered 2 overlays too, so I'm not keen on it. But I suppose if the change affects a few keys, a "patch kit" would work well. I would do this rarely and accumulate all desired changes into one drop.
The other reason I'm not that excited is because there are two sets of calculator functions I do not use. One is the statistical functions, and the other is the matrix functions. Why?
In both cases, large amounts of data need to be entered. This is a lot easier in Excel than on a calculator, especially if the calculator does not have some PC interface, which is normally where the data is anyway. It is easier on data entry, checking, and it is easier to see & document the matrix or the statistical data set.
With statistical data, I also prefer to see the data graphically before I start curve fitting or parameterizing the distributions. Much safer that way. Anscombe's quartet is a good illustration of the reasons why.
I greatly appreciate all of the hard work and creativity that has gone into this. But is isn't going to bother me if these functions are a little harder to get to.
Posts: 74
Threads: 2
Joined: Jul 2005
I just ordered two also.
Forrest
Posts: 119
Threads: 18
Joined: Feb 2007
I just ordered three overlays, but I say go for it anyway.
Maybe I should clarify a bit: I have no objection if the overlays change occasionally. Say, once or twice a year. That's good for progress, and I can afford the occasional US$5 outlay.
Edited: 7 Oct 2011, 4:31 p.m.
Posts: 228
Threads: 7
Joined: Aug 2011
I think small changes in the keyboard layout could just be "run-time" configurable no? New options in the MODE catalog.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
Not all that easily.
- Pauli
Posts: 653
Threads: 26
Joined: Aug 2010
There are essentially three or four things I would like to change:
- I really miss LastX. Yes, I know it an be done by RCL L, but for the same reason x<>y could be omitted since x<> Y works just as well. My suggestion: h ENTER = LastX and g ENTER = SHOW. This is consistent with other HP calculators. Move the CONST menu to h EXIT and put FILL in a catalog - it's almost exclusively used for programming anyway, and in manual calculations 3x ENTER does it just as well.
- I can't say why, but the arrangement of the log and exponential functions somehow seems "wrong" to me. I feel they should swap their positions, i.e. ln = f-shift and ex = g-shift. The same way as sqrt is f-shifted and x2 is g-shifted.
- Finally, I wonder if the || function on the divide key really is so important for everyday use that it justifies a valuable position on the keyboard. I am sure there are more useful functions that deserve this place. You may say that || "fits so nicely" on the divide key because all four functions on it are ..."division related". But this should be no reason for wasting this valuable position for a relatively exotic function that most users will not need for their daily manual calculations. I would suggest to put the XROOT function there. I consider this function far more useful for the vast majority of users than ||. If XROOT had been implemented earlier I am sure it already was somewhere on the keyboard now.
- The matrix functions should go to their own menu. The respective key could be h 0 which is now reserved for PSE. Since this functions is only used in programs anyway it can be moved to one of the other menus.
Dieter
▼
Posts: 1,619
Threads: 147
Joined: May 2006
Posts: 28
Threads: 6
Joined: Sep 2011
Dieter,
Quote:
Finally, I wonder if the || function on the divide key really is so important for everyday use that it justifies a valuable position on the keyboard
It does !!!! This is an invaluable function to have on the keyboard for EE's work.
Note that while doing analog design, it is used daily in keystroke mode, and is then as useful as sqrt, x2, trig and exponential functions.
I was initially puzzled by the glyph used (||), but I was really thrilled when I discovered that it was the "parallel" function.
I cannot comment for other engineering/science fields.
So, unless there is another way to keep it easily accessible, or if the trinity decides differently, I would strongly argue for it being kept on the keyboard. I am agnostic regarding its position, though.
Etienne
▼
Posts: 1,619
Threads: 147
Joined: May 2006
Quote:
It does !!!! This is an invaluable function to have on the keyboard for EE's work.
Then write a program for it and map it to A-D. It is a specialized function used by a specialized group.
Posts: 24
Threads: 4
Joined: Sep 2011
I, for one, thought || was nice. but of course I am an electrical engineer (or used to be)
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Posts: 82
Threads: 8
Joined: Nov 2009
Quote:
There are essentially three or four things I would like to change:
I really miss LastX. Yes, I know it an be done by RCL L, but for the same reason x<>y could be omitted since x<> Y works just as well. My suggestion: h ENTER = LastX and g ENTER = SHOW. This is consistent with other HP calculators. Move the CONST menu to h EXIT and put FILL in a catalog - it's almost exclusively used for programming anyway, and in manual calculations 3x ENTER does it just as well.
I strongly disagree about getting rid of x<>y. It is the most frequently used stack manipulation function and deserves its central unshifted position on the keyboard. I agree about CONST and FILL, though. Put LastX on h ENTER in place of CONST.
Quote:
I can't say why, but the arrangement of the log and exponential functions somehow seems "wrong" to me. I feel they should swap their positions, i.e. ln = f-shift and ex = g-shift. The same way as sqrt is f-shifted and x2 is g-shifted.
Finally, I wonder if the || function on the divide key really is so important for everyday use that it justifies a valuable position on the keyboard. I am sure there are more useful functions that deserve this place. You may say that || "fits so nicely" on the divide key because all four functions on it are ..."division related". But this should be no reason for wasting this valuable position for a relatively exotic function that most users will not need for their daily manual calculations. I would suggest to put the XROOT function there. I consider this function far more useful for the vast majority of users than ||. If XROOT had been implemented earlier I am sure it already was somewhere on the keyboard now.
I haven't used these enough to comment.
Quote:
The matrix functions should go to their own menu. The respective key could be h 0 which is now reserved for PSE. Since this functions is only used in programs anyway it can be moved to one of the other menus.
Sounds reasonable to me.
▼
Posts: 756
Threads: 31
Joined: Aug 2010
I don't think that Dieter was suggesting that we should get rid of X<>Y. He was arguing *FOR* LASTx by using X<>Y as an example of another function that is accessible via another method and still exists on the keyboard. I am with him 100% here.
Cheers,
-Marwan
▼
Posts: 82
Threads: 8
Joined: Nov 2009
I understood but adamantly disagree with the concept of accessing x<>y by any other means than a single keystroke. x<> Y is completely unacceptable for such a frequently used function.
▼
Posts: 756
Threads: 31
Joined: Aug 2010
I don't think that anyone disagrees with that. X<>Y is fundamental to RPN and should always be in the primary plane.
Posts: 1,545
Threads: 168
Joined: Jul 2005
h Lastx is the same number of keystrokes as RCL L but uses up another key location. I view that as a bad tradeoff. No gain in efficiency but losing a key position. I would vote against an hLastX change (as if my vote is worth much).
X<>Y however is a different story. Changing it to use x<> Y would now require three keystrokes instead of one. That's a lot of wasted time/effort to replace a VERY commonly used RPN function. Sure, it would free up a space on the keyboard, but at the expense of 2 extra keypresses. The RCL L vs. h LastX takes away a key location but saves no steps.
That's my view of that tradeoff.
This is Walter's baby, but I personally agree strongly with the RCL L and X<>Y choices.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
Gene, you are on my side. RCL L is a perfect replacement for LastX. It just should go into a Beginner's Guide: "Are you missing LastX from your trusty HP-25? Here it is: RCL L."
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
I know they append an open or close parenthesis to Alpha, but are those symbols used enough to really take up two shifted key positions on the keyboard?
I'm merely trying to figure out some way to get the matrix menu on the keyboard and these are about the ONLY places where I would have any reluctance at all with functions placed.
Is there an alternative that could be done for ( and ) ?
▼
Posts: 1,619
Threads: 147
Joined: May 2006
They are also used to scroll the display in base 2 mode.
Use the || key for the matrix functions and you'll be able to keep the symbol too.
ALL, FIX, SCI, and ENG have to somehow be redundant and could be consolidated under yet another menu. E.g. DISP.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
Quote:
ALL, FIX, SCI, and ENG have to somehow be redundant and could be consolidated under yet another menu. E.g. DISP.
We had that already. Being able to change the display format quickly is essential in every day use.
▼
Posts: 1,619
Threads: 147
Joined: May 2006
Really? Do you have any data to back that up? I only ask because I rarely change it. I am curious what others think. Perhaps you already did.
Perhaps its time for a fourth function/key. Can you register a double-click? :-)
▼
Posts: 756
Threads: 31
Joined: Aug 2010
Has there been a previous discussion of SHIFT+HOLD?
I am with Egan here. While I agree that ALL, FIX, SCI, ENG are pretty fundamental I don't change them often and can live with these functions in a sub-menu as long as it has just those four options for quick access. Use one of the existing keys as a menu key and save yourself 3 keys for other uses.
Cheers,
-Marwan
Edited: 7 Oct 2011, 3:09 p.m. after one or more responses were posted
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
giving the matrix catalog a home instead?
▼
Posts: 1,619
Threads: 147
Joined: May 2006
On ENTER? I'd put LASTx there before MATRIX.
From the manual:
Quote:
If you know how to deal with a good old HP RPN scientific calculator, you can start with your WP 34S right away.
Walter needs to append, "unless you are looking for LASTx, then continue reading this manual."
IMHO, LASTx is fundamental to all RPN calculators.
I still say, use || for matrix--no need to change overlay.
▼
Posts: 112
Threads: 9
Joined: Jan 2011
It seems to be consistent, a Catalog should be h-shifted.
Posts: 3,283
Threads: 104
Joined: Jul 2005
Double click isn't possible. Why I change the display format? Because I prefer ALL over any FIX format but sometimes want to watch a result in a different format.
▼
Posts: 31
Threads: 7
Joined: Sep 2011
I agree with you here, Marcus.
Posts: 3,229
Threads: 42
Joined: Jul 2006
They scroll the display in integer mode (in any base not just binary).
They are essential to have on the keyboard for integer work.
The parentheses are a bonus because the graphics turned out nicely. If they didn't, the parentheses would have ended up in one of the symbol alpha catalogues instad.
- Pauli
Posts: 228
Threads: 7
Joined: Aug 2011
done
Users' Guide: Oddities
I've created a section for stuff that might throw HP calc users for a loop.
▼
Posts: 1,619
Threads: 147
Joined: May 2006
Add, "|| isn't 'pause', it's something that is relevant to the EE crowd."
Posts: 112
Threads: 9
Joined: Jan 2011
I am OK with the choices as well.
I will point out that RCL L for LastX is non-intuitive (although well documented in the manual). I am not aware of any previous HP calculator that did not have a shifted key position for LastX. If the layout is being reconsidered, I would ask the Trinity to give thought to:
1. moving CONST to a numeric position and making h-ENTER to be LastX.
One reason Walter gave [1] for CONST being h-ENTER was that it was the only key wide enough for the 'CONST' lettering.
Seeing how STATUS occupies the h-[*] key, it certainly is possible to move CONST to say h-[0], and move PSE to a catalog.
2. Matrix catalog could be h-[6], and move L.R. to its respective catalog.
No demands here! Just a few suggestions. In any case - many thanks for all your work.
[1] Comment 30 @ http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv020.cgi?read=183084
Edited: 7 Oct 2011, 10:26 a.m.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
I don't use LastX often so I may not be the most credible person here but I'm still against duplicating RCL L on a key by itself. As already pointed out the number of key presses is identical and you will certainly have to read the manual in parts to make any use of your WP 34S so it's not asking too much for learning this once.
Posts: 653
Threads: 26
Joined: Aug 2010
For the record: the x<>y example was only for "illustration purposes". Of course I do not want to get rid of a dedicated x<>y key. But for the same reason I would prefer LastX that's called "LastX". ;-)
Dieter
Posts: 756
Threads: 31
Joined: Aug 2010
I like these ideas. The problem is that each of us have different requirements. For example I would choose to replace || with %T (or at least find some other location for %T on the keyboard since I use it a lot). On my machine I have written a tiny program that executes %T and has the label A so it can be run directly.
Anyway, and I know that I have brought this up before, a fully implemented re-assignable keyboard would make everyone happy. Then Eric could throw in a few blank labels with his keyboards )or in my case I could simply use some leftover labels from my HP-41's) and we could all be happy. I have intended for quite some time to take a look at the code and see what it would take to implement some of the ideas I have put forward but unfortunately life continues to get in the way.
But to answer the question of what to do with all the keyboards already out there... I just ordered 4 overlays from Eric and as far as I am concerned I really don't care if I have to order another 4 or 8 or whatever it takes to get to where this calc is going. I certainly don't want to hold up improvements because of an existing base. After all, isn't this how legacy design gums up the wheels of progress?
Just my $0.02 worth.
Cheers,
-Marwan
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
As assignable keyboard is out of the question. We have one single solitary bit of non-volatile RAM free a the moment. Key assignments are impossible in so little space.
How much space would they require? To allow an assignable keyboard, we'll need a minimum of two bytes for each assignable position. So 34 * 4 * 2 = 272 bytes at least. We have exactly 2048 bytes in total for all preserved state -- registers, programs, user settings, everything.
Adding an assignable keyboard will consume way too much memory for this little device.
We've discussed this possibility several times and it always comes down to not enough RAM to do it properly.
- Pauli
▼
Posts: 225
Threads: 9
Joined: Jul 2008
Just a reminder that you can use Keyboard Codes (see page 86 of the Edition 2.1 Owner's Manual) to assign many of the WP 34s keys to a program. The extra step of pressing XEQ before the key is a reasonable alternative to an assignable keyboard IMHO.
Posts: 3,283
Threads: 104
Joined: Jul 2005
The only way to do it would be to do a specialized label search and execute a (short) program for each assigned key. The remaining bit would then be the "User Mode" toggle. The assignments may go to a library page if desired.
▼
Posts: 756
Threads: 31
Joined: Aug 2010
I was thinking about just such a solution but hesitated to mention it since I have not had time to delve into the code at all. This would definitely work for me as at least a partial solution that meets most of my requirements.
Cheers,
-Marwan
Posts: 225
Threads: 9
Joined: Jul 2008
Building on this idea... How about a USER mode where pressing a key (other than the shift keys) will perform a label search for LBL 'k[key code]'. If the label exists, execute the program, else perform the default key function. For the shift keys, on the next key pressed, perform a search for LBL 'f[key code]', 'g[key code]' or 'h[key code]', depending on the shift key that was pressed.
While not as elaborate as the HP-41C key assignment system, it produces four planes of user defined actions while only using 1 bit of RAM.
Just thinking out loud.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
This is not the worst idea one can have. The changes to the code would be minimal. We just need a USER key.
▼
Posts: 225
Threads: 9
Joined: Jul 2008
A USER key (non assignable of course) and an annunciator of some kind. Of the fixed symbols in the display, I don't see the small equals sign or the small down arrow being used for anything in the manual (unless I missed it).
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
You missed it. ;) Both have a use: = denotes any power eating state such as waiting for a serial connection or debug mode. Down arrow denotes alpha lower case mode. Before you ask: The large = is tied to flag D. It might be possible to display a small u in the alpha display to indicate user mode.
▼
Posts: 225
Threads: 9
Joined: Jul 2008
If I could remember what I had forgotten, I could have looked it up :)
If a small u in a corner of the dot matrix display would not be too complex to implement, that should suffice. For the User key, perhaps a shifted plane of the Exit key or a shifted plane of a shift key (as is being discussed in this thread) could be used?
There is not much in this little machine that you three haven't used already. I am still awestruck be the huge (and growing!) feature set.
Posts: 3,229
Threads: 42
Joined: Jul 2006
Quote: The large = is tied to flag D.
Flag A :-)
Quote: It might be possible to display a small u in the alpha display to indicate user mode.
Again this is hard that it appears -- the status line is character based not graphical. So we need a character for the symbol (which we have) and then everything needs to be realigned properly (which is painful). That is assuming there is space in the line for this -- it is pretty busy already.
- Pauli
Posts: 228
Threads: 7
Joined: Aug 2011
hey that's funny Steve, I was looking at the code for how to do something very similar, but I like your idea better.
Sometimes I don't want "A" to run LBL"A", for example. I wanted to be able to turn off that feature and just do XEQ A but otherwise do Sigma+. I found the place in the code to do that top row functions regardless of the LBLs.
I was looking at adding a USERON, USEROFF to the MODE catalog and using one of those last free bits of non-volatile RAM.
Now for what you are suggesting, having something on the MODE catalog would of course impose restrictions (e.g. LBL h05 couldn't be used).
The other thing I wanted to change with the MODE catalog was adding a * or underlining the modes that are currently active.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
Quote:
The other thing I wanted to change with the MODE catalog was adding a * or underlining the modes that are currently active.
That's a really hard thing to accomplish given the current code base. :-(
▼
Posts: 228
Threads: 7
Joined: Aug 2011
I wouldn't say hard, just not elegant.
I think I counted 26 of the entries were "toggles", so I would use a function with a rather long case statement, called from catcmd(), with a case for certain op_codes and append a * depending on the appropriate UState member value.
How are we for text segment space?
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
This would be *very* demanding on flash space. If you want to know how much is left look at the summary.txt file on the realbuild folder.
▼
Posts: 228
Threads: 7
Joined: Aug 2011
.fixed 0x00100000 0x1e380
.revision 0x0011e3fc 0x4
I take this to mean there are 1e3fc - 1e380 = 7c bytes left?!!!
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
Quote: I take this to mean there are 1e3fc - 1e380 = 7c bytes left?!!!
That is about right - 124 bytes. We're trying to reclaim some code space & have been doing so for a couple of months. All the low hanging fruit have long since been collected.
Your idea is sound and positive, it just won't fit.
- Pauli
Posts: 3,229
Threads: 42
Joined: Jul 2006
Quote: I was looking at adding a USERON, USEROFF to the MODE catalog and using one of those last free bits of non-volatile RAM.
The last bit actually. There is only one. We're going to have to be very very careful about using it.
All of the commands hidden by A, B, C & D are available elsewhere on the keyboard. I've almost stopped using the hot keys are shortcuts.
- Pauli
Posts: 756
Threads: 31
Joined: Aug 2010
Yes, I remember that discussion. The basic HP41C has 441 bytes, the HP41CV/CX have 2,233 bytes and they make it work by allocating RAM out of available memory. I understand that the manipulation of memory adds complexity and potential bugs so all I am saying is that it is not completely unfeasible.
There are two features that I deem essential in any machine that is going to replace my 41 or my 48 series machines. In order of importance to me the first is partitioned programs whereby non-alpha labels are local within a program and the second is a fully customizable keyboard (this and the lack of I/O were the only things that kept the 42S from being the perfect calculator). I use my calculators more to write small utility programs and simple arithmetic rather than complex math. The problem with all labels being global is a big issue for me and though the WP34S has some ways to handle this that other calcs don't it will never replace my 41 and my 48 type machines until it offers local labels.
Don't get me wrong. This is a *GREAT* calculator, it just does not meet my requirements for a day-to-day workhorse in its current form. I am using it and I am enjoying it but it has not become my go-to calculator as I hoped it might.
Cheers,
-Marwan
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
V3, if ever being created on the same hardware, will definitely have an END statement and a more elaborate scheme of putting programs in flash.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
I would consider this very unlikely however. There is more capable hardware being developed now. E.g. OpenRPN, DIY RPN, DM 15CC. We'd almost certainly use one of these platforms for our next project.
The 30b is fine and when we started it was really the only thing available (and in many ways it still is), however the screen is very limiting and the amount of RAM is tiny. The flash space is also becoming a limiting factor which wasn't something I thought we'd have big difficulties with.
- Pauli
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
I'm with Pauli in this matter. In fact, the 20b was the only suitable repurposable calculator the time we started with the 34S. But while progressing, we found the 20b contains some very rigid limits: keyboard, display and memory. Keyboard was overcome with the 30b eventually, but the breathtaking display limits the UI most obviously still ;-) So anything going beyond the WP 34S will definitively need a more modern LCD, allowing softkeys - hey, that was possible 25 years ago already, it must be possible in 2012 as well and better!
Ceterum censeo: HP, launch a 43S (and if you stubbornly refuse to, the community is going to do it the old HP way).
Walter
▼
Posts: 528
Threads: 40
Joined: Dec 2008
If you ever do a follow-on calculator, I hope you'll do reassignable keys and have the keys display their function briefly when held down like the 41C. This means the function executes when the key is released, not when it's pressed.
This whole thread shows the value of reassignable keys. Everyone has their favorite functions and everyone has functions that they never use. With reassignable keys, Your Favorite Functions are never more than a couple of clicks away.
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Know. this. All my old (vapourware) designs had an ASN key. But all we can give you with the WP 34S are the four hotkeys you see. Sorry for this, but such's real life so far.
Walter
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
No need for ASN if we delegate it to some labels in program space. Just a user mode setting (maybe a flag?) is needed.
▼
Posts: 756
Threads: 31
Joined: Aug 2010
Hi Marcus,
For now that would be a great solution but in the future (next generation?) a true ASN function would definitely be a better solution. for one thing that would allow assigned keys to be used during programming. With my HP-41 I had a keyboard layout I used for day-to-day stuff and another that I used when programming the calculator.
Cheers,
-Marwan
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
You won't get a true ASN function on the 34S. There isn't the RAM for it. Our next device will have it definitely.
- Pauli
▼
Posts: 756
Threads: 31
Joined: Aug 2010
So I understand. But what Marcus is suggesting is a great interim improvement for the current device.
Cheers,
-Marwan
Posts: 3,229
Threads: 42
Joined: Jul 2006
Quote: V3, if ever being created on the same hardware, will definitely have an END statement and a more elaborate scheme of putting programs in flash.
We effectively have an END statement at the end of each flash block (and main RAM). That's 6 - 8 programs each of which can be up to 506 steps long and they can have multiple alpha labels each. There are 100 local labels in each so every fifth statement can be a label -- that should be sufficient for most things. If it isn't we've back and skip as well.
- Pauli
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
Pauli, I'm just thinking of flash regions of arbitrary length. The internal logic would remain pretty much the same.
Posts: 756
Threads: 31
Joined: Aug 2010
True, but the issue is that I then have to decide what programs go where when developing them and then never move them around or place two programs with the same labels in the same space. This is the real issue since for any given program or limited set of programs I can definitely assign labels accordingly. It is not the lack of labels that is the problem but the fact that any two sharing a "region" have to have different labels and with lots of small utility programs (the way I use my calculator) it is not always possible to plan ahead as to what goes where.
Cheers,
-Marwan
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
I know where you're coming from here and I too tend to use the device in a similar manner -- except when I'm editing and debugging. I've still not had a problem with clashing labels. Generally, I use a block of ten labels for each program. Worst case I switch to run mode and GTO xx to see if a label is already defined.
With the assembler, it is quite possible to off load programs and reload them with SKIP/BACK automatically added -- no labels now.
Anyway, it is very unlikely we'll implement program partitions on the device as it. I've said this many times already, it really isn't as easy as people are making it out to be. If anyone disagrees, please download the sources and implement it. Then I'll have a look and figure out where you got it wrong :-) I'd love to be shown to be mistaken here BTW.
- Pauli
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
Anyway, it is very unlikely we'll implement program partitions on the device as it. I've said this many times already, it really isn't as easy as people are making it out to be. If anyone disagrees, please download the sources and implement it. Then I'll have a look and figure out where you got it wrong :-) I'd love to be shown to be mistaken here BTW.
Well Pauli, since I'm not a C-programmer I'll definitely not implement it into your sources, but I've already explained long time ago how such an END could be implemented very easy and without needing many bytes:
1) add the new statement END and a new opcode for it
2) the 'code' for this END (i.e. when a running program comes to such an END) is just the same as for RTN - you could even make it simply jump to the RTN routine, so almost no new code would be needed
3) when a program reaches a GTO nn or XEQ nn (with nn=00..99) it should just look for this LBL nn not in the complete current flash region but just down to the next END statement, and when the LBL nn is not found then start searching it again beginning from the previous END statement.
In other words: since now an END is separating different programs, the 'search-for-label' routine should just search within the current program instead of the complete flash region.
The only real changes which would be required for this are in this 'search-for-label' routine, and I think these changes would neither be difficult nor cost many bytes.
And with this kind of END implementation you could even simplify the command for clearing a single program - again: just clear the current program between the previous and the next END.
Franz
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
Quote: ...but I've already explained long time ago how such an END could be implemented very easy and without needing many bytes:
As I explained at the time and many times since, I do not believe that doing END properly is as simple or straightforward as has been suggested time and again.
Since I obviously don't know much of anything about the deep dark internals of the 34S software implementation, I'm happily deferring to those who clearly are far more knowledgeable in these dark arts than I to put actions behind their words. Someone, anyone: step up and prove me wrong here -- show me it is very easy.
- Pauli
For those impaired in detecting such: that was sarcasm. The offer to prove me wrong still stands however -- I'd love someone to do that.
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
Since I obviously don't know much of anything about the deep dark internals of the 34S software implementation, I'm happily deferring to those who clearly are far more knowledgeable in these dark arts than I to put actions behind their words. Someone, anyone: step up and prove me wrong here -- show me it is very easy.
- Pauli
For those impaired in detecting such: that was sarcasm. The offer to prove me wrong still stands however -- I'd love someone to do that.
Oh my god, I can't stand this bullshit anymore! :-(
Is "feel free to implement it yourself" or "prove me wrong" all you can say?
Well, then it's indeed a waste of time to make any suggestions.
Franz
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
I'm not the one who bought this up yet again....
In fact I'm getting sick of regurgitating the same response time and again.
- Pauli
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
In fact I'm getting sick of regurgitating the same response time and again.
Well, as long as your only 'arguments' against any new ideas are like this
"I do not believe that doing END properly is as simple or straightforward as has been suggested time and again."
you should not wonder that noone would be satisfied with such an answer!
If I want to believe I would go to a church but not visit this forum ...
Franz
Edited: 10 Oct 2011, 8:24 a.m.
▼
Posts: 429
Threads: 31
Joined: Jul 2011
Franz, you are clearly out of line.
Posts: 756
Threads: 31
Joined: Aug 2010
No, I believe that I brought it up. And it was a comment on how I used the calculator. I already understood that we would not be seeing this in the current implementation. This was more than anything a future wish list to make the next generation all that it can be and so I mentioned the two features that I miss most from the HP-41.
It looks like we might get a partial implementation of one of those features and that is great but I didn't intend to start a battle over this. Being a developer myself I have heard more often than I care to count how "easy" something would be to implements without the requester having any idea about the internal complexity. My favorite (not exactly the same scenario) was when a UI "expert" told me he did not like a screen layout and that I should change it. When I asked him what he wanted he said "Just change it and I'll let you know if I like it". I threw him out of my office!
Cheers,
-Marwan
Posts: 756
Threads: 31
Joined: Aug 2010
Hi Paul,
I am not suggesting it is easy and I understand that we won't see this in the WP-34S. My comments are for the future. BTW, SKIP/BACK is what I meant when I mentioned in an earlier posting that at least the WP-34S provides alternatives that (somewhat) solve the problem.
Cheers,
-Marwan
Posts: 114
Threads: 3
Joined: Sep 2010
I say keep moving forward and create a new layout.
The overlay is only obsolete if a person wants the new firmware, which some may not. Some are/were happy as is. You also gave warning about a potential change over a week ago, maybe even longer, so this is not a huge suprise.
Posts: 372
Threads: 42
Joined: Mar 2011
I'd say, don't stop new ideas just because there are a few overlays around.
Who flashed at HHC and doesn't have a cable will be unable to reflash the calculator anyway. Maybe Eric could stock a few of the old layouts as well as the new ones; so who has the cable and wants to be up-to-date can buy the new layout, while the others can order the older version.
This seems to me much less trouble than maintaining two separate firmwares. And buying a new overlay every so often isn't a huge deal, they're rather cheap anyway...
Cristian
▼
Posts: 14
Threads: 2
Joined: Sep 2011
Since Gene was kind enough to offer me a cable, I'll offer to reflash anyone's calculator for the cost of postage.
Posts: 112
Threads: 9
Joined: Jan 2011
Well, this is a developing project, so course corrections like this are expected. I think maintaining multiple versions of the firmware is a bad idea. It is hard enough for the 34S 'Trinity' to spend the time that they do on this project. Asking for multiple versions is a a burden on their free time.
I am wondering if it is possible for Eric Rechlin to create an 'update package' for those with the current layout. It would include new key labels for those keys where the h-shifted function have changed, and small labels to be placed on the existing overlay for places where the f- and g-shifted functions have changed. This would limit the cost to existing users in migrating to the new layout. New users could then purchase the full overlay kit from him.
In the end though, I think we all have to realize that the Trinity has spent more time and money than any of us on this. I am fully willing to spend another $5 on an overlay.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
Changing the keyboard layout is a lot of work, so I'm not keen on it except there are very good reasons to do so. Here are some points:
- Walter needs to provide the actual layout in a form suitable for the manual: non-trivial mental work to get it consistent.
- The layout has to be applied to the three BMP graphics for the emulator: tedious pixelwork.
- Eric has to the same on his overlay file: even more tedious pixelwork.
- The keyboard driver has to be rewritten to accommodate the new layout: non-trivial programming exercise.
I've a few more corrections in mind than what we have come up with until now, so I assume there will be discussions ahead. I vote for not changing the layout until this is all settled. Let's call it V3 then!
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
Changes to the keyboard will be fairly painful for those of us who have keyboards with the current layout. (I've ordered two additional overlays myself. Why is everyone doing that?) Nonetheless, WP34S is in beta. If a consensus of the developers emerges around changing the layout, in consultation with the user community, then the pain of upgrading shouldn't stand in the way.
I think it's amusing how you've opened Pandora's Box a little, Marcus. Putting the keyboard layout in play is going to be fun to watch. But this is a great exercise now. The real machine has been in tester's hands for a while. We have experience of how the actual layout works. The discussion around changing the layout will be informed by that experience. The result ought to be solid improvement to the scheme.
Regardless, changes like this shouldn't be undertaken lightly. As the tester community grows, so too will the pain of updating the keyboard layout. At some point you should declare the layout to be out of beta, even if the calculator itself stays in a testing phase. That means that trying to get the best possible layout now is really important. Taking it slow and getting it right is the correct approach, in my opinion. A long lead time will reduce the impact on Eric too. I don't know how many overlays he has in current production now.
▼
Posts: 250
Threads: 14
Joined: May 2007
Quote:
I don't know how many overlays he has in current production now.
About 60 went out to the first beta testers in June.
Based on feedback, I made a bunch of minor changes and made another 50 for HHC in September.
After HHC, I made another 75, and of those 75 I have fewer than 10 left.
Right now I don't know if I should make a bunch more or hold off until any changes are decided upon.
Eric
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
I recommend you wait a bit. The design department is working, but I won't finish the layout on a train ride ;-) Just rely on our usual speed ...
Walter
Edit: just realized I'll arrive about right to watch a nice football match of our national team :-) And there's more to come ...
Edited: 7 Oct 2011, 2:40 p.m. after one or more responses were posted
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
Quote:
Just rely on our usual speed ...
I wish you would consider taking your time with your decisions. There's a lot of user experience you could capture that might help optimise and stabilize the layout going forward.
Posts: 250
Threads: 14
Joined: May 2007
Assuming the layout changes are minor, I'd be willing to send out a "keyboard patch kit" to anywhere in the world for $2 (and add $1 for each extra patch kit desired).
I'm assuming no primary functions would change, but if they do, or if any [h] shifted functions change, it will be very easy to fix by just removing the key sticker and putting a new one on.
If [f] or [g] shifted functions change, the easiest solution would be to just apply a small sticker on top of the existing overlay. Not perfect, but it beats trying to apply a whole new one.
Eric
▼
Posts: 112
Threads: 9
Joined: Jan 2011
Wow! Now that is service!
Posts: 151
Threads: 8
Joined: Oct 2009
I'm delighted with both the progress of the '34S and the deliberation shown in potential key changes. My only concerns about that have been:
1) Can Eric keep up with the demand if we all want new overlays?
2) Can existing overlays be removed from the 20b and 30b to allow a clean replacement with a new overlay?
I've not had to remove my overlay - it looks nearly as good as when I put it on months ago. If it can be removed cleanly, I see no problem with replacing it.
Go, team! We're cheering you on...
Posts: 27
Threads: 2
Joined: Aug 2011
I would support changing Last X to a primary or shifted key.
Maybe remove the dedicated convert key?
Also I would have the key for scrolling binary numbers left and right
in the display be two keys using the same shift key, as it is now using two different shift keys is very non intuitive.
(another thing that doesn't have anything to do with the layout, I would like base two numbers to only display 8 bits at a time, scrolling a binary number when 12 bits is displayed means it's impossible to quickly see which byte you are looking at)
As for removing ALL, FIX, SCI, and ENG from dedicated keys, I think
a display menu is a good idea. I like how the 35s does it where you can jump to a menu item with the number keys: Display 1 => Fix, Display 2 => Sci, etc.
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Just two comments: - Any proposals of DISP menus "how the 35s does" won't work due to the excellent display of the 20b/30b ;-/ Did we mention already this is our favourite piece of hardware?
- The odds for a label "Last x" appearing are very low for the reasons explained by Gene and others.
Walter
▼
Posts: 1,619
Threads: 147
Joined: May 2006
Quote:
The odds for a label "Last x" appearing are very low for the reasons explained by Gene and others.
Perhaps I missed this explanation. I have not read a single argument for FILL over LASTx.
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Well, LASTx is accessible via RCL L already - only two keystrokes. That's the best you can get since it won't become a primary function ever. FILL is two keystrokes now, while the alternatives - 3 or 7 times ENTER - need more work. Sufficient?
Walter
Posts: 372
Threads: 42
Joined: Mar 2011
Quote:
(another thing that doesn't have anything to do with the layout, I would like base two numbers to only display 8 bits at a time, scrolling a binary number when 12 bits is displayed means it's impossible to quickly see which byte you are looking at)
I second that! :)
Cristian
Posts: 875
Threads: 37
Joined: Jul 2005
We seem to be rehashing a lot of the discussion about key labels and functions that we had last spring. For the moment, why not keep it simple? Put the MATRIX menu where PSE is, and put PSE in the P.FCN menu. For now, everyone can just remember this change. If it "sticks", at some point Eric can send out new labels for the 0 key.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
Jeff, there are a few more inconsistencies which should be attacked. Some have been mentioned here such as having the windowing functions for long integers on different shift keys isn't optimal. Putting OFF on h-EXIT is another consideration. And I never understood why ATOI and ITOA are on the keyboard (riddle: where?).
Posts: 4,587
Threads: 105
Joined: Jul 2005
MATRIX goes on h-shifted '*' and pushes STATUS to h-shifted '.'
SHOW and OFF swapped as discussed earlier.
Put DECM on the keyboard due to the known H.d discussions here. H.d becomes H thus.
Introduce a catalog CLEAR in consequence.
Walter
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
I like the fact that the changes are all on the h plane. That makes it easy for Eric to ship patch kits to owners of the existing overlays, as he suggested.
Forgive my ignorance of previous discussion on this topic, but why wouldn't DECM be better in the MODE menu?
edit: To be CLEAR, I think that menu makes perfect sense. Perhaps you could do something else with the space?
Edited: 7 Oct 2011, 5:10 p.m.
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Quote:
why wouldn't DECM be better in the MODE menu?
Because of people unable to find it - and having all other important modes on the keyboard.
Posts: 1,545
Threads: 168
Joined: Jul 2005
A clear menu is fine, but perhaps CLX should be g backspace?
I'm guessing that CLX would be used more than CL Sigma.
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Thanks - put it in my new proposal already.
Posts: 185
Threads: 20
Joined: Apr 2007
Is there any reason the shift keys do not themselves have shifted functions?
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Please look at page 27/102 of the current manual.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
▼
Posts: 429
Threads: 31
Joined: Jul 2011
If each one canceled only itself, could they then have shifted functions? Like f and h shift for g, g and h shift for f and finally f and g shift for h.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
f cancels / replaces g, etc. This is useful if you have accidentally pressed the wrong shift. Don't tell me you never do! :-)
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
I think what they are suggesting is:
f pressed incorrectly is cancelled by pressing f again.
g pressed incorrectly is cancelled by pressing g again.
f pressed followed by g would execute whatever the f-shifted function of g was.
In other words, yes, people press shift keys, even the wrong one from time to time. But the fix is to press the wrongly pressed shift key again to turn it off.
▼
Posts: 429
Threads: 31
Joined: Jul 2011
Posts: 185
Threads: 20
Joined: Apr 2007
Quote:
f cancels / replaces g, etc. This is useful if you have accidentally pressed the wrong shift. Don't tell me you never do! :-)
Yes but what if you press a shift key by accident when you want an unshifted function?
There must be a way to clear the shift key. The obvious way to do that is to press the same shift key again.
Shift keys have historically not had shifted functions. But is that a paradigm that, dare I say it, could be shifted?
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
In the past, HP's normal way of canceling the shift key on many models was to press the "prefix" shifted function, which cleared the prefix key.
This had the added benefit of showing the mantissa in the display.
I believe the 12c f and g keys cancel each other, but the prefix clear is the way to clear both.
That said, it might be nice to consider having some shifted functions on the other shift keys.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
So we could have a g-shifted and an h-shifted function on f, an f-shifted and an h-shifted function on g and an f-shifted and a g-shifted function on h. We might relocate -> to both f and g as their g- and f-shifted function respectively. The conversions would then be called with f+g+DEG/RAD/GRAD respectively g+f+H.MS/H.d. CONV might then go to h+f and some other catalog(ue) on h+g.
What to put on where is now ->?
I'd like Walter, our chief design officer, to comment on this.
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
It's just an idea. The shift keys are very lonely on that row with no shifted friends. :-)
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
So we could have a g-shifted and an h-shifted function on f, an f-shifted and an h-shifted function on g and an f-shifted and a g-shifted function on h.
Oh my god, it seems you want to create the most complicated calculator keyboard ever! :-(
Have you thought about how the 4 labels for these f/g/h keys would look then? For each of the 3 keys one label must be omitted (the one of it's own function), and this would be on a different place for each key.
Could you please make a SVN build with the latest changes before such keyboard 'deformations' are done? This will then certainly be the last version I'm using ...
Franz
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
Franz, I plan to create a stable build that matches the current layout and a branch for future development.
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
Franz, I plan to create a stable build that matches the current layout and a branch for future development.
That's good to hear, Marcus! :-)
As for the f/g/h combinations:
The maximum I could imagine would be h-shifted functions for f and g (but not any/all other combinations) - this would make 2 new green labels for f and g which could either be used for 2 catalogs or to put the -> and CPX to these [h][f] and [h][g] positions: with this last method you could extend the 4 A-D user keys to the usual 6 A-F, which would be very comfortable for programs with more than 4 functions keys (just thinking of TVM or TRIGON for example).
Franz
Edited: 8 Oct 2011, 3:16 p.m.
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Don't worry, "such keyboard 'deformations'" won't happen as long as I'm responsible for the UI :-)
Walter
▼
Posts: 429
Threads: 31
Joined: Jul 2011
It's a pity you judge this to be a deformation. I find it very appealing. With six new locations on the keyboard, most shuffeling around of other functions could be avoided.
Posts: 528
Threads: 40
Joined: Dec 2008
Quote:
Have you thought about how the 4 labels for these f/g/h keys would look then? For each of the 3 keys one label must be omitted (the one of it's own function), and this would be on a different place for each key.
Actually, you just have to replace the sticky keyboard overlay with a spiral-bound flip chart that attaches to the top of the calculator. Each sheet corresponds to one of the 27 possible key planes (f, g, and h keys unpressed, pressed, or pressed and held).
It would come with a stylus to reach through the half-inch deep hole created by the chart when you actually need to PRESS a key. Oh wait, you'd need three styluses (styli?) for the [f](hold)[g](hold)[h](hold) plane....
:)
▼
Posts: 372
Threads: 42
Joined: Mar 2011
Quote:
Oh wait, you'd need three styluses (styli?) for the [f](hold)[g](hold)[h](hold) plane....
Nah... just put the planes that need held keys at the bottom, so that the keys stick well out of the holes! :)
Cristian
Posts: 3,229
Threads: 42
Joined: Jul 2006
The maximisation of functions on a keyboard occurs when half the keys are shifts -- I'm discounting shifted shift functionality here -- in that case every key should be a shift which is silly.
- Pauli
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
We certainly don't want a shifty calculator. :)
Posts: 528
Threads: 40
Joined: Dec 2008
Responding to the thread so far:
I agree that RCL L is fine in place of LASTx. Yes it's a little different but it's intuitive and the same number of keystrokes.
I think we can definitely move ./, to a menu. Perhaps more than anything else, that function is likely to be used once when the user gets their calculator and never ever again.
I agree that || is so specialized that it should move off the keyboard. I completely understand its importance to electrical engineering, but functions like this are the reason why A-D are assignable. Further, || is easily misunderstood as |x| for the beginner. At least it was for this beginner.... :)
If you change the keyboard, I think you should increase the revision number to 2.2. Eric could put the rev number on the labels and this would help people keep straight which keyboard layout goes with which software version.
I think PSE could move to P.FCN if the space is needed.
I'd leave "H.d" as the name of the command at [f] [RCL]. "H" is unintuitive. Also, with FIX/SCI/ENG automatically changing to DECM, I don't think we need DECM on the keyboard explicitly.
Finally, let me say NICE JOB on the keyboard layout in general. This discussion gave me a chance to really look it over, and, given the huge amount of functionality involved, it's really well done.
One last comment for Eric: in dim light, I have trouble distinguishing between the blue and green on the keyboard overlay (I have one with the clearcoat if that makes a difference). I'd prefer a brighter green if it's possible.
Dave
▼
Posts: 1,619
Threads: 147
Joined: May 2006
Quote:
One last comment for Eric: in dim light, I have trouble distinguishing between the blue and green on the keyboard overlay (I have one with the clearcoat if that makes a difference). I'd prefer a brighter green if it's possible.
I'll second that. Given that all the green labels are on sloped keys I'd vote to change h to white and the labels to white. This is inline with the 34C, however the 34C had a black h with white keys, but the concept was the same.
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
How would that work with the white main function labels? I wonder if the machine would look more cluttered that way?
edit: I agree the green labels are too dim. A light green might be better.
Edited: 7 Oct 2011, 8:55 p.m.
▼
Posts: 1,619
Threads: 147
Joined: May 2006
Like this:
Just reverse the black/white.
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
Those keys have very steep fronts. For me, it's quite easy to separately scan the key tops and fronts. With the shallower angle of the (30|20)b keys, I think it would look more muddled. I don't actually know, since I haven't seen an example of a 34S with this scheme. It might be pretty subjective whether light green or white would work better. From a style point of view, I suspect the green would visually clash with the other colors. Of course, if you are looking for good contrast, that might be just the ticket.
I'm going to have a look for template images to try out some of these combinations.
Posts: 1,830
Threads: 113
Joined: Aug 2005
The atrocious (esthetically, in my opinion) lime green on the canonical layout image strikes me as just fine for contrast's sake. Here I've replaced that green with white. This picture lacks a third dimension to show how the front slope might aid you in distinguishing the primary functions from the h-shifted ones. I think the result is pretty jumbled nonetheless. The fact that the alpha plane is off white adds to the problem.
edit: How's this?
I wouldn't mind if the alpha plane were bright green, either. The off white is dim in Eric's overlays, as well as in the template image.
Edited: 8 Oct 2011, 1:31 a.m.
▼
Posts: 764
Threads: 118
Joined: Aug 2007
I think light green would be best - to distinguish the key's primary function and h function.
Posts: 429
Threads: 31
Joined: Jul 2011
Quote:
Edit: Having read the answers so far I'm leaning towards changing the keyboard, but not in a hurry. Let's discuss the proposed changes with a graphic from Walter in place and we go on from there.
I think I will stick to the old keyboard layout and therefor to the then old software. My wish would be to have the corresponding firmware stable and bugs free and maybe in that status marked as "WP-34S I" and "final" with its own download repository.
Changes to the layout and the firmware from there on could be marked "WP-34s II" with kind of a fresh start, appealing to everyone who wants to go on and have changes made.
This is how I, as a layman, imagine programmers do things in such cases. If that is not so, I apologize. In this case I would be happy to just get a notification when the last firmware version compatible with the old keyboard layout is published. Thank you in advance.
Edited: 8 Oct 2011, 7:06 a.m.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
SVN supports branches and the idea isn't too bad to fix the current V2.2 and only get rid of bugs here.
Let's start with V2.3 or even V3 with all the good ideas in place.
▼
Posts: 63
Threads: 13
Joined: Sep 2011
Should I hold off on buying new keyboard templates in anticipation of a new layout?
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
Posts: 1,830
Threads: 113
Joined: Aug 2005
Problems I see with the current color scheme:
- Off white alpha labels are hard to see.
- Bright green labels somehow end up dim on Eric's overlays.
- I don't like the green from an esthetic point of view.
This scheme replaces the green with an orange color that has pretty good contrast on the PNG. The green color is used for the alpha labels. This reduces the glare from the green while enhancing visibility of the alpha labels.
- Caveat: I have no idea how this would look on a real overlay
- Caveat: Using orange here would require extensive changes to the example images in the manual.
▼
Posts: 1,253
Threads: 117
Joined: Nov 2005
love it, a clear improvement.
Posts: 82
Threads: 8
Joined: Nov 2009
While I think orange may be one of the very few other colors that work well, I also think it's getting to be too many colors. Personally I rather like the green and don't have a problem with it.
I'm more curious to get feedback from users who have partial or total colorblindness as to their preferences.
Posts: 372
Threads: 42
Joined: Mar 2011
I don't know, I don't have a problem with the green - I don't know why, but I think it's perfectly legible. It's less bright than the white labels of course, but I like that because this way, the primary (white) labels stand out more... Or maybe I'm just used to it.
Cristian
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
The main problems this is designed to fix are the legibility of the alpha plane, and a brightening of the h plane. Aside from esthetics, I'm worried that Eric's printing system may not be able to produce a bright enough green to give good contrast. If you look at his overlays, the green is pretty dim. Despite that, his green is easier to see than the gray of the current alpha plane.
I think legibility is primary and esthetics are secondary. If Eric can produce a brighter green, then I have no problem sticking with it for the h plane. That leaves the alpha labels. Perhaps we can use orange for those, assuming Eric can produce a more legible overlay with that color.
Another consideration ought to be that the alpha plane is on the main overlay. That isn't "patchable" like the h plane is. Still, a wholesale color change of the h plane, either to orange or a brighter green, would demand a complete replacement of the key cap labels anyway. Adding the base sticker to the mix wouldn't be that much extra effort.
▼
Posts: 250
Threads: 14
Joined: May 2007
I am open to color changes, if Walter/Pauli/Marcus agree on a new color scheme.
I might be able to brighten the green a bit, but I can't brighten it a lot due to limitations in the media and ink. All I can really do is make it whiter. The vinyl isn't a particularly bright white, and my printer's ink isn't as bright as what some printers can produce (perhaps because of its use of pigment instead of dye?).
Eric
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
That's what I feared. Do you think you could produce a bright orange?
▼
Posts: 250
Threads: 14
Joined: May 2007
Nothing will be very bright. I think the way it is now is still pretty legible, however; you'll see when you get your overlays, probably Monday.
Eric
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
Except for the alpha labels, I find the overlay colors to be bright enough. The green H plane is only a problem in dim light. I actually have trouble with ordinary text under those conditions, so I know how to remedy that. :) I've voted for your overlays with my dollars twice now. Thank you for offering them.
Posts: 1,830
Threads: 113
Joined: Aug 2005
The vinyl is off-white? I wonder what you could with that as the background color.
Posts: 4,587
Threads: 105
Joined: Jul 2005
As an alternative to a brighter green (please see the emulator :-) ) also a clear red would be viable IMO. But keep in mind that's not discussed yet within the team.
The alpha letters will stay dimmed - it's a calculator, not a typewriter, else it would feature a totally different layout.
Walter
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
The problem is that on a screen the colors come out significantly different than on a printer to warrant this discussion. The former dark read on the alpha characters was almost invisible on the first overlays. I vote for a backlit keyboard ;-).
Edit: Typo.
Edited: 9 Oct 2011, 11:40 a.m.
Posts: 1,830
Threads: 113
Joined: Aug 2005
I don't want to use the 34S as a word processor, I just want to enter three character alpha labels in my XEQ, GTO and LBL instructions, as documented in the manual.
Posts: 764
Threads: 118
Joined: Aug 2007
What about the alpha characters being black letters on white boxes? This would help distinguish the alpha characters from the rest of the functions.
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
Walter doesn't want them emphasized, and I can understand that. I just think they should be visible. :)
edit:typo
Edited: 11 Oct 2011, 2:20 p.m.
Posts: 756
Threads: 31
Joined: Aug 2010
Posts: 79
Threads: 5
Joined: Jun 2007
I like the new overlay, and eventually plan to buy one as soon as I have enough free time to actually start playing with a WP 34S.
I don't know if this has been discussed before, and this is a really minor point, but the fact that the "2, 8, 10, 16" base indicators are numeric bothers me a little. I'd prefer to have "BIN, OCT, DEC, HEX".
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Space is very tight up there, so seven letters below a key would require a very tiny font :-/
Posts: 3,283
Threads: 104
Joined: Jul 2005
It looks like we have three options:
- We leave the layout as is and live with its shortcomings. This would save us from relabeling and relearning the keyboard. It would provide a basis for making the software stable before we move on to other things.
- We make only very minor changes such as moving L.R. to a menu to make room for the MATRIX menu. This is so minor that it can be remembered easily or changed with a single label. We may swap SHOW and OFF in the process but not more.
- We make major changes, starting with Walter's suggestions and throwing in whatever the team and its user base thinks will make the layout better. In order not to disappoint those who do not want to change we would need to split the development to be able to fix bugs in the present version.
Please vote!
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
I would vote for point 1 or 2 (I don't see much difference between them):
Of course there should be an additional MATRIX menu (and L.R is indeed a good place), but I don't even see the need for changing SHOW and OFF!?
One thing is clear: you can never make everybody happy!
Take 50 WP34s users and you'l get 50 different keyboard layout preferences. ;-)
Of course I would also like to see a lot of keyboard changes (there are many functions I won't never need and many useful functions that I miss), but you'll never get all users "under one hat" (as we say in German ;-)), and I can really live with the current layout.
And IMO other changes (in supported functions or operations) would be much more important than moving around keyboard labels - but that's another thing of course ... ;-)
Franz
Edited: 9 Oct 2011, 8:09 a.m.
Posts: 429
Threads: 31
Joined: Jul 2011
1 and 2 basically mean the project has come to its end. 3 means the fun goes on. So my vote goes to 3.
My reasoning goes like this: I don't really need a working, sophisticated calculator in my every day life - I own several that are up to the task, but I find the process of thinking, trying, flashing and all that stuff to be fun. If once the 34s will be perfected it will be boring! ;)
In practice, I will flash a 30b with the last and stable version, put Eric's labels on it and then have a 20b ready for experimenting with what ever comes next!
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
1 and 2 basically mean the project has come to its end. 3 means the fun goes on. So my vote goes to 3.
I don't agree. If "fun goes on" only means shuffling around the keyboard labels (as point 3 suggests), then it's just a waste of time IMO.
"fun goes on" would require real improvements of the WP34s functionality, but as Pauli himself has mentioned yesterday this will certainly not happen (look at his remark about and END statement and local labels).
And so I would indeed say that the project has come to its end (despite of fixing any bugs which may still exist).
▼
Posts: 52
Threads: 2
Joined: Sep 2011
On the other hand: If the functionality comes to an end (we filled up all flash space, no additional functions can be added anymore) why not look back and re-think how the layout could be tweaked and re-arranged to make it "perfect" for the supported function-set?
I guess the layout changed organically over the time and now contains a lot of compromises, so it would not be that bad to rethink them in face of the current function-set?
I would also vote for 3 - but I don't own a 34S as of yet, so my vote should be discarded I guess :-)
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
On the other hand: If the functionality comes to an end (we filled up all flash space, no additional functions can be added anymore) why not look back and re-think how the layout could be tweaked and re-arranged to make it "perfect" for the supported function-set?
I guess the layout changed organically over the time and now contains a lot of compromises, so it would not be that bad to rethink them in face of the current function-set?
Yes, you're right, but as I already said: you'll never make all users happy - that's the main problem with making a "perfect" layout. :-(
Posts: 3,283
Threads: 104
Joined: Jul 2005
One of the things that fascinate me about WP 34S are the shortcomings of the hardware: So little RAM, so much to put in there. It has been a real challenge in the past few months to push the limits farther with each new release. The typical sequence of events was:
"Can we implement this and that?"
"No, I doesn't fit."
"I've done it, together with some other improvements."
:-)
I would really miss this if we had a platform with abundant resources. Of course we would face other challenges such as adding network support and real time 3D graphics... ;-)
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
Of course we would face other challenges such as adding network support and real time 3D graphics... ;-)
Yes, and please don't forget to implement Dolby Surround, too! ;-)
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
Quad core would be nice. :) Oh, and keep the long battery life whatever you do!
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
Quad core would be nice. :)
It seems we're going to create a super-calculator - at least in our imagination ... ;-)
Posts: 3,229
Threads: 42
Joined: Jul 2006
Quote: "fun goes on" would require real improvements of the WP34s functionality, but as Pauli himself has mentioned yesterday this will certainly not happen (look at his remark about and END statement and local labels).
Don't think this sad thought please. We are planning a 43S that will address these issues.
So, even though the the 34S might be approaching complete, that doesn't mean we'll stop.
- Pauli
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
Quote:
We are planning a 43S that will address these issues.
Do you have hardware in mind? "Just curious" understates my interest by some distance. :)
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
Posts: 4,587
Threads: 105
Joined: Jul 2005
Yes we have - but we won't let it out yet ;-)
Posts: 372
Threads: 42
Joined: Mar 2011
My vote would be closer to "2.5" - i.e. major changes scare me a little, but a few, well-thought changes are ok. After all I've been using this calc for just a few months, I think I still have the flexibility to re-learn a few key assignment... especially if there's a reason to change. I totally agree on adding the Matrix menu, even though I never use matrices, and on swapping Show and Off - I'm used to the way they are now, but I remember at first I really wanted OFF to be on the right-most shift.
The point is: the fact that we're used to this layout now, shouldn't prevent us from improving it.
Cristian
Posts: 28
Threads: 6
Joined: Sep 2011
Marcus,
From your proposition, I understand that the user mode suggested earlier would only be eventually considered in option 3.
If that's right, my preference would be for option 3.
If not, I would kindly ask it to be added to the "current" layout, as I believe it would make things easier for different "breeds" of users.
That would make the process a slightly different option 2, I guess, unless user mode can be fitted in a "1+epsilon" option (added function without layout change).
Sorry for not strictly adhering to your offer!
Etienne
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
User mode should be independent of the keyboard layout. It will certainly rely on row/column codes which do not change. I'm a friend of the proposal with special global labels even if that would cost a few more program steps then local labels or a special KEY instruction. The label search function would need no change and the key assignment could be easily put in a library region. Rest the necessary indicator and a key position to toggle the mode. Another problem would be that some functions would be eternally hidden in user mode because we typically do not repeat functions which are on the keyboard in any catalog(ue)s.
Posts: 1,830
Threads: 113
Joined: Aug 2005
I think that as the installed base grows, wholesale keyboard changes will become more and more painful. At the same time there is now lots of experience among beta testers using the current layout. If you want to leverage feedback from your users, now would be a good time to do that.
Personally I can live with most of the suggestions made here. My personal concern is legibility of the actual, as opposed to conceptual keyboard. My eyes are almost 56 years old and I have trouble picking out letters with the current overlays. I should hasten to add that I think Eric's overlays are wonderful, and make the WP-34S usable. I wouldn't own one without them.
The color scheme is actually within my power to change, in principle at least. If the project wants to keep the alpha plane dim, then that's fine. I can try to pursue a better solution for my individual circumstances.
Edited: 9 Oct 2011, 11:48 a.m.
Posts: 875
Threads: 37
Joined: Jul 2005
Preferred: 2 (except leave SHOW and OFF alone. This change would require a keyboard plane change, which will either require a sticker on the overlay, or a whole new overlay.)
Second choice: 1
|