Saturday, March 8, 2014

Joystick Problems with DOS and Approaches to the Problem

IBM's Game Control Adapter was designed as something of an afterthought, a simple to use expansion card (for a programmer) as a way to provide for connecting a low-priority input device.  It sat at port 201, supported four digital inputs, intended for buttons and four analog inputs, intended for paddles or joystick axes.

When it was released as one of the original expansion cards for the new IBM PC, it was perfectly adequate for the time.  The Apple II joystick port operated in the same way but only supported three buttons.  The Tandy Color Computer also supported four analog axes and four buttons, and its joysticks were later used in the mostly-PC compatible Tandy 1000 line.  The Commodore VIC-20 only supported one Atari-style joystick or two Atari-style paddles.  Only the Atari 400 and 800, with their four joystick ports, supported more game inputs.

In IBM's design, a joystick is a pair of potentiometers which are turned by moving the joystick.  Each three-terminal, 100 kOhm potentiometer is connected through the joystick cable to a +5v line and a capacitor on the game control adapter.  This capacitor is tied to an input on the NE558 Timer IC.  The Timer compares the capacitance on its input with a reference capacitance, and outputs a 1 when the capacitance is not equal and a 0 when the capacitance is equal.  The resistance value from the potentiometer determines how quickly the capacitor on the input will be charged.  If the capacitor is turned to a lower resistance, the capacitor charges more quickly, and if turned to a higher resistance, the capacitor charges more slowly.

When the programmer wants to read the joystick position, he writes to port 201.  This discharges the capacitors.  Then the programmer reads and reads port 201 until there is a 1 for the axis he is trying to measure.  The time taken for the value to become a 0 represents the position of the joystick.  Many games have joystick calibration prompts requiring the player to move his stick to its maximum positions and its center to obtain the timing required to properly calibrate the stick.

Eventually the limits of the design began to emerge.  The first was that the joystick had to be read several times to get an accurate measurement of the stick's position.  This took a substantial portion of a 4.77MHz  8088 CPU's time.  However, when there was only one CPU and one speed used in PC and compatibles, this was just an inconvenience, because the timing would be equivalent on all machines.  For many simpler games, which relied on digital controls, fine measurement of the joystick axes was not an issue.  However, when faster CPUs and clock speed began to emerge, joystick routines would consequently run faster.  Thus routines would take 20% of the CPU's time an 8088 may only take 10% or less of the CPU's time on the more efficient 286.  When CPU speeds began increasing to 6MHz, 8MHz and beyond, routines that were designed for the IBM PC would complete themselves far too quickly to get an accurate read of the joystick.

A second issue with the inherent accuracy of the components used to determine the joystick's position. Linear potentiometers such as used in the PC are not known for their rigorous accuracy.  While the adjustment dials on each axis can help, they can shift or loosen over time.  Moreover, the housings containing the resistive element and wiper are not hermetically sealed or anything close to it.  Dust and dirt and oils over time can seep in and cause jittery or inaccurate reads.  Wear on the resistive element can make it harder for the stick to give an accurate resistance.

IBM gave a formula to measure the time the stick would take to charge the capacitor at any given resistance (0-100).  When it released the IBM PC AT, with its 6MHz 80286 CPU, it introduced Int 15, subfunction 84 to give a BIOS routine to read the joystick.  Unfortunately, the clone PC makers had already spent substantial time and money cloning the original IBM PC BIOS, and this new BIOS call did not necessarily make it into every clone.  Tandy 1000s do not support it.  The advantage of the function was to give reliable reads because the routine was tied to the processor and speed(s) which the system board was designed to run.

Other companies tried to offer solutions to these problems.  Tandy 1000 joysticks used the design from the Tandy Color Computer.  Instead of using the potentiometers as variable resistors, Tandy uses them as voltage dividers by connecting the third terminal to ground.  Inside the machine, the voltage is compared to a voltage ramp which, when port 201 is written to, is charged from 0v to +5v in a set period of time.  When the voltage ramp is greater than the voltage from the joystick, a 0 is reported.  This method has been said to give more precise and less jittery results than the timer-resistance method used on a true PC.

The Amstrad PC-1512 gave a unique solution to the joystick problem.  It supported one Atari-style digital joystick with two buttons.  This joystick plugged into the keyboard.  The directionals and buttons for the joystick were assigned to unique keyboard scancodes 7C-77.  However, when reported by the BIOS, pressing the directionals would give scancodes assigned to the cursor keys on the numeric keypad.  Since many, many games used the keypad cursor control keys for movement, this was a highly compatible way to implement digital input.  It would not work if the program read directly from the keyboard input port instead of the BIOS unless the program was Amstrad-aware.  The two joystick buttons could be assigned to represent any key through the use of a program which would write to the Amstrad's non-volatile RAM.  This memory would retain the buttons' settings until the next time the buttons' settings were changed.

When the Sound Blaster came along, it implemented a standard joystick port.  Until the Sound Blaster 16, the port did not change.  In the Sound Blaster 16, the old DIP-style NE558 timer was replaced with surface mounted components, which presumably have lower latencies which work better with faster processors. The Gravis Ultrasound implemented a hardware version of a speed adjustable gameport, and came with a program to adjust the sensitivity of the gameport without the use of an external dial or jumper.

Other companies made speed-adjustable gameports.  In these gameports, a dial would be routed outside the computer to adjust the speed of the gameport.  In the Thrustmaster ACM Game Card, the dial was a potentiometer which would adjust the resistance going to the reference capacitor.  The ACM Game Card had a second joystick interface at port 209, requiring a second NE558.  The dial controls the resistance for both reference capacitors.

The Gravis Gamepad was very popular in the early 90s because it provided four buttons and a NES-style D-pad.  However, inside the Gravis Gamepad were transistors to convert the digital values of a D-pad into the analog resistance values expected by the PC gameport.  Essentially pressing one side of the pad would give the maximum resistance value of the axis, the other side would give the minimum resistance value and not pressing the pad would give the middle of the resistance value.

Later joysticks, like the Gravis Gamepad Pro and the Microsoft Sidewinder gamepads would give options for truly digital controller with more than four buttons.  These sticks would use the gameport to send binary codes to the program.  The downside is that a DOS program had to have specific support for the gamepad, or the digital functionality of the gamepad would only work in Windows 95 with a driver.

Another late innovation was to take inspiration from computer ball mice.  Computer mice and trackballs use optical rotary encoders to track movement, just like the dials on most arcade machines, the Atari driving controller and the N64 thumbstick.  Reading from the encoders is much more reliable than the timer-potentiometer method and not prone to speed sensitive issues or the same kind of wear.  The Microsoft Sidewinder 3D Pro had this function and many buttons, but unless a DOS program understood it, it had to emulate the analog potentiometer method

Once IBM ceded leadership of the PC market, no other company came up with a standardized digital gameport solution.  Eventually, USB input devices of all kinds, gamepads, joysticks, driving wheels, rudder pedals, throttles, yokes put all the speed issues to software.  However, USB really didn't catch on until Windows 98, so for almost twenty years game players had to deal with the analog gameport.

No comments: