How to change kernal SCNKEY routine behaviour in Commodore 64

Question

I'm trying to implement game controls using kernel routines in Commodore 64.

Below code works with one exception. Each key stroke counted as single input. e.g.: There is no effect if you keep holding the button. You had to release and press again for each move. How can I change this behaviour? Simply I want to repat the action as long as the key held down.

    GETIN  =  $FFE4
    SCNKEY =  $FF9F

keyScan:
    jsr SCNKEY  ;get key
    jsr GETIN   ;put key in A

    cmp #65
    beq left

    cmp #68
    beq right

    jmp keyScan 

Tanner

A great question for retrocomputing.stackexchange.com – Urethra

Answer 1

SCNKEY isn't suitable for games that require multiple simultaneous key input. It's stateless and simply returns 'the' key that is pressed now — i.e. if two are pressed, it'll tell you only one, and officially makes no guarantee as to which. The best you could do is consider a key still pressed until SCNKEY reports either that something else is pressed or that nothing is, but it'd be even odds as to whether a second simultaneous keypress is ignored or replaces the first.

If your program doesn't fit the orthodoxy of there only ever being 'the' key that is pressed, you'll have to hit the hardware yourself. Codebase64 offers some example code; my summary version is (having set up the CIA correctly, though it'll likely be appropriately configured already):

1. write a byte to DC00 which contains a 0 for each row that you want simultaneously to scan;
2. read a byte from DC01 and check the top four bits to find out which keys of those on the selected rows were pressed.

A generic routine would need to test each row individually to avoid shadowing — suppose you asked to read rows 4 and 5 at the same time by storing 0s to DC00 in bits 3 and 4, and the result you got back had the top bit clear, you wouldn't know whether v or n or both were pressed, only that at least one of them is.

See the very bottom of the same link as above for a table of the rows and columns on an English-language keyboard; they're the result of the physical key layout so other languages will vary as much as their keyboards do. If you're writing a game and you're more interested in the layout of the keys than their symbols then you needn't worry about the language.

Cohobate

This is similar to ZX Spectrum, where some games did use the "shadowing" of multiple rows to allow for controlling the game with the same keys over multiple rows of keyboard (For example "k/l" worked in same way as "o/p" .. (not sure about actualy keyboard layout, maybe I'm 1 off). For some games like arkanoid actually almost whole keyboard worked either as left or right. :D – Levan

Answer 2

Yea, the C64 doesn't have key-repeat (like this editor I'm typing into right now does).

The typical way this problem is solved is by polling memory location 197, which holds the current keyboard scan code. To try it out, run this: 10 printpeek(197):goto10

You can see that the value of 197 changes, and actually holds it's value. Of course, the key value isn't ascii, or even petscii, but you can experiment to find the scan code of the keys whose values you are interested in.

Quindecennial