A 9-pin RS-232 serial port looks superficially quite similar to the Atari joystick port. I don't suppose you could just plug a joystick into a serial port and have it work, but suppose you took this into account at design time, say you were designing an 8-bit computer back in the day, early eighties or so, and you were equipping it with a 9-pin RS-232 serial port for the sake of being able to plug in a modem or serial printer or suchlike, would it be feasible to also make it take a joystick?

  • 2
    It's not particularly feasible since the two different ports need to wire up to completely distinct internal electronics to handle them. A UART in the case of RS-232, and a set of TTL GPIO lines in the case of the Atari-style joystick. – Brian H Apr 24 '17 at 15:48
up vote 5 down vote accepted

Not an Atari joystick.

The Atari joystick was basically just a set of mechanical switches and each of the pins was either ground, +5 volts, or one of the switches.

Were you designing a joystick back in the 80's to plug in to a serial port, you would have needed to put some electronics in it i.e. a chip to support RS232. I think that would have been prohibitively expensive back in the day.

On the other hand, there's no reason why you couldn't make it work from a technical perspective. The protocol would be quite simple and you wouldn't need to run it at more than a few hundred baud.

In the early eighties, use of a 9-pin port for serial communications was uncommon. Most systems used the standard 25-pin port. I think it was IBM that made the 9-pin serial port popular, but I don't think that happened until around the time of the IBM PC AT (the original Macintosh also had a 9-pin serial port but it was wired differently, and was eventually replaced by round 8-pin Mini-DIN connectors).

Regardless, if you wanted to allow one port to connect to different types of devices it was theoretically possible, and the basic way to do it was to use something called a "tri-state buffer" for each device. This was a chip that basically allowed a pin on a connector to be in one of three states:

  1. asserted (logical 1)
  2. deasserted (logical 0)
  3. high-impedance (disconnected)

As long as all devices were kept in the high-impedance state (except the one that was actively using the connector at that moment) this would work, but it had two severe drawbacks:

  1. The operating system had to be able to tell which device should be able to use the port, and if the user had the wrong thing connected to the port it was possible to burn something out (i.e. user error could lead to hardware damage).
  2. Sharing ports like this was terribly inconvenient when a user wanted to use two different peripherals at the same time (for example, using a joystick to play an on-line game that required a serial port connection to a modem).

In practice it was far better to use separate ports for different purposes (and to make the connectors different shapes to prevent users from plugging things in the wrong place). So there was some incentive to move to smaller ports (like the 9-pin D connector or the Mini-DIN connectors) but very little reason to actually share ports among different devices. Game controllers were the only exception that come to mind (and they were wired in such a way that it would be safe to, e.g., plug in a joystick if the game actually used paddles).

Note that the sharing of one port among different devices was done, but only when all devices used the same type of communication. These were commonly called "busses", and notable examples at that time would include the IEEE-488 bus used on the Commodore PET, the IEC bus used on the C-64, and the SIO bus used on the Atari 400/800. If you wanted to use one port for multiple devices, the use of a bus was the way to go. Even the expansion ports in the Apple ][ could be considered a type of bus (albeit one where each slot had its own address).

  • Back in the 80's when I first came across RS232, it wasn't uncommon to use standard sized DIN plugs. The C64's serial port was one such, for example. – JeremyP Apr 26 '17 at 8:28
  • the 6-pin DIN port on the C64 was called a serial port, but it wasn't RS-232. It was actually a serialized version of the parallel IEEE-488 bus. This is what I was referring to as the IEC bus. – Ken Gober Apr 26 '17 at 12:50
  • But we also had DIN ports for actual RS-232 as well. – JeremyP Apr 26 '17 at 12:57
  • The Apple //c used full-size DIN ports for RS-232 (that was in 1984), perhaps that's what you're thinking of? RS-232 on the C64 was typically done via the user port (where the VICmodems plugged in, although you could also get 25-pin RS-232 ports that plugged in there as well). I suppose it's possible that someone made an RS-232 adapter that plugged into the user port that had DIN connectors rather than a DB25 but I've never seen one. – Ken Gober Apr 26 '17 at 13:48

It could be done with a standard RS232 port. Not that you could plug an Atari joystick straight into it, but it would be trivial to run a five-microswitch joystick (i.e. Atari-type) on a serial port. Nor would you need a special driver for the host. Any old program could read the port and get the button info from it.

Before USB and even PS/2 ports were common, there were mice that plugged into the serial port. If you can run a mouse on a serial port you can certainly run a joystick! And the Atari-type joystick presents a much smaller problem.

A computer's RS232 port is set up as "Data Terminal Equipment", which means that it receives four different "status" signals from the DCE: Data Set Ready, Clear To Send, Carrier Detect, and Ring Indicator. For an Atari-type joystick it would be trivial to connect four of the five microswitches to these so that they'd send RS232-compatible "asserted" (positive voltage) and "deasserted" (negative voltage) on these.

For the fifth switch you could use the Received Data (RD) line. You couldn't send actual characters on RD without more logic, but if you just leave it at negative voltage (marking) when the switch is not-pressed and go to positive voltage (spacing) when the switch is pressed, the computer would see framing errors (or random incoming characters if it was released fast enough) in the status from the port. Set the port at 115200 bps and you could be "sampling" that button about 10,000 times a second, far more than fast enough.

The chief obstacle would seem to be power -- or, rather, voltage. Very very little current is needed to drive those lines, as they are high-impedance, voltage-sensitive inputs.

An RS232 port does not intentionally supply any power. However its own output signal lines obviously are capable of driving RS232 inputs, and that's all we'd be asking them to do here. (They can even supply enough current to light up LEDs and still provide useful signals to the other end, as witnessed by countless "RS232 testers" whose LEDs were powered from the port.)

We just arrange for the program in the host to set up the port properly: If it asserts, say DTR, there you have your + voltage, and if it deasserts, say, RTS, there you have the negative. The TxD signal on an idle port will also be constantly providing negative voltage ("marking").

So all you really need are five microswitches, a connector and cable, and appropriate wiring.

A more sophisticated approach would be to actually send serial data on an RS232-compatible line. You'd need a bit rate generator, a UART, and a single RS232 line driver... which in this case need be nothing more than a couple of transistors (just one if you're creative). For an Atari-type stick you just wire your five microswitches into five data pins on the UART, and it sends a continuous stream of characters - bits within each character indicating the status of the five switches.

You could trivially expand this to eight switches.

Or with a better position sensor under your joystick you could use the extra three bits for "intensity", indicating how far the joystick was pushed in the direction indicated. Or you could do more sophisticated schemes. With one bit for the "fire" button 128 different combinations of direction and magnitude could be encoded if the hardware sensing the joystick position permitted it. 16 different directions (permitting 22.5-degree resolution) and 8 magnitudes, for example.

With CMOS this circuitry would consume microamps and so could easily be powered from the few mA available from the output signal lines.

Again, if you can run (and afford to make) a serial mouse from a serial port with no additional power supply, you can obviously do this. Cost would be no more prohibitive than that for a serial mouse.

  • 1
    The serial mouse is a bad comparison: it actually speaks RS-232, rather than merely hijacking the signal lines for a non-serial-data protocol. – Mark Apr 25 '17 at 20:33
  • I don't understand your comment. The latter part of my answer outlined how you could build a joystick that actually speaks RS-232, with a UART and RS-232 line driver (it only needs to drive one line, it need only be a couple of transistors), powered from the serial port. The serial mouse is an exactly on point comparison. – Jamie Hanrahan Apr 25 '17 at 22:03
  • I have edited my answer to make the point more clear. Anyway, the OQ did not limit answers to those that "actually speak RS-232" for a serial data stream. – Jamie Hanrahan Apr 25 '17 at 22:10
  • Serial mice communicate by sending a byte stream over the data lines of the RS-232 connection; a vertical motion of a Microsoft mouse with the left button held down might look like 64 0C 1A. – Mark Apr 25 '17 at 22:13
  • Why, yes, I know that. ... and? What's your point? As I described (starting with the words "A more sophisticated approach would be to actually send serial data on an RS232-compatible line"), joystick position + button state could be easily sent as a byte stream over the data line of an RS-232 connection. If eight bits per report is sufficient you wouldn't even need any logic beyond the UART. – Jamie Hanrahan Apr 25 '17 at 22:29

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.