WP34S yet another newbie layout



#52

Well just about every man and his dog has proposed a different keyboard layout, so I thought I'd have a stab at it too! This is a *really* rough mockup just to throw some ideas out there. Don't expect anyone to change any code; can do all that myself if needed. Would like some comments, though, on what I've gotten wrong as far as groupings go! WIP.

The first idea here is to try and create a "cursor" group in the top right corner. Assume some future upgrade to navigation (up/down is already used for menus) then having 4 directions might be handy. So I appropriated the CLX as another cursor key,

I haven't really focused on making sure I copied all the functions over; hope I did OK, but it's the basic idea I'm after at the moment.

The second change is, of course, the moving of the function keys to the left edge, stacked vertically, the addition of offset arrows, and the solid colours. I prefer them here, and it makes the big blank space middle of keyboard disappear.

I've moved the R/S top right of numeric block, and the XEQ to the left of that. So the start and stop are next to each other. The bottom row now holds the EEX key which makes more sense because it's involved with number entry. The CPX has had to move to 1st key 2nd row.

The fractional F/G functions are now down next to the . used for fractional entry, creating a new grouping.

I think it's probably a good idea to have a dedicated sigma+ key (with sigma- shifted on that). When you're doing stats you don't' want to have to f-shift every single item entry. Unless that's already catered for with a sticky f-sigma when doing stats :) in which case it's OK as is.

Another thing I'd do -- and that's 'hotkeys'. When you're in a menu, there are probably fairly logical letters for many of the menu items. How about allowing you to press the letter hotkey to select? For example, to set 4-register mode for the stack; press h-MODE then 4. No scrolling through all the options if you know the hotkey. Hotkeys could be displayed alongside the menu items (optionally, say, if you hold enter down... or something).

I couldn't be bothered moving the alphabet around to the right spots. That would need to be reviewed, so ignore that part.

Since I really haven't played with the real thing, yet, I'm sure some of my assumptions are bad. BUT, if everyone can drop their preconceptions and preferences just for a bit... at least this is a novice view uncluttered by previous experience. Just thought I'd throw it out there for comment on the functionality errors in this design.

Cheers
A

Edit: Haters gonna hate. I contribute to communities and actually make stuff. Move on if you're bored.

I have removed the 2/8/10/16 and replaced with a BASE menu. Idea is you'd press g-BASE and then 2 or B, or 8 or O, or T, or H... or select manualy with up/down from the base menu. BASE on menu allows addition of further arbitrary base support later and also frees up keyspace.

I have consolidated DEG/RAD/GRAD into a new menu DRG.

I moved the e^x and LN back into the appropriate row grouping.

Moved the DSE/ISG to the XEQ key, as it's part of programming group which seems better placed near XEQ R/S LBL/RTN.


BAD IDEAS: DISCARDED BECAUSE I WAS JUST PLAIN WRONG...

* Moving R^ and Rdown to the UP/DOWN arrow keys. Used by forward/back step so key not avaialble.

* The R<>P key in the official overlay is incorrectly coloured. The yellow should be (the R and the arrow pointing to the P). The blue should be (the P and the arrow pointing to the R). The arrows are the wrong colour and mirrored. As it is, it makes NO SENSE at all.. I've fixed that in the image shown here.


Edited: 20 June 2012, 5:18 a.m. after one or more responses were posted


#53

Quote:
Other changes I'd make would be to use the up-arrow and down-arrow as overloaded roll up and roll down keys, and free-up the roll key for other use. When menus are active, the up/down would be menu stuff. When not, then it's roll.

Where are single step and back step? Both function in run mode. These change ruins them.


You've also spread some functions out. Combinations and permutations are no longer near the statistical functions. e^x and LN isn't near the other exponential and logarithmic functions.


I'm sure they'll be other comments, layout design is something I'm rather poor at.


- Pauli


#54

Quote:
Where are single step and back step? Both function in run mode. These change ruins them.

They're still on the up and down arrows. Am I misunderstanding the question? I haven't' changed them....? Seems even better as they're now close to the XEQ, R/S key creating a grouping.

Quote:
You've also spread some functions out. Combinations and permutations are no longer near the statistical functions. e^x and LN isn't near the other exponential and logarithmic functions.

You're right, and this should be restored. I was mainly working on the white/top keys. I didn't purposefully move the shifted keys and if there are logical groupings for those, then they can be repaired. I'll fix that up shortly.

The main concept of 'cursor keys' and moving the shift keys is the bit I was trying to get across. So, ignoring all but the white keytops, for now... :)

Thanks for your comments :)


#55

If, as you wrote, roll up and roll down are overloaded on the up and down arrow keys; then it is impossible for single step and back step to also be there.


- Pauli


#56

Quote:
If, as you wrote, roll up and roll down are overloaded on the up and down arrow keys; then it is impossible for single step and back step to also be there.

- Pauli


Gotcha. So I can't do that. Removed the suggestion from original post.
Thanks.

Edited: 20 June 2012, 2:40 a.m.

#57

BOOORING!!!

#58

Quote:
The R<>P key in the official overlay is incorrectly coloured. The yellow should be (the R and the arrow pointing to the P). The blue should be (the P and the arrow pointing to the R). The arrows are the wrong colour and mirrored. As it is, it makes NO SENSE at all.. I've fixed that in the image shown here.

Sorry to say that, but you're wrong! ;-)

The yellow [f] function converts (from Polar) to Rectangular and the blue [g] converts (from Rectangular) to Polar, hence the yellow R< and the blue >P are both correct.

Franz

Edited: 20 June 2012, 4:38 a.m.


#59

Quote:
Sorry to say that, but you're wrong! ;-)

Don't mind being wrong :) Thanks!
I just assumed.

I know I'm pottering around and not really contributing anything yet, but I enjoy layout and fonts and design and especially usability. I designed and programmed the entire UI on the uWatch, so I do have some experience.

Can't wait to get my hands on the calculators (ordered), overlays(ordered) and programming cable(ordered). Already have the source code and been browsing. But, of course I'm working blind and guessing a lot of stuff at the moment.

All I can say is that I'm more likely to follow through on these half-assed ideas than your average newbie poster, as I've done it before. I don't care if nobody uses/wants/likes what I do, but having people show me where I am wrong about stuff is great.

If I end up doing my very own design and I'm the *only one* who likes or uses it, well that should put nobody's nose out of joint now should it. But maybe some of my suggestions might be useful, who knows.


#60

Quote:
But, of course I'm working blind and guessing a lot of stuff at the moment.

Why this? Why don't you just use the WP34s emulator? It's working perfectly and so you could test every function of the real calc - no need to 'guess' anything. ;-)

BTW, about your other suggestion:

Quote:
Another thing I'd do -- and that's 'hotkeys'. When you're in a menu, there are probably fairly logical letters for many of the menu items. How about allowing you to press the letter hotkey to select?

This is already implemented. In every menu you just can press any letter key and this jumps immediately to the first command in the menu with this letter (even further letters work).

But '4' for a 4-level stack won't work, because the command is SSIZE4, so you would have to press 'S' (twice) in the MODE menu to get to SSIZE.

#61

Quote:

Quote:
Another thing I'd do -- and that's 'hotkeys'. When you're in a menu, there are probably fairly logical letters for many of the menu items. How about allowing you to press the letter hotkey to select?

This is already implemented. In every menu you just can press any letter key and this jumps immediately to the first command in the menu with this letter (even further letters work).

But '4' for a 4-level stack won't work, because the command is SSIZE4, so you would have to press 'S' (twice) in the MODE menu to get to SSIZE.


The hotkey(s) for any menu selection doesn't have to correspond to the first letter of the menu item. It just has to be a logical/memorable key or keys. Could be a number of keys each select a menu item (e.g., 2 or B to select binary in BASE menu). 4 is very memorable/usable for SSIZE4. No reason at all the code can't cope with that.


#62

Quote:
No reason at all the code can't cope with that.

One reason comes to mind immediately: space.

Flash is almost full.


I'm sure there are space saving measure we haven't thought of available still.


- Pauli

#63

Quote:
The hotkey(s) for any menu selection doesn't have to correspond to the first letter of the menu item. It just has to be a logical/memorable key or keys. Could be a number of keys each select a menu item (e.g., 2 or B to select binary in BASE menu). 4 is very memorable/usable for SSIZE4. No reason at all the code can't cope with that.

Yes, I understand what you mean with your 'hotkeys', but this would require quite a lot of additional storage if you implement such a hotkey for every function. And certainly this would start again lots of discussions, because everyone would want his own hotkeys. ;-)

For me this 'quick-selection' of functions with the first letter is comfortable enough.

Now about a few other points of your suggestions:

I don't really see any need for a true cursor 'block', because we don't have anything in the WP34s which would need a <- or -> cursor (no menus like the HP42s).

But what I don't like at all is your arrangement of these 4 cursor keys - this 2x2 block looks really ugly.

If there is a need for a cursor block then it should definitely be arranged like the following 2 ways:

   ^                       ^
< > or at least < v > as on PC keyboards
v

Also putting f,g,h in the left column is nothing that I would prefer over the current horizontal arrangement, but of course that's just a matter of taste.

Your idea of putting 2,8,10,16 (and maybe even DEG,RAD,GRAD) into a separate menu is not that bad though, and it would free some key positions for other useful functions.


Edited: 20 June 2012, 6:01 a.m.


#64

A few comments about things you might have overlooked:

Putting DRG in a menu makes the ->DEG, ->RAD and ->GRAD functions inaccessible. The same holds for the temporary base conversions like ->2, ->16, etc.

Putting a letter on the back arrow will make it impossible to delete text in alpha mode.

You need to check the possible combinations of keys thoroughly before you change the layout. We learned it the hard way when we instantiated our first keyboards.


#65

Quote:
A few comments about things you might have overlooked:

Well Marcus, I guess this is rather directed to Andrew but not to me!?
Quote:
Putting DRG in a menu makes the ->DEG, ->RAD and ->GRAD functions inaccessible. The same holds for the temporary base conversions like ->2, ->16, etc.

Not really correct - you could either put those conversion functions in this menu too, or you could make them accessible by [->][h][menu] for example, or by [CPX][h][menu] as for Walters 'experts' catalog. Not really confortable but at least possible.
Quote:
Putting a letter on the back arrow will make it impossible to delete text in alpha mode.

I've never made such a suggestion, did I?

Franz

Edited: 20 June 2012, 4:07 p.m.


#66

My post goes to the thread, not the most recent poster. So Andrew is the one I meant to address.

You got the point: We made some attempts to save keystrokes for useful functions. It is certainly possible to address them in a different manner but the usefulness of such changes is worth being discussed.


#67

Quote:
You got the point: We made some attempts to save keystrokes for useful functions. It is certainly possible to address them in a different manner but the usefulness of such changes is worth being discussed.

Yes, and I have to agree that the current keyboard layout is much better IMO than any of the changes I've read here in this thread.

Although I would of course also have some (tiny) suggestions for improving some key assigments ... ;-)

Franz

#68

I thought Dave Jones was responsible for the uWatch.


- Pauli


#69

Quote:
I thought Dave Jones was responsible for the uWatch.

- Pauli


He sure was. Dave did the hardware and initial software. I came on board and...

Rewrite of user interface

new menu system

custom characters

chessboard display system

21 rewrite

stopwatch rewrite, 1/10th second resolution, lap timer

statistics and combinations functions

rewrite of number bases support and display to 64 bit limit

addition of octal base

bit shifting operations

fixed, engineering and scientific display format

SI system units display format

wide number/string display systems

uWatch User Guide

You can check all my contributions in sourceforge.


Edited: 20 June 2012, 5:45 a.m.

#70

Andrew,

Some nice ideas :-) I take your layout as it is right now. If you continue changing it, however, I'd recommend you write a new post per change - else it's difficult to follow this thread.

A few remarks in random order:

  • Prefixes located bottom left are nice. For internal logic, I'd suggest reverting their order: h above g above f. See why?
  • Primary functions: The cursor square is a nice idea. I'd prefer a configuration like a reverse T, however, for logic reasons (< being left of V being left of >, compare HP-48). This would allow for putting CPX back top right, and STO, RCL, Rv returning to their previous locations.
  • More primary functions: EEX should be next to +/- IMHO. And DELETE (back arrow) must be primary, as XEQ and R/S. So now you are lacking space for one primary function - no idea yet where you get it from.
  • You probably don't know about the use of the right arrow key -> in our layout. I guess you didn't look into the manual yet - I recommend you read a bit about the functions you want to remove.
I won't comment on secondary functions yet (not before the primary ones are settled). Happy layouting :-)

Walter


#71

Quote:
Prefixes located bottom left are nice. For internal logic, I'd suggest reverting their order: h above g above f. See why?

Yes, but I thought I'd get way too many complaints. Agree!

Quote:
Primary functions: The cursor square is a nice idea. I'd prefer a configuration like a reverse T, however, for logic reasons (< being left of V being left of >, compare HP-48). This would allow for putting CPX back top right, and STO, RCL, Rv returning to their previous locations.

I kind of pre-empted this with the example shown. Almost what you asked for, so we're on the same page here.

Quote:
More primary functions: EEX should be next to +/- IMHO. And DELETE (back arrow) must be primary, as XEQ and R/S. So now you are lacking space for one primary function - no idea yet where you get it from.

I understand the problem, but I don't understand your grouping of EEX and +/- but will think about that. As to the missing primary function -- yes, unfortunate that delete isn't a right-arrow :) I'll think some more. My first thought is "do we really need A B C D keys as primary functions? I'll RTFM.

Quote:
You probably don't know about the use of the right arrow key -> in our layout. I guess you didn't look into the manual yet - I recommend you read a bit about the functions you want to remove.

Me bad.

Thanks for the feedback. I fear if I do multiple threads even more trolls will emerge. I'll have a think about how to make the various iterations easy to follow. I have had a go at the T-cursor and here's the result...

For those who think the cursor isn't needed now, you're probably right. But it opens up the option for UI redesign. If there's a cursor and it's easy to use, it may improve the whole thing.


Cheers
A


#72

Quote:
For those who think the cursor isn't needed now, you're probably right. But it opens up the option for UI redesign. If there's a cursor and it's easy to use, it may improve the whole thing.

UI redesign? I'd rather say this would need a hardware redesign (a full dotmatrix display).

#73

Quote:

UI redesign? I'd rather say this would need a hardware redesign (a full dotmatrix display).


I have some ideas for the use of left and right arrows. Specifically, useful for display of what I called "wide numbers" on the uWatch UI. Also, the dot-matrix area could scroll left/right as well as having up/down selection.

So, I have reasons to want a cursor.


#74

Quote:
I have some ideas for the use of left and right arrows. Specifically, useful for display of what I called "wide numbers" on the uWatch UI.
Please RTFM before reinventing the wheel.

And why g f h while f g h would look so much better? Any particular reason for Rv being placed left of STO/RCL? Just wanting to understand ...

Happy layouting :-)


#75

Quote:
Please RTFM before reinventing the wheel.

Actually I did. I understand the current wide number display system. It's interesting, no real issues with it and I'm not being critical. But I have some different ideas I'd like to explore. That's a different issue; I can try that privately. The point really is that a cursor *might* be useful for UI stuff... that's all I'm getting at here.

#76

Quote:
And why g f h while f g h would look so much better? Any particular reason for Rv being placed left of STO/RCL? Just wanting to understand ...

In various iterations I've just been juggling the ordering of those buttons. Basically I think the H (green) should be above the f/g (yellow/blue) simply because the decals are in similar positions on the keys themselves. The ordering of the yellow/blue is kind of arbitrary... but since h is on top, possibly better would be h/g/f.

The Rv position could go either side of STO/RCL; this is an artefact of me juggling things about to test layouts and not something I feel strongly about.


Edited: 20 June 2012, 8:28 a.m.

#77

Here's an update, incorporating some of the suggestions from Walter and others. Note I'm only spruiking the top-decals here; the f/g/h functions are all over the place and I'll get to those soon.

I've restored the backspace key to prime position and to "recover" a prime key I've relegated CPX to an f- keypress.

The EEX is moved next to the decimal; makes more sense to me here.

The R/S is now in prime position, top right. It lives with the A B C D key row which also, I understand, start running programs.

The XEQ is now near the ENTER.

Edited: 20 June 2012, 8:38 a.m. after one or more responses were posted


#78

And the CPX function has now gone to the Nirwana???

Edit: ok, I can see it now on [f][+] - really very comfortable! :-(

Sorry, maybe you're calling me now a troll too, but slowly this shuffling around of keys is indeed getting confusing.

And all this useless nonsense just for getting 2 'cursor' keys (left/right) for which there are no functions at all in the WP34s?

I hope all these changes will not happen ...


Edited: 20 June 2012, 8:40 a.m.


#79

Quote:
And the CPX function has now gone to the Nirwana???

Sorry, maybe you're calling me now a troll too, but slowly this shuffling around of keys is indeed getting confusing.

And all this useless nonsense just for getting 2 'cursor' keys (left/right) for which there are no functions at all in the WP34s?

I hope all these changes will not happen ...


A troll is someone who doesn't contribute and simply posts "boooring!". If you're not interested, move on.

I don't think you get the point, but I respect your opinion. I'm not redesigning the keyboard for the existing software/UI. Of course the arrow keys are useless for the current UI. I'm looking at an ideal keyboard layout for a new UI.

I don't expect anyone to *want* this layout right now and I would never consider replacing the existing layout or push for that. But what I will do is try a code branch with an experimental UI/layout.

Some of the suggestions/ideas might be useful. Some won't work. Who knows... maybe it will all be good. There certainly won't be consensus. Why not have a bit of fun thinking laterally about it instead of dismissing stuff out of hand. Can't hurt. Might help.

Don't get me wrong; looks to me like the WP34S is an awesome masterpiece as it is. I am in awe of the work that's gone into it, and excited that I can actually play with it. So why not have some fun.

The CPX is bottom-right on an f-key as noted.

Edited: 20 June 2012, 8:49 a.m.


#80

Quote:
The CPX is bottom-right on an f-key as noted.

Yes, I've found it - after quite a long search.

Seems to be a pre-prefix key now. ;-)

And the 'conversion' key -> ???

I guess you'll turn it also into a pre-prefix key!?


#81

I read, and consider your posts carefully. And I change based upon peoples' feedback. I'll miss things, and often I'm wrong... and I'll correct things when I err. But I'm nearly always calm and polite and respectful even when people are rude.

It's not a sacred cow... not mine, anyway.

I think possibly the first code change I will tackle is a reconfigurable keyboard/function mapping description file. That way, people could create their own keyboard layouts, easily add their own functions (or leave others out) just by changing the human-readable file and then compiling the code, download the new binary.

Since the binary is so tight, there may be some benefit to having a large pool of available functions and selecting a subset for a particular target user (i.e, perhaps creating a programmers' WP34S or a statistician's WP34S which each choose some functions over others, more likely to be suitable for the user of that flavour of the machine. You *might not want* to have complex support at all but may wish a whole heap of financial stuff to be included. Why can't the codebase be a *generic* build-your-own machine?

I'd like to see the labels "WP34S Programmer" or "WP34S Statistician" all built from basically the same code, with essentially the same UI, but different keyboard layouts.

Anyway, the key/function configuration file should be a useful change for the current code base, and would make for quick and easy reconfigurations for particular target users. Does there really have to be just ONE keyboard layout for the WP34S? You can bet your bottom dollar that *my* WP34S will have the keys exactly as *I* want them. Why shouldn't that be the same for everyone?

As to the complex key hidden, yes it's not a good solution. uWatch handles entry of complex numbers intuitively, by not having a complex MODE, and using the double decimal keypress for entry.

I quote from the manual...

Enter numbers in the usual way, and initiate the entry of an ipart by pressing [.] either once or twice. When a decimal dot or exponent is already present, pressing [.] will initiate the ipart entry. the screen will change to, for example, 1.2+i waiting for the ipart entry.

If there is no decimal place already, two [.]s are required, for example, to enter 1+i, enter [1][.][.], you can leave it as +i or enter [1] if you like, both are acceptable. for example [0][.][.]
enters the value i (i.e.: 0+i).

The [+/-] change sign key can be used during the process of number entry to affect the signs of number parts. Before [EXP] or "i" is entered, [+/-] changes the sign of the mantissa, after [EXP] it
changes the sign of exponent, after "i" it changes the sign of the ipart and, lastly, after [EXP] again, changes the sign of the ipart exponent.

Since the entry of a complex number can be longer than the 16 digits displayed, the number will scroll left on entry accommodating the rightmost digits. You cannot scroll back before entry.

You can display the full mantissa for both the real and iparts of a complex number by pressing [MENU] then exit with [MODE]. The complex number is displayed using both lines with the top line
the real part and the bottom line the ipart. This does not change anything on the stack and is just a display convenience.


Edited: 20 June 2012, 9:45 a.m.


#82

Quote:
I think possibly the first code change I will tackle is a reconfigurable keyboard/function mapping description file. That way, people could create their own keyboard layouts, easily add their own functions (or leave others out) just by changing the human-readable file and then compiling the code, download the new binary.

Well, what I've marked bold in your posting would certainly be only a possibility for a very small number of WP34s users and members here - I'm quite sure that the big majority here doesn't have a 'C' development environment at all and won't want (or be able) to compile the WP34s project by themselves.

So this is rather a dream than a real option.


#83

Quote:

Well, what I've marked bold in your posting would certainly be only a possibility for a very small number of WP34s users and members here - I'm quite sure that the big majority here doesn't have a 'C' development environment at all and won't want (or be able) to compile the WP34s project by themselves.


Yes I understand that. But if there were different variants (already built) that you could download -- one specialised for mathematicians, another for physicists, another for programmers, etc... then perhaps that might allow greater functionality for those uses.

For example, a mathematician might wish the CPX function to be "top level" and fair enough. A programmer certainly wouldn't, but would probably love to have the base conversion top level. Hence the configurable keyboard and variants.


Edited: 20 June 2012, 10:26 a.m.


#84

Quote:
For example, a mathematician might wish the CPX function to be "top level" and fair enough. A programmer certainly wouldn't, but would probably love to have the base conversion top level.

Well, I would want all! ;-)

But ok, I'm a mathematician, physicist, programmer, ..... ;-)


#85

Then either you need three WP 34's - 1 WP 34S, 1 WP 34M, and 1 WP 34P. Or you'll need the WP 34X - "One Calc to rule them all, One Calc to find them, One Calc to bring them all ..." (them = the solutions, of course ;-)


#86

Quote:
Then either you need three WP 34's - 1 WP 34S, 1 WP 34M, and 1 WP 34P.

Or an even better idea: you make a WP34SMP!

You can decide what SMP is standing for, either my 3 professions or 'symmetric multi-processing' (which would also be a great feature BTW). ;-)

Franz


#87

Please don't respond before reading the whole message and verifying you got the point ;-)

#88

'..' is used for fractional display already. :-(

Table driven keyboard entry is already part of the code (but not in a separate file). Have a look at keys.c! The main problem is that the whole keyboard engine is full of exceptions, there are likely more of them than there are rules. If you want to create a preprocessor for the keyboard layout, good luck! It will be a real chore. I rewrote most of the keyboard code from Pauli's original switch/case based coding and I know what I'm talking about. Don't forget such things as handling of the shift keys in the right places (including shift hold functions), auto repeat for the arrow keys (but not always), deliberate catalogue switching from one catalogue to another, alpha mode character grouping, -> key combinations, STO/RCL arithmetic,... The list is almost endless.

I do not want to discourage you but don't expect an easy job.


#89

Quote:
Don't forget such things as handling of the shift keys in the right places (including shift hold functions)

Apropos 'shift keys': pressing [f] after STO or RCL is still displaying 'f' in the alpha display for a short time (until you release the prefix-key again - I guess you forgot this with all your print&graph enhancements. ;-)

Franz

Edited: 20 June 2012, 4:37 p.m.

#90

My immediate reaction is that I like the ideas that went into this layout. From my HP calculators I'm used to having the shift key(s) in the lower left corner (with OFF as a shifted function of the ON key, using the shift key immediately above). This layout therefore seems more immediately familiar to me than the regular WP-34S layout, and I think I would (at least try to) use it if given the option.

While playing with keys, I would save one (shifted) key position by dropping the separate [hyp-1] prefix. To me, [hyp] [cos-1] (by whatever means these functions are found) makes more sense than [hyp-1] [cos].

#91

The position of CPX isn't ideal here: f CPX + can be entered via keyboard bounce or sloppy fingers. The current keyboard layout goes to some effort to not terminate functions with a double key press -- the only exception I'm aware of is . . for X as a register argument to a command that can take one -- we argued this one back and forth for quite a while.

. . can also be used for fraction entry but this isn't command entering since it occurs on the input line and can be back spaced.


- Pauli

#92

R/S should stay where it is now - putting it away from the number keys is a show killer AFAIK. All the rest I can live with.

#93

it's interesting work if you have the time to work properly on it.

Last fall I started to play with making a HP32sII keyboard layout. Problem was it lost too many WP34s unique functions so I decided that what I wanted was trig and log functions on un-shifted keys. This required moving stuff to menus so as to only have 2 shift keys.

It wasn't bad but by the time I had everything consistent enough to start coding it had already been 2 months and V3 was coming out with even more functions on the menus already!

Upon reading Marcus' slides from HHC2011 I realized that the existing keyboard layout was the results of more hours of design than I was willing to put into it and found it easier just to get to love the default layout :D

#94

Hi all.

While we're on the subject. Although I'd buy a 34S in a second, now that I've resigned myself that the HP-15c LE, 35s & 33s are NOT scheduled for ROM upgrades, a design point of the 34S I'd like to see remedied is this--if the PAUL WALtEr display is any indication of the character set, I'd rather that a correct upper and lower case character set is implemented. Unless, the lower case R is meant to advertise that the 34S has both an upper- and lowercase character set and the lower case 'r' is just that, a lowercase 'r', then, yes, I may seek to purchase a 34S. BUT, if the lowercase 't' and 'r' are what's produced if an uppercase 'T' and 'R" are typed, that leads me to question which other letters are configured to display as their opposite case character form.

So, please enlighten me. Does the character set of the 34S correctly display upper and lowercase letters or is this modification scheduled for a future ROM upgrade/hardware revision of the 34S?

Thanks

Edited: 20 June 2012, 11:04 p.m.


#95

Matt,

Please look at http://wp34s.svn.sourceforge.net/viewvc/wp34s/trunk/windows/winfont/WP34SSegmentFont.ttf?view=log and download this font. It will answer your questions by itself. If you find a way to display the missing letters in a 7-segment display, please tell us immediately ;-)

#96

We have a proper font in the upper line. Both upper and lower case characters and lots of other goodies. I'd suggested reading the manual and looking at the complete character graphics there. And yes, you get what you type.

The bottom line of the display seems to be what you're asking about here. This is a standard seven segment display meant for numbers. If you could show us how to do a complete upper and lower case alphabet within this restriction, I'd be mightily impressed -- I believe it to be impossible. We do not allow users to type anything except numbers into this line -- we do display some crude text here to partially offset the severe limitation on the length of the top line.


- Pauli


#97

Personally I rather like the rather oddbod 7-segment alpha font used for the bottom line. But is it HP-like? No. I very much doubt HP would do this on a commercial machine :)


#98

Quote:
Personally I rather like the rather oddbod 7-segment alpha font used for the bottom line. But is it HP-like? No. I very much doubt HP would do this on a commercial machine :)

They have already:

'Error' from the Voyagers and before?
'Running' on the Voyagers?

We make slightly more extensive use of the capability however.


- Pauli

#99

Hi there.

My original thought is that since this is a grassroots project with unrestricted creativity and the 34S could have a more versatile display to begin with, wouldn't it have been better to incorporate a starburst diode (i.e. 41 Series) or 5x7 dot matrix arrangement for each character in the lower display line to begin with?


Quote:
My original thought is that since this is a grassroots project with unrestricted creativity and the 34S could have a more versatile display to begin with, wouldn't it have been better to incorporate a starburst diode (i.e. 41 Series) or 5x7 dot matrix arrangement for each character in the lower display line to begin with?

Oh, that wasn't the amount of grassroots we were keen on ;-) But feel free to start such a project yourself now since the software is almost ready ...

Edited: 21 June 2012, 1:25 p.m.

The CPU can only drive 400 LCD segments without an external controller. To improve the display will require more than just a new display module.

- Pauli


I see. Thanks for letting me know what level of technology is needed and what's involved in that. It helps me to understand the feasibility and scope of what the 34S project is about. maybe my imagination is getting carried away. Thanks for the balance.


Possibly Related Threads...
Thread Author Replies Views Last Post
  Layout of arithmetic keys on early calculators Walter B 10 466 11-20-2013, 11:13 AM
Last Post: Jake Schwartz
  [WP34S] WP34S firmware on the AT91SAM7L-STK dev kit? jerome ibanes 1 157 10-04-2012, 04:59 PM
Last Post: Paul Dale
  HP-41CV layout vs Voyager's, 35s Ben Huntsman 17 693 09-17-2012, 05:30 PM
Last Post: Luiz C. Vieira (Brazil)
  Nov-64: Complete Newbie Needs Help Les Wright 16 564 05-06-2012, 08:38 AM
Last Post: Luiz C. Vieira (Brazil)
  [wp34s] Incomplete Gamma on the wp34s Les Wright 18 645 12-06-2011, 11:07 AM
Last Post: Namir
  [wp34s] Romberg Integration on the wp34s Les Wright 2 199 12-04-2011, 10:49 PM
Last Post: Les Wright
  WP 34S: Keyboard Layout Change Marcus von Cube, Germany 20 530 11-26-2011, 06:05 AM
Last Post: Walter B
  [WP34s] Firmware<>Layout wish Alexander Oestert 36 1,001 10-20-2011, 03:41 PM
Last Post: Andrés C. Rodríguez (Argentina)
  Re: [WP 34S] New keyboard layout (poll) Walter B 108 1,688 10-17-2011, 05:35 PM
Last Post: Paul Dale
  [WP 34S] New keyboard layout anybody? - Edited Marcus von Cube, Germany 168 4,037 10-09-2011, 01:19 PM
Last Post: Jeff O.

Forum Jump: