Machine Code Keyboard Input

[MrVertigo]

I’m trying to get to grips with inputing from the keyboard in machine code. I’ve read threads on this forum, and a lot of books, but something isn’t clicking.

Can someone give me a simple routine that would essentially do nothing until a key is pressed, then return to BASIC when the key is pressed? No Rom routines, just pure machine code.

[David G]

a simple routine that would essentially do nothing until a key is pressed, then return to BASIC when the key is pressed

Pure M/C

Code: Select all

 W4KEY: LD      A,(4025H);LAST_K   ;CHECK KEYBOARD STATE
        INC     A
        JR      Z,W4KEY            ;LOOP UNTIL KEY DOWN
        RET

seven bytes, so make your REM have seven dots

Code: Select all

   1 REM .......
  10 PAUSE 120
  11 RAND USR 16514
  20 PRINT "KEY PRESSED"

Before RUNning, POKE these seven bytes:

Code: Select all

POKE 16514,58
POKE 16515,37
POKE 16516,64
POKE 16517,60
POKE 16518,40
POKE 16519,250
POKE 16520,201

The PAUSE statement will wait about 3 seconds before running the M/C. Because when you type RUN it will react so fast the keyboard is still down. So the PAUSE is to give time for the key to go up. Better machine code will first wait for all KEYS down, then wait for a key press, then RET

[MrVertigo]

Thanks. I haven’t used an assembler yet, so some assembly language confuses me. I’ve just been learning pure machine code.

What does the LAST_K director mean in assembly? That’s one of the things that’s been confusing me when I try to follow old threads on this forum.

[David G]

LAST_K is a specific location in memory. See ZX81 manual Chapter 28 - The System Variables

16421 LAST_K Shows which keys pressed

The keyboard lines are directly wired to memory location 16421 (4025 hexadecimal), so reading that memory location gives the key states. If no keys are pressed it reads -1. If any key is pressed, it will be something different. Fortunately, -1 is easy to test for in M/C -- just INC it. -1 increments to 0, hence the JR Z (Jump if Zero).

ASSEMBLY:

Code: Select all

LD      A,(4025H);LAST_K

MACHINE CODE of same:

Code: Select all

3A,25,40 hexadecimal

Code: Select all

58,37,46 decimal

LD A(nn) is opcode 3Ah, and the address is 4025h. I look up the machine codes in Appendix A of the ZX81 manual

POKE takes the decimal format

[XavSnap]

Help from VB81:

KEYS.gif (8.39 KiB) Viewed 1472 times

[1024MAK]

It should be mentioned that the update display (as in produce the video display video signal) routine in the ROM also scans the keyboard matrix, and puts the result of this in the system variable memory location called LAST_K.

This works if you are using BASIC or a assembly language / machine code routine from BASIC, and hence using the ROM video display system.

Mark

[David G]

as soon as I posted that, i began to think about how I don't fully understand the keyboard interface. I've always just used that bit of machine code with much success

Reading the LAST_K memory location is the simple solution, and it requires no ROM calls from your machine code

Thanks Mark for pointing out that LAST_K is updated by the display code. I just tried it and see that it indeed only works in SLOW mode. In FAST mode, no keypress is detected by that simple code

[MrVertigo]

Ah, I’m really looking for a full understanding of machine code that I can expand to use in coding as I progress. Reading a wired memory location is one thing, but I’m really looking to fully understand the IN A, (c) way of doing things.

Something along the lines described at the link below:

But something about it isn’t totally clicking for me. So I thought if I could see a bit of code that would achieve the aim outlined in my original post, via the IN A method, it might click.

[1024MAK]

Well first you need to understand the hardware.

The keyboard is a matrix. Eight lines are actually derived from the Z80 upper address bus, A8 to A15. So to select which ‘half’ row to scan, the I/O address has to set the upper byte accordingly.

The lower byte on the address bus must be that of the ULA, namely 0xFE. When addressed, the ULA will read the state of the five keyboard column lines and pass this information to the Z80.

Hence when an appropriate machine code IN instruction is executed, both the above are done simultaneously.

Now you need to convert this to a format that is useful to your program, including key switch contact debouching (mechanical contacts have a nasty habit of making and breaking multiple times before settling down to being made due to mechanical vibrations, the replacement keyboards are worse for this than the membrane).

The keyboard layout and matrix is shown on this schematic.
See here for the ZX81 I/O details.

Mark

[MrVertigo]

Ah, I understood the keyboard stuff before, but I couldn’t understand where FE was coming from in the stuff I was reading. I didn’t realise it was the ULA.

I sometimes see programmes doing a compare for 191, from different half row scans, checking for ANY key from that half row. But I don’t understand why 191. What is the reason? I understand that a key press, any key press, will turn one of the 1s to a 0. But surely only one of the keys will give 1011111 (191)?