Are game port joystick button circuits more than plain switches? Is this one just faulty?

Question

I'm building a custom interface unit for a game port joystick. To use/test it, I have a CH Products Mach III. (This is the IBM PC version, not the Apple version.) I purchased the joystick for this purpose and have not tested it with an original computer.

I found that the second button was registering as always-pressed. On investigation, there is a resistance of about 60 Ω between "button 2" pin 7 and "ground" pin 4 (pin 5 is absent from the plug) when the button is not pressed, <1 Ω when the button is pressed, and no connection between pin 7 and any other pin. Button 1 behaves more as expected, an open circuit when the button is not pressed.

Is this a special signaling mechanism of some sort, or does it merely indicate that the switch is dirty? (It is not clear how to open the joystick to inspect the circuit, or I would have done this first. Perhaps I'll ask a separate question about that.)

I would ideally like to design the interface unit to be broadly compatible with different models of joysticks (including, possibly, Apple-style joysticks with an alternate socket; and excluding proprietary extensions or anything requiring digital decoding), so I am preferably looking for expectations on button interfacing, perhaps with recommended (or historical) detection thresholds, not just information about this specific joystick.

Answer 1

Is this a special signaling mechanism of some sort,

No. Buttons are always on/off mechanics. The PC doesn't have any means to detect anything but high or low, according to the threshold (*1) the input circuit has (*2).

or does it merely indicate that the switch is dirty?

Yes, a dirty switch, a used up one, a broken one, some bad soldering adding a bridge and so on.

---

P.S.: Here's a real nice detailed page about the GCA.

P.P.S.:

I would ideally like to design the interface unit to accommodate as many joysticks as possible

'as many' as in many different joystick (styles) on a single GCA style interface, or as in many joysticks at the same time? If the later, then the maximum is about 16 pairs, as the address range for joysticks ports is 200h..20Fh with 201h being the default. This is ofc only true if you're designing a classic ISA type card. Going by USB, it's all up to your driver.

---

*1 - For the 74LS244, as used in the original IBM GCA, requires at least 2.0V to detect a high or less than 0.8V to detect low. Since all pullups are ~5 kOhm this means that a button (including all cabling) should have a resistance less than ~0.9 kOhm when closed and above ~4 kOhm when 'open'. So 60 Ohm for sure mean it's always detected as low or closed.

Of course these values may differ for any of the countless other game port inputs.

*2 - Of course, being a digital input, they could be used for some serial data transmission. But that's way beyond standard button usage.

Answer 2

To answer the gist of your question of

I'm building a custom interface unit for a game port joystick.

and

I would ideally like to design the interface unit to be broadly compatible with different models of joysticks

I refer you to some resources of my own past research:

1. History of the Gameport, and analog joysticks:
   https://mysite.du.edu/~etuttle/electron/elect57.htm

2. Info about "Digital" Joysticks, and also some history:
   https://sites.google.com/site/joystickrehab/analog-vs-digital

   Joystick manufacturers began to use signal mixing to produce joysticks which adhered to their own standards and did not strictly adhere to IBM's DA15 specification. That is, instead of using a single pin on the DA15 port to address the joystick's functions, it would use a combination of pins per signal. These controllers also posessed the first Point of View hats. They would be the first Digital Joysticks. These would require their own driver software in order to be utilized by Windows 95; in MS-DOS the game title would have to directly be programmed for it. Even then, DA15 port was ultimately not able to handle the demands of newer and more complicated games and their correspondingly more intricate controllers.

   The Linux Joystick driver source code could be a good ressource when trying to understand these "digital" gameport joystick implementations:
   https://www.kernel.org/doc/html/latest/input/joydev/joystick.html#hw-specific-driver-information
   https://github.com/torvalds/linux/tree/master/drivers/input/joystick

3. Furthermore, some of the existing USB adapter interfaces like the one you perhaps intend to create:
   https://sites.google.com/site/joystickrehab/itemcatal
   Info on the Hardware side for USB joystick programming:
   https://helmpcb.com/electronics/usb-joystick
   And you might find various other adapter builds when searching for microcontroller, arduino and usb joystick keywords.

4. Finally, some specifics to the special art of Force-Feedback MIDI-port Joysticks:
   Microsoft used the MIDI I/O pins of the CreativeLabs gameport spec for bi-directional communication of Force definitions, by emulating a MIDI instrument.
   Aside from this, these sticks were using ingenious methods to do serial communication over the gameport, known as the OverDrive protocol and patented by MS in US Patent 5628686.

   DescentBB thread about reverse-engineering the protocol:
   https://www.descentbb.net/viewtopic.php?t=19061
   and resulting code:
   https://github.com/tloimu/adapt-ffb-joy/wiki

In your specific case, it's possible you have a dirty button (<1 Ω), but the earlier answer is incorrect in saying "Buttons are always on/off mechanics" in this case. Reading the patent on the OverDrive protocol explains how the Gameport mechanics, described in the first link (charging a capacitor over time and polling capacitor charge), can be (ab)used to do much more than on/off switches.

I hope this information can help you build the very best custom joystick gameport interface. Good luck!