Looking at the schematic and explanation of how the C64 joystick ports work, it seems clear that the stick direction and button lines (JOYA0, through JOYA3 for port 1 and JOYB0, through JOYB3 for port 2) can also be used as outputs by having the attached device sense the levels of those lines (5V and 0V) and programming the CIA to pull the levels high and low in the same way as is done for keyboard scanning. (Or, for that matter, manually pressing appropriate keys on the keyboard to bring the levels low.)

This should also work on the VIC-20, and perhaps other Commodore computers with joystick ports.

Were any devices that used this technique manufactured and sold? If so, what were they, and how did they deal with keyboard interference with the scanning?

(This question was inspired by a comment on the pagetable.com blog post NES and SNES Controllers on a 6502 (like the C64). It seems to me that you could use the same technique with NES/SNES controllers plugged into the joystick ports instead of the user port, albeit you'd need to deal with the issue of keys pressed on the keyboard interfering with the I/O.)

  • 1
    I recall a digital audio sampler for the Amiga using the (C64 compatible) joystick port to record line level input using 8 bit samples at ~8KHz. Most likely the data were sent 4-bits at a time.
    – Brian H
    Commented Aug 13, 2019 at 13:14
  • Why not use the Userport instead? It was meant for that sort of things.
    – Janka
    Commented Aug 14, 2019 at 7:31
  • 1
    @Janka Well, that's a quite different question only tangentally related to this one. But some reasons could be: 1) leaving the user port free for other peripherals, such as a modem; 2) lower hardware cost (due to cheaper connector and PC board); 3) connector wear (the user port edge connector is more fragile than the joystick connectors); and 4) non-technical users may feel more comfortable plugging and unplugging with the less intimidating joystick port and connector.
    – cjs
    Commented Aug 14, 2019 at 7:44
  • 1
    I think the joystick ports are the ones you don't want to use for anything but joysticks as everyone had them. Plus, the internal circuitry didn't feature any EMI protection to the CIA, so most people outright refused to unplug their joysticks and expose the ports. (It was the same for the Userport, but a damaged joystick port meant the box was essentially bricked.)
    – Janka
    Commented Aug 14, 2019 at 8:09
  • 1
    @Janka Even if "everyone had joysticks," non-game software that was more likely to use a modem, A/D or other user port device was less likely to use a joystick. Further, even fewer programs needed two joysticks, so a joystick, user port device and "dongle" could all be used together. But this is really not on topic at all for this question; if you want answers about this you should ask a separate question.
    – cjs
    Commented Aug 14, 2019 at 8:14

4 Answers 4


The dongle for the PaperClip word processor plugged into joystick port 1. It read bits 0 and 1 from the dongle and wrote bits 2, 3 and 4 to control it.

Keyboard interference probably wasn't an issue with this use case.

  • It was imperative that the dongle avoid keyboard interference, but I would think that an alternative dongle design could have exploited the relationship between the joystick and keyboard port if it included a circuit to watch input 0 and briefly assert inputs 1-4 in sequence in response to a rising edge on input 0. Without the dongle installed, only four rows of the keyboard would work.
    – supercat
    Commented Oct 22, 2019 at 15:07

The Inception 8 joysticks adapter uses a joystick port for two-way communication between C64 and Inception board. Basically, a program at the C64 would send a command sequence via the joystick port, switches the port to listen and receives the Inception board's reply. In most cases, the information communicated is the state of the joysticks connected to the Inception board, but the board's FPGA can also act as an external math coprocessor.

  • Since Inception uses only a single Joystick port, it should also work with a VIC-20, but I'm not aware of any software supporting this. For the C64 there are a couple of games supporting Inception8.
    – Peter B.
    Commented Oct 19, 2019 at 20:51

The amazing little AtariLab was actually ported to the C64. This included pretty complete I/O, although it was mostly used for input. I'm not sure how many, if any, actually shipped.


One prominent example is the "homebrew" EPROM burner Tiny Eprommer, originally published 1984 in 64'er Magazine, Special Issue #84. (People are still building/using this device; it's often seen on fx eBay as both kit or assembled product.)

The main board is attached to the user port but as the device needs more GPIO than what the user port provides, a daughter board is connected, with a cable, to the 2 joystick ports, each of which maps to 4 data bus pins on the EPROM. Thus, the device both reads and writes the EPROM's data bus using the control ports.

The keyboard scanning routine does not interfere as long as the host software refrains from calling the kernal routine for keyboard scanning ($EA86, typically invoked from the standard $EA31 interrupt handler), or disables interrupts. However, typing on the keyboard while using CIA1 for I/O is going to cause trouble, as "random" connections between inputs/outpus are being made.

(As a side note, the control ports are neither better or worse protected than the user port - if you check the schematic, you'll find they both connect directly to a CIA chip. There is nothing inherently wrong with interfacing devices through the control ports, but apart from the inconvenience to the user of having to remove controllers, there is also the limitation of keyboard interference, which for some scenarios - like the EPROM burner - can be acceptable. And of course, if you do blow a CIA, you're more likely to notice if it's the one handling the keyboard/control ports. :)

  • I wonder why the designers of such a device wouldn't use 74LS373 and/or 74LS374 or equivalent chips for I/O expansion? Adding one of each such chips would provide 16 extra I/O pins easily, and I would think that would be easier than adding an extra connector and cable. Wire the main 8 data pins of the user port to the EPROM data bus and the inputs of the 74LS373/374 chips. Wire one control output wire to the clock/latch inputs of the 74LS373/374 chips, and wire another to the EPROM chip-select.
    – supercat
    Commented Sep 15, 2020 at 16:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .