Proposal - wp34s GETKEY semantics and other input functions



Post: #2

I propose a function KEY? nn, nn being a register id.

This is at the same time an input, storage and conditional function:

nn can be any register including the stack registers and indirect addressing. KEY? queries the keyboard buffer (the keys are scanned in the background) and returns an integer value to the selected register. If no key is pressed, the next step is executed. In most cases, this will be a backwards jump.

Key codes are the internally used integer codes: Top left is zero, codes increase with each column by one and with each row by six.

Waiting for a key is performed with the PSE command which can wait from zero to 9.9 seconds. If a key is pressed, the PSE is ended. The key can then be queried with KEY?

What do you think?


Post: #3

Sounds like an INPUT on HP-42s, but with automatic timeout. Good idea. Two remarks:

  1. You didn't mention any output. Is there anything appearing on the display when KEY? is encountered?
  2. Personally, I start counting with one and would vote for counting keys alike.
My 20 m€ only

Walter
Post: #4

Not quite what I just did an outline implementation of :-)

Probably better albeit more complex.


This command polls the keyboard, nothing is displayed and program execution isn't halted.


- Pauli

Post: #5

OK, so input is limited to natural numbers from zero or one to the number of keys (maybe minus one), and there is no output from KEY?. Then we are missing INPUT still.

Quote:
Waiting for a key is performed with the PSE command which can wait from zero to 9.9 seconds. If a key is pressed, the PSE ((means: pause)) is ended. The key can then be queried with KEY?

The last sentence isn't quite clear to me. I'd have searched for the key pressed via RCL nn with nn being the one used in KEY? nn before. TIA for enlightenment :-)

Walter


Post: #6

This function returns the key pressed, don't think of it so much as a numeric input. It polls the keyboard and lets you know which key is down. This suggestion cannot be achieved via any keystroke program with our current command set.

The INPUT function can be achieved by "PROMPT STO" and I still don't see a pressing need for it :-)


- Pauli


Post: #7

Let me quote Marcus (emphases added by me):

Quote:
I propose a function KEY? nn, nn being a register id. ...
nn can be any register ... . KEY? queries the keyboard buffer (...) and returns an integer value to the selected register. ... If a key is pressed, the pause is ended. The key can then be queried with KEY?

To me, the last sentence doesn't match what was said in the beginning. Marcus?

Walter


Post: #8

It does match. It is describing the interaction with pause.

    PSE 99
KEY?

A key press terminates the pause early. The key pressed can then be queried using KEY? if desired. Makes sense to me at least.


- Pauli


Post: #9

Here we reach the limits of linear programming :-)

PSE 99
KEY?
NOP
PI
PSE 99 sets a 9.9s waiting interval before the next step is executed. What is meant here, however, is KEY? is executed immediately after the waiting interval was started, and *then* either a keystroke or a 9.9s timeout will cause the program to proceed. That's my understanding based on your explanations.

Post: #10

Not at all. PSE 99 will wait 9.9 seconds. If a key is pressed, it exits early that all. Don't press a key and the full 9.9 seconds elapse. Press a key and it continues right away. This is normal pause behaviour as Marcus wrote it.


KEY? is executed only after the pause has finished either after 9.9 seconds or after a key press.


- Pauli


Post: #11

Pauli, no need to add to your explanations. You got it.

PSE 99
KEY? X
BACK 2

will wait for a keystroke and return it to the X register. The display is carried out by PSE, just the normal behaviour.

Edited: 28 Apr 2011, 8:02 a.m.


Post: #12

I might have got it, but Walter hadn't :-(

The code in svn has the conditional backward I think...


- Pauli

Post: #13

OK, so the meaning of PSE was / shall be altered. It shall not wait for the time set before passing control to the next step, but the wait interval shall be interrupted by any keystroke happening within said interval.


Post: #14

Quote:
It shall not wait for the time set before passing control to the next step, but the wait interval shall be interrupted by any keystroke happening within said interval.

I hope the first not is an error....


- Pauli


Post: #15

Quote:
I hope the first not is an error....

It would have been if I hadn't written
but later in this sentence :-)

P.S.: Seems it becomes clear why the real good stuff in mathematics was written in Latin or French ...

Edited: 28 Apr 2011, 8:17 a.m.


Post: #16

The original intention was to make PSE pause the commanded time but making it interruptible seemed a nice addition to me. If you don't touch the keyboard, the waiting time is honored.

Post: #17

Quote:
The last sentence isn't quite clear to me. I'd have searched for the key pressed via RCL nn with nn being the one used in KEY? nn before. TIA for enlightenment :-)

KEY? doesn't say "store a future key press into a register". Rather, it asks "what key is pressed NOW?"


So we can have a wait for key press sequence:

    LBL 00
PSE 99
KEY? X
RTN
GTO 00


Thus, XEQ 00 will keep looping until a key really has been pressed.
The key code is in X.

However, there are other uses that don't involve just waiting for the key press -- the program can get on with other things.


e.g. to allow a lengthy calculation to be stopped at a nice place unlike R/S that stops it immediately. E.g. after the next term in a series is summed.

Another possibility would be to allow a program to looks like it has a custom catalogue and which responds properly to arrow keys.


- Pauli


Post: #18

Oops, I've got KEY? executing the next step on a key press in the example, which isn't what Marcus suggested. Still the basic idea should be clear.


- Pauli

Post: #19

Paul, look at my example. The next instruction shall be skipped if a key is pressed. Looping back is by far the more common operation if no key has been pressed. Agreed?


Post: #20

Definitely agreed, execute the next step when no key is pressed is better.


The name is a bit suspect. KEY? would normally execute the next step when a key is present (skip on false rule).

NOKEY? is silly (and too long).

POLL ?


- Pauli


Post: #21

Do if true is a good consistent rule to follow if at all possible, IMO.

So, Key? would do the next step if true, ISTM.


Post: #22

What about DSZ? The meaning is "Decrement, Skip if Zero" not "Decrement, Execute if Zero".


Post: #23

For those interested, I've implemented the proposal together with Pauli. It's in SVN as an emulator build. The flash file is totally untested.


Forum Jump: