Loose spec for multi-system classic gamepad adapter

The following draft description runs down the basics for a single port that allows the direct connection of Sega Genesis controllers and connection via a mostly passive adapter for several other systems’ controllers, including NES, SNES, PlayStation and PS2, Nintendo 64, and GameCube. Additional styles could be added later, and a structure is made available for controllers custom-built to this spec.

Connector

The host-side connector used is a DE-9M 9-pin D-subminiature connector. This is the same connector used by Sega Genesis and Master System, early Atari and Commodore controllers, and the 9-pin variant of the RS-232 serial port found on older PCs. This is a mature standard with connectors that are fairly compact, inexpensive, and easy to source, especially compared to the connectors for the other supported controllers.

Controllers not using the Genesis protocol are still electrically supported by the host hardware and are connected by or as if by using a mostly passive adapter (containing minor additional parts for self-identification purposes); a controller could also be modified to permanently incorporate such an adapter.

Connection

Pinout

Electrical implementation

• Pin 8 (ground) is always connected to ground. Connectors with a shield ground should have it connected to this ground as well.
• Pin 5 (V_aux/V_cc-Sega) must be capable of switching a 5V supply on and off for either a Sega controller supply or as the vibration motor supply for a GameCube controller. Complete implementations should also provide a nominally 9V supply for PlayStation controller motors.

With the exception of pins 5 (V_aux) and 8 (Ground), all pins have some I/O capability.

• Pin 9 must be capable of input, and must also be capable of outputting a supply voltage in non-Sega modes, nominally at either 3.3V or 5V depending on the mode. Buffering or level-shifting circuitry may be necessary to make this possible. These two capabilities are never required simultaneously. This line may also be capable of output.
• Pins 1 and 2 must be capable of input and may be capable of output.
• Pin 7 must be capable of output and is generally unusable otherwise.
• Pins 3, 4, and 6 must be capable of both input and output.
• Pin 3 must be capable of switching directions during the normal operation of a controller.

All inputs should be implemented with weak pull-up resistors (e.g. 33K or 47K), but they will generally be necessary only for the detection phase and, if it is possible to disable them from firmware, this may be done after detection.

Detection protocol

By default, the connector is held in a Sega-conformant mode, with pin 5 (V_cc-Sega) at 5V, pins 7 (select) and 8 (ground) at 0V, and all other pins (1,2,3,4,6,9) in input mode. The input pins are polled periodically to determine which, if any of them, has been pulled to ground. Multiple samples are taken some time apart to act as a debouncing mechanism. When a signal with at least one line of those six pins grounded has remained steady for about 100ms, the controller is considered connected.

If the controller is a Sega controller, pins 5 and 8 are the power rails and pin 7 is the select line. When the select line is low on a powered Genesis controller, the left and right lines (3 and 4) read as grounded. Therefore, if both of those lines read low, the other lines are ignored and operation continues as a Sega controller.

If the controller is not a Sega controller, it is connected via an adapter. With pins set as above, the controller is not powered up (the V_cc pin is in input mode). The adapter should contain, or behave as if it contains, an NPN transistor whose base is connected via a resistor to pin 5 (V_aux), whose emitter is connected to pin 7 (detect), and whose collector is connected to one of the six lines being read. (For multiple lines, multiple transistors could be used.) Pin 7 being grounded enables any such code transistors, allowing a crude self-identification code to be read. After this code is read and recognized as a valid non-Sega controller type, the system raises pin 7 to disable the code transistors, then turns off V_aux, and finally raises V_cc to either 3.3V or 5V, depending on the mode selected.

Possible detection codes

1	2	3	4	6	9	Code Meaning
*	*	L	L	*	*	Genesis (extra bits ignored)
L	H	H	H	H	H	PS/PS2 5V
L	L	H	H	H	H	PS/PS2 3.3V
H	L	H	H	H	H	N64/GameCube 3.3V
*	*	L	H	*	*	NES/SNES (with 4-bit controller variation code)
H	H	H	H	L	H	Custom-H 5V
H	L	H	H	L	H	Custom-H 3.3V
H	H	H	H	H	L	Custom-F 5V
H	L	H	H	H	L	Custom-F 3.3V

• PlayStation controllers’ nominal voltages are variously reported as 3.3V and 5V. Most controllers reportedly work with either, but in the event that one or the other is required, a code transistor on pin 2 could be connected via e.g. a DIP switch and included or excluded as necessary.
• The custom modes are also available at either supply voltage by the same mechanism.
• NES and SNES controllers are electrically identical. The available 4-bit identifier is a cue to the firmware which sort of controller it might be using. Among the important variants are the NES gamepad (8 bits read), the SNES gamepad (16 bits read), Zapper (alt data pins, no serial), Power Pad (alt data pins, serial), Four Score/Satellite (reportedly 24 bits serial), and probably others. HHLHHH probably directs the firmware to read a gamepad and a Zapper simultaneously since they share no lines. The SNES pad would require only an additional transistor (perhaps LHLHHH) because it is also common. All NES-type controllers run at 5V.
• N64, GameCube, and PS/PS2 controllers and custom-mode controllers have their own protocols that include provisions for self-identification. The controller itself will be queried to determine whether V_aux is required. GC V_aux, if enabled, is always nominally 5V. PS/PS2 V_aux, if enabled, is always nominally 9V. Custom-mode controllers may request either voltage for V_aux and optionally others.

Custom controller modes

This draft provides for electrical connection of two custom modes of controller, called Custom-H and Custom-F. The pinouts and protocols for these are not fully defined at this point, but the goal is to provide an easy means to construct novel controller designs without an extreme amount of design complexity on the controller side. A data protocol is intended to be provided that allows a custom controller to identify itself, specify its configuration, and request a level of V_aux for additional power.