I wrote this little Basic program to get Joystick input from Control Port 1.

I know that this method is very strange and is better for keyboard input.

20 get a$
30 if a$="" then 20
32 b=asc(a$)
33 if b=50 then 100
34 if b=95 then 200
35 if b=160 then 300
36 if b=29 then 400 : rem left/problem
46 a$="":goto20
100 print"right":goto46


400 print"left":goto46

The program works as expected but when I do 'left' the program lags for approximately 1 second. I can't even stop the program during the lag. Why is this only happening for 'left'?. I heard about something that the Control Port 1 is time delayed but I'm not sure and I do not know why this should be only for 'left'.


2 Answers 2


Control Port? You are reading the keyboard (*1).

Here 29 (1D) is cursor right, while 159 (9D) is left (Down=17; Up=145)

To read the joystick you need to peek into the port. 56321 for port 2, 56320 for port 1 (2).

Try 10 PRINT PEEK(56320): GOTO 10 and wiggle your joystick to see all values via port 1. Since it's a bitmap, testing should be done by masking the values, or at (maybe faster) using a mask to remove fire and unwanted lines before going through an IF-sequence like yours, as logic operations in BASIC are slow.

And finally, you might want to consider some more reliable fall through checking.

(1) - The reason you are getting some/any results is due to the fact, that keyboard and joystick are using the same ports. Reading via GET is not only tricky, but a great way to screw things up.

(2) - To keep joystick and keyboard separate, it might be a good idea to switch the keyscan off (POKE 56322,224) and only enable it when needed (POKE 56322,255) - when to do it best depends a lot on your programm structure.

  • Thanks, How could 'get' screw up things? And is there a reason why this doesn't work with Control Port 2 at all?
    – user6734
    Oct 5, 2017 at 17:15
  • 3
    'Cause GET want to scan a matrix and the Joystick isn't wired according to this. It shortens a whole column on the matrix. Port 2 is wired to the row lines, and since they are driven low anyway, shortening them wont yield any result. Just take a peek (pun intended) at the C64 schmatics: c64-wiki.de/images/2/21/Schaltplan_C64_original.pdf Keep in mind that the C64 was just ment for a short production run to keep a foothold in the market until the real machines where ready. Resulting in a less than great design.
    – Raffzahn
    Oct 5, 2017 at 20:13
  • 1
    A common way for a fast joystick integration in BASIC is using a tiny machien code routine which not only reads the port, but also converts the directions to a 0..8 value which can be used with an ON GOTO/ON GOSUB statement thus saving lots of conversions. and resulting in a next to even handling time independant of the direction taken.
    – Raffzahn
    Oct 5, 2017 at 20:20

The get a$ method isn't really a good way to read the joystick. Raffzahn's method is much better: it directly queries the CIA's I/O lines the joystick acts on.

Actually, it just works by accident: the C64 uses the very same CIA I/O lines to query the keyboard matrix and the joystick ports. Essentially, from software you can't tell whether a key is pressed or the joystick is moved.

The keyboard is a matrix of contacts that are horizontally connected to the same lines as one joystick port and vertically connected to those of the other joystick port. When you press a key you connect a horizontal line to a vertical line. The keyboard subroutine in turn pulls down one of the horizontal lines and looks for a vertical line being pulled low as well. If it is the key on the intersection must be pressed.

Each joystick has four directional contacts that are closed when you move in that direction. It doesn't need to be scanned but from the keyboard routine's perspective it looks like a whole row or column on the keyboard is depressed - it senses a pulled down line no matter what row it currently scans. On the other joystick port you short the scanning (output) lines to ground which can't be sensed, that's why the get a$ method doesn't work there.

The keyboard scanning interferes with reading the I/O lines directly, so it's better to switch the horizontal lines to input as well while you're querying the ports - that is what the POKE does.

(It is quite possible that I mixed up horizontal and vertical lines but you'll get the idea. Of course, the keyboard is not physically arranged in a rectangular matrix but it's wired that way.)

You must log in to answer this question.