34S Keyboard help

[Andrés C. Rodríguez (Argentina)]

Some time ago, and responding to a query for new functionality, I mentioned the keyboard behavior of the HP41C and HP42S. On these calculators (and emulators like v41 and Free42), when a key is pressed and held down, the name of the function is displayed and, if the key is kept down for a couple of seconds, the display reverts to NULL, and no operation is carried out at key release. It's very useful in the HP41 due to the USER redefinable keyboard (by means of the ASSIGN function); and perhaps not as important in the HP42S, but helpful anyway.

I learned from the responses that such behavior may be difficult to implement on the 34S, and I understand (and respect) the reasons and decisions of the design team. However, playing for the first time with my own 34S, I noticed that, in program mode, the alpha display shows the function name for each step. So, when you press a key in program mode, the display shows the function name... only that it is also recorded as a program step. In the meantime until I make or get a reasonable overlay, this helps to "map" functions to key locations.

Would it be possible to reuse some of the program-mode function-name-display-at-keypress code to offer some of the suggested functionality (perhaps without NULL)? In such a mode (a flag may activate/deactivate it), the alpha display will show the last function name for a second or two, before reverting to its "normal" usage.

Just my (additional) AR$ 0.12

[Walter B]

Buenas tardes, Andrés,

One difference of the 34S to the 41C is we don't have assignable keys except the now four hotkeys. So a more or less permanent overlay will help a lot - I do it with a sheet of paper so far. Else I'd be lost - only Pauli knows by heart where all the labels are located so he can operate the calc without an overlay ;-)

The difference to the 42S is we can't have a complete separation of indicators and alphanumeric display in the 34S due to hardware restrictions. The LCD features only a very limited number of fixed annunciators (and we abuse some of them already). So we have to put some indicators in the dot matrix where they should stay constant as long as applicable. With displaying the function called for a short time, we'd return to the flicker of the 41C.

Nevertheless, I see the benefits of your suggestion. Pauli will tell if it's something which can be done within the code space limits set.

Walter

Edited: 26 May 2011, 1:36 a.m.

[Paul Dale]

Quote:

---

Else I'd be lost - only Pauli knows by heart where all the labels are located so he can operate the calc without an overlay ;-)

---

Sadly this is true, apart from some of the alpha keys. I also know the keyboard to function mapping in console emulator.

Quote:

---

Nevertheless, I see the benefits of your suggestion. Pauli will tell if it's something which can be done within the code space limits set.

---

Marcus would be better at deciding this one.

The space to actually take an internal op-code returned from the keyboard handler and generate a string from it isn't going to be large. The code to display this and null it after a time period will be more complex I suspect. You'll get the command printed after every completion of a command (unlike the 41 which doesn't do this for commands that take arguments) unless extra effort/code is added.

That said, I don't really see the necessity of this once you've got an overlay.

- Pauli

[Marcus von Cube, Germany]

The question is what to do with long running functions (they display "wait..." at the moment) and if the code will fit in the roughly 1000 bytes of flash space left.

Walter has mentioned the annunciator problem. We might go the route of displaying the function name while the function is executing but with a minimum time to make it noticeable. We already have part of the infrastructure in place. Just look at the RPN indicator which flashes when a key is pressed.

[Andrés C. Rodríguez (Argentina)]

Thank you Walter, Paul and Marcus, for taking this into consideration. I cannot evaluate by myself the convenience for the majority of users, nor the "cost" of firmware space, development time, and risks of damaging other features; so I'm more than glad that you take a look at this idea.

Best regards,

[Paul Dale]

The firmware space cost is an interesting one.

* 1000 bytes is another user code page.

* It is also space for fixing functional bugs.

* It could also be space for adding features (as this is).

Basically, the 128kb of flash is full. There are things that can be done to reclaim small amounts but I'm not aware of any low hanging fruit here anymore -- we've collected these already. I.e. nothing "big" & "relatively easy" remains to my knowledge.

Thus, it comes down to is displaying the command name more important that another page of user code? Is it more important that leaving a bit extra for bug fixing? And are future bug fixes more important that that elusive page of programs?

I'd suggest the answers to these are: don't know, probably not and definitely respectively. Still, we won't know for sure how much space it takes until it is implemented.

BTW: We've got Hugh's number factorisation in the code but disabled. Who'd be interested in this instead of the above? The reason it isn't in yet is that is isn't tiny :-) The function takes the number in X (integer or real of course) and returns the smallest prime factor.

- Pauli

[Andrés C. Rodríguez (Argentina)]

It seems that the cost in flash space is too high to afford, so let's put our hopes in the development of good overlays. Certainly other functions, improvements and revisions deserve priority for a such scarce resource. I feel that keyboard help may have been a "nice to have" item, but hardly critical or essential at all.

Thank you again for looking at my suggestion.

Best regards.

[Marcus von Cube, Germany]

As the "maintainer of flash space" I have my own ideas:

A program region is always 1KB in size, a total of 4 flash pages. What we have now is a few bytes too short.

We always need some headroom for bug fixing. What would you say if we offered another page for code which you are happily using and then we find out we have to reclaim the space again for other purposes on the next minor release?

Saving space without losing any functionality mainly means a redesign of the numerical algorithms. For now, most of them are coded in C. We will eventually define our own compact interpreted language for these so that adding more brain doesn't take too much code space. An intermediate step might be to relocate some of the commands to user code, sacrificing some speed and accuracy but gaining space. We already have some functions implemented this way.