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?

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.

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

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?

---

Walter

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

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

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?

---

Walter

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

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

Here we reach the limits of linear programming :-)

PSE 99

KEY?

NOP

PI

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

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.

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?

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

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

- Pauli

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.

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

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

Quote:

---

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

---

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.

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.

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.

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

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.