The question is pretty straight forward. How did they do so much more than the simple, unidirectional 4 axis of analog control, plus 4 on/off buttons?

There was surprisingly precise force feedback info, many buttons, and I feel like there were some joysticks had more than 4 analog axis of motion (though I may be mis-remembering this).

Some back story:

I used to have a Microsoft SideWinder Force Feedback Pro joystick that used the Game Port. It had an 8 way hat-switch, 8 buttons, a 9th button that could act as a shift for the 8 buttons or as it's own button, and, not to mention, very precise force feedback.

In flight sims, you could see the stick precisely mimic what the control yoke in the game was doing. As I kid, I used to bypass the hand detection of the controller just to watch autopilot move the stick both in game and in real life as it flew the plane. The joystick tracked the motions perfectly.

From what I understand of the Game Port, it has 4 analogue channels for joysticks, and 4 digital channels for buttons, as well as a single serial data channel that was added by Creative in the early days to their soundcards that pulled double duty for MIDI data as well. This, from what I understand, was later picked up by everyone else and became a standard feature.

I can't find much detail on this serial channel, and I suspect it's the key to how all these extra features worked, of course with the help of specialized drivers that were a must in those days.

But this is my question:

How did they do this? Was it a simple RS232 serial signal? Did they repurpose the digital button channels to send serial data? From what I gather, polling the analogue and digital channels was quite resource intensive because of how it had to be polled multiple times, manually by the CPU (instead of having something like a keyboard buffer). Did they leverage this fact to be able to get the button channels to send data?

The other thing that comes to mind is that, if I recall correctly, the SideWinder Joysticks didn't need calibration, because they used an optical mechanism. Were they still using the analog channels for XYZ and R, or did they serialize this too?

  • 1
    DId the more advanced Joysticks actually work on the Gameport? IIRC mine needs to be connected via USB to be able to use all the buttons etc., and if you connect it via gameport, you only get the basic gameport functionality. But I'd have to dig out mine and check.
    – dirkt
    Commented Aug 3, 2022 at 2:49
  • Some did! My first generation MS SideWinder Force Feedback Pro that I referenced did indeed have full functionality on the game port!
    – nabeelr
    Commented Aug 3, 2022 at 2:55
  • @nabeelr Are you talking about this? I have one here, somewhere. (I bought it for my PC/AT in late 1983 or early 1984, I think.) I have the schematics for it, somewhere. Came with the IBM technical reference manuals I bought from IBM for 'not cheap.' I think there were four analog and a similar number of digital inputs on it. I'll have to go look, though.
    – jonk
    Commented Aug 3, 2022 at 6:09
  • I had one of these! And somehow never once stopped to think about how it worked. Missed opportunity.
    – Raydot
    Commented Aug 6, 2022 at 1:14

2 Answers 2


I know of a minimum of two implementations of this that, as far as I know, were done independently.

  1. Gravis's GrIP protocol, which is used in the gameport version of the Gravis Gamepad Pro. Wikipedia cites GRiP-duino as a source for saying that it sends a digital protocol over the button lines. (Necessary for using the Gamepad Pro's Start/Select and shoulder buttons and for its support for connecting up to 4 of them via the pass-through connector on the PC end of the cable.)

  2. The protocol used by the Microsoft Sidewinder 3D Pro I used to have (no force feedback but 4 axes, 8 buttons, and a hat switch), which was a Gameport-only device that required special drivers for its non-fallback mode.

I don't know about the latter, but it appears to be the same protocol used by the Precision Pro and Hackaday talks about how MaZderMind reverse-engineered it. (An explanation of the protocol, including screenshots of the oscilloscope readings, is present in the README.)

They also point at US Patent 5628686 (Apparatus and method for bidirectional data communication in a game port) as a prototype of the concept which doesn't perfectly match the behaviour of the shipped product, but gives the gist of the idea.

The links on How can I use a SideWinder 3D Pro with a modern PC running Windows 7? here on RC.SE may also be useful, since they involve building a custom USB-Gameport adapter to speak said protocol.

  • Great answer! Creative also sold gameport gamepads with loads of buttons, I don’t remember if they used their own protocols or something else. Commented Aug 3, 2022 at 7:26
  • Thrustmaster also had their own protocol(s) IIRC, which was supported by flight sims and games such as Descent. Commented Aug 3, 2022 at 7:28
  • speaking of Gamepads: the Sidewinder Gamepad exposed a Gameport and you could daisy-chain up to four of them. Good times with local multiplayer NHL98! Later I was disappointed when this wouldn't work under Linux, because of proprietary Windows drivers/protocols...
    – kubi
    Commented Aug 3, 2022 at 9:01

There are multiple different ways that are possible, so many of the things you listed have been used, in addition to others.

Your first question is, how did they do this.

Specifically, the Microsoft Sidewinder Force Feedback Pro you are asking about, simply uses the game port's MIDI serial interface for data transmission. While the original IBM game port did not have a MIDI interface and it was added by Creative for the first Sound Blaster card by replacing extra 5V and ground pins with MIDI transmit and receive pins, it became very common and it is generally available on game ports that are on sound cards or motherboards with integrated sound card, but not available on separate Multi I/O cards or motherboards without sound card hardware.

The other part about your question about the calibration is that the joystick detects the stick position with optical encoders, and the onboard MCU that handles the communications anyway needs to keep track of the optical encoder movement pulses, to provide the stick position digitally via MIDI serial interface, and since it likely offers standard analog joystick compatibility, it needs to have a DAC of some sorts to emulate a changing resistance to behave like a standard joystick with analog potentiometers. The optical encoders are likely incremental encoders, so they don't know the absolute stick position, so the joystick may just assume that when you power it up, it is in the center position, and then the MCU can track the changes to the stick position.

In general, there are many ways to extend the game interface.

The standard interface has only 4 digital inputs and only 4 analog inputs for measuring potentiometer resistance, and was mainly intended for maybe two joysticks with two buttons, or four paddles with one button. It technically has only input and can't be used for output, but there's a neat trick that can be utilized for output as well.

First way of extending the standard interface was to add digital buttons that were connected to more than one digital button input simultaneously, by simply adding diodes. This meant that the button input should not be decoded only as one button per input bit, but as a single code of 4 bits for 16 different states, one of them being nothing pressed, so that leaves 15 active states. This was used by some products to add more buttons and the POV hat (CH FlightStick). The downside was, that you could not press more than 1 of these buttons at any one given time, or it simply decoded to another function. The positivide side was, that you can have more buttons, and still have two analog channels left for e.g. throttle handle and rudder pedals, so good enough for e.g. slow paced flight sims.

Some other joysticks extended the standard features differently, for example, Logitech Wingman Extreme had 4 standard buttons, and the digital POV hat was connected to one analog channel via resistor network so it can be read as analog value. It did not use the fourth analog channel, it could have been used for throttle.

There is yet another way to extend the standard game port features, using a digital protocol of transferring data packets over the 4-bit digital button interface. Many different vendors had their own specific protocol, but the general idea is the same, make the gaming controller to go into mode where it can send digital data packets which the PC can read and decode into axis and button values.

As I mentioned earlier, the game port only has analog and digital inputs, but the analog axis input is basically a potentiometer with resistance, and the resistance is measured by charging a known capacitor through the resistance, and measuring how long a time it took for the capacitor voltage to reach a certain threshold. The analog input is usually done with discrete NE558, which is basically a quad NE555 in one package, or similar functionality may be integrated into sound card chipset, which may offer some hardware features to tune the process or accelerate it by having a hardware counter for measuring the time. So, when the software triggers the hardware to measure resistance, the capacitor voltage rises as it is charged by the resistance in the joystick. The shark-fin like voltage charging waveform can be detected by circuitry in the joystick to get a trigger pulse to know when the resistance measurement is being performed. This is used by the joysticks that use digital protocol to only send the digital packet when the software triggers the analog channel reading, and also the digital joysticks are not in digital mode unless a specially timed sequence of timing pulses are detected by the joystick.

One example of this kind of joystick is the Logitech Winman Extreme Digital. Since it has an MCU inside it, it can work in three modes. By default it emulates the standard non-digital Wingman Extreme which has 4 buttons, digital POV hat on 3rd analog channel and no throttle. The extra buttons can be used to configure it in CH mode, where the 6 buttons and POV hat data is sent over via the button interface, and the throttle is now sent on 3rd analog channel. With the special handshake sequence sent from the PC, the MCU goes into digital mode, where all the 6 buttons, POV hat, and throttle data are sent as digital data packets over the button interface to fully use the features of the joystick.

The next extension is then the MIDI sigals on the game port. The game port MIDI interface is an UART running at bit rate of 31250, and it uses standard TTL logic levels. It does not use RS-232 physical interface, and it does not use MIDI physical interface, as you always need a special MIDI interface cable with electronics to convert it to MIDI physical interface, which is an opto-isolated current loop. So basically, the MCU in the joystick can simply be directly connected to the MIDI UART pins and it can transfer any bytes at any protocol it wishes, as it does not have to use MIDI protocol, but the features can be implemented as MIDI messages, to allow the drivers or games to simply open a MIDI port and send standard MIDI events to control the force feedback.

Some joysticks use other ports in combination to achieve the features they need. Some joysticks have additional connections to standard RS-232 serial ports or keyboard/mouse ports for getting their communications done.

  • 2
    +1 for mentioning MIDI. I don't think most people appreciate MIDI as anything other than the format used in canyon.mid and some 90's era website background music. Even among musicians it's often disparaged unfairly. But it's pretty a pretty darn good protocol for input device data streaming, particularly considering how old and ubiquitous it is.
    – Darren
    Commented Aug 3, 2022 at 19:10
  • So, the Sidewinder Force Feedback Pro didn't use rotary optical encoders from what I recall. It was actually a domed housing with a textured pattern printed on it, and an optical eye that tracked movement within that dome, as I recall... I was a kid when I took mine apart, so I may be mis-remembering, but it wasn't your typical optical rotary encoder like found on mice. But I agree that it was probably handled and transcoded into some other signalling in the joystick before being sent off.
    – nabeelr
    Commented Aug 3, 2022 at 19:32
  • Also, thanks for the explanation. Seems to be the best one so far!
    – nabeelr
    Commented Aug 3, 2022 at 19:38
  • Thank you for actually explaining how the data got from the joystick to the computer. Commented Aug 4, 2022 at 16:36
  • 1
    @enorl76 In this case it just means that the joystick port has an UART wired to it for serial comms. It is intended to be used for having an adater to have stadard MIDI in/out ports to communicate with other MIDI devices if you are a musician, but instead it is used to communicate with the joystick for controlling the force feedback add-on.
    – Justme
    Commented Aug 4, 2022 at 18:21

You must log in to answer this question.

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