Understanding INKEY$ in ZX BASIC

Question

The ZX BASIC Manual gives the following little program to demonstrate how INKEY$ works:

10 IF INKEY$ <> "" THEN GO TO 10 
20 IF INKEY$ = "" THEN GO TO 20 
30 PRINT INKEY$; 
40 GO TO 10

While I have ascertained that this works, and that if you remove line 10 (as the manual goes on to suggest), you get several letters displayed per keypress, I just don't understand the logic of it. I mean, IF INKEY$ <> "" and IF INKEY$ = "" would seem to cover all logical possibilities. How does the program ever get to line 30?

So my question is: What exactly is the logic of INKEY$f in ZX BASIC, and why do these two conditions not produce an inescapable loop?

Answer 1

Some comprehensive BASIC to start with

There are BASICly three (*1) kinds of statements to handle single keystrokes in various BASICs (*2):

1. Waiting for a single keyvalue to arrive and returning it.

2. Checking if a key has been pressed, if yes, it's read and returned, otherwise an empty value is returned

3. Delivering the actual state of the (decoded) keyboard without any waiting or checking.

Most classic BASICs follow version #1 or #2, as they work with keystroke buffers like when there is a terminal connection. Many homecomputer BASICs, especially of the Microsoft kind follow #2, while mainframe BASICs often follow #1. Usually, but not always, it is called GET (*3). #3 is common among 'creative' BASICs that support game programming, including Sinclair BASIC.

All three have their reasoning:

Version #1 stops the program run until a keypress is received, thus waiting for it does not need to do any further handling. Convenient on more text and business style application - also, in a mainframe environment, input is sometimes only available in blocking versions

Version #2 is about as low level as any terminal based system can get. It only peeks into the input buffer, but if there is a character, it gets extracted and delivered. This allows more interactivity, but still can only report 'no keypress' or 'this key has been pressed and released' (*4).

Version #3 now is something that can only be accomplished if the keyboard state is in direct access to the BASIC interpreter. It delivers this state each time called. So handling input is much like on Assembly programs. There is no filter about pressing or releasing. This has to be done by the BASIC program. As a result, each and every key (*5) behaves much like a joystick switch. Not only pressing, but also exact timing of press and release can be detected - thus including duration of press.

In practice this translates to three different logics:

Version #1 is the most relaxed, as it always returns with a key pressed.

Version #2 also returns when no key is pressed, so if waiting is required, it needs to be looped around. Of course, other things can be done during that loop before checking the keyboard again.

Version #3 does need edge discrimination (*6) when used, differentiating key press and key release to form a keystroke if this is the goal.

Now for your question

What exactly is the logic of INKEY$ in ZX BASIC,

Sinclair BASIC's INKEY$ follows Version #3 and delivers just the actual state. Perfect for timing relevant game programming, but a bit more work for the programmer of more mundane tasks.

In your example it works like this:

10 IF INKEY$ <> "" THEN GO TO 10

This loop waits until no key is pressed by reading the matrix over and over again

20 IF INKEY$ = "" THEN GO TO 20 

This loop waits until a key is pressed by reading the matrix over and over again

30 PRINT INKEY$;

Now the matrix gets read one more time and the result is displayed.

and why do these two conditions not produce an inescapable loop?

Because it's always checking the actual state, not some buffer. The logic is the one of an edge discriminator (*6), not so much of an OS call as modern languages offer.

But yes, there is a chance to screw it, if you're able to press and release faster than thee lines are executed may result, depending on your timing, in lost keystrokes, missed keystrokes or wrong returned. Then again, We are talking about a human operation the membrane here. Fat chance :))

A truly secure routine would be a bit slower, a bit more complex and look like this:

10 A$ = INKEY$
20 IF A$ = "" THEN GO TO 10
30 IF INKEY$ <> "" THEN GO TO 30
40 PRINT A$
50 GO TO 10

Now we read the keyvalue only once and store it for later processing. This will always record the first key pressed, no matter if later on others got pressed (before releasing all).

---

*1 - Make that 6, as some BASICs define INKEY as numeric, while others (like Sinclair) made it string based.

*2 - It's INKEY on Sinclair, GET on Microsoft, and maybe other names on lesser known dialects. I just use INKEY for the remaining answer to simplify wording. I'm well aware the Sinclair might have chosen INKEY instead of GET to make clear that here a different behaviour is to be expected.

*3 - None of these single key reading operations where part of the original Dartmouth BASIC (as FORTRAN didn't offer anything about keystrokes), thus names are made up by each implementation in their own way.

*4 - Usually it's reported the time it is pressed, but both ways have been used.

*5 - Depending on the keyboard structure and scanning, multiple key combinations may or may not work.

*6 - An edge discriminator in electronics is a circuit to detect when a signal changes, like detecting a rising or falling flank (aka edge), for example in interrupt handling or alinke. Here it describes a procedural way to detect when a condition changes - from not pressed to pressend, and back.

Answer 2

I suspect your confusion is because INKEY$ returns the current state of the keyboard, not a buffered stream of up / down key presses (On serial terminal based systems such as CP/M you'd get the character code which might have buffer depending on the hardware).

Basically the code could be written:

10 Wait for all keys to be up.

20 Wait for a key to be pressed

30 Print pressed key

40 back to start again.

Answer 3

Lines 10 and 20 do cover all possibilities, but they don't cover them at the same time.

Line 10 is saying, "do not proceed to the next line as long as there's still a key being pressed from before."

Line 20 is saying, "now that no key is being pressed, stay here until one is being pressed."

You will reach line 30 only when you first press a key, which it will print, then it will go back to line 10 to wait for you to release that key, then on to line 20 to wait for you to press a new one.

Answer 4

Inkey$ is read each time it is used, as such could be different each time in the if equation.

The line 10 and 20 combination is latch.

This combination was used rather than the Input command which stop the program and waited foe a user responce. This latched inkey$ method allows some program to keep running while a user can input and control.

The problem I used to find with Inkey$ is that the longer the basic program was the slower it scanned Inkey$, and the latch would get sloppy and misread, even with the A$ storage method.

So programmers put the Inkey$ latch <> = into a Def Fn command and called it via Function, which helped the scan sloppyness, but at a cost of the Def Fn taking up some of the memory so less lengthy basic programs.

Another way was to make the Inkey$ latch <> = into machine code and called the check via say Command USR 60000 and then used the result = A$ and used that. Ie making a new command ie Stick or keyboard, which was better than using command Input.

They are alot of hacks to the Input command, you can use it like the Echo command in DOS and use it not for user entry but like the Print command or goto or call machine code and If to itself again to stop break command being used and the User hack crashing a machine code program to basic.

Some program used Inkey$ USR to call machine code so if inkey$ every got to call a check then the machine would crash rather than letting the user default back to Basic and hacking or Saving the program.

The Def FN and USR commands are quite powerful in Sinclair Basic and can do more than designed to do by doing weird equations. So one actually did chess in Basic in one line using Def FN command.

Answer 5

Raffzahn's answer is excellent and deserves to be the accepted answer but I would like to add another viewpoint.

It only appears to be impossible for the program to get to line 30 because of an implicit expectation that INKEY$ will return the same value on successive calls. However, if this was the case then one of line 10 or 20 by itself would block. Understanding why that is not the case requires a realisation that successive calls to INKEY$ might return different values. Once this is understood, the apparent impossibility should evaporate.

In some languages, a declaration of a function allows the specification of "deterministic" or "non-deterministic". When I first saw this, my reaction was: "Of course it is deterministic, it's a computer program". However, both cases are possible. A sensibly implemented sqrt or log function will be deterministic. You would not expect multiple calls to sqrt(2) to return different values. However, you should not be surprised if time() or rand() return different values. INKEY$ is of the latter type: non-deterministic.

Answer 6

Basically, INKEY$ is not a variable (though it looks like one) but a function call. The logic of the program is as follows:

1: While any key is pressed, wait.
2: While no key is pressed, wait.
3: Print the key that is currently pressed.
4: Go back to step 1.

If you eliminate step 1, then whenever you have a key pressed, step 2 will immediately terminate, and proceed to step 3, and this tight loop will repeat continuously - until you release the key, when step 2 becomes effective again.