I've been working on Megadrive/Genesis & Saturn support for the last couple weeks. No new info here I would guess but I feel it's still interesting to document it in one place with my own reverse engineering and some help from SEGA's expired patents :) .

SEGA kept evolving the same 7 IOs interface for its controller from 1983 with the SG-1000 up until the fall of the SEGA Saturn in the late 90s. It got replaced by the Maple bus for the Dreamcast.

Keeping that interface for so long involved some nice trick for detecting the various devices SEGA came up with over time. Also various protocols from fully parallel inputs to the Three-Wire handshake was used.

I'll cover most input accessories except light gun.

Various expired SEGA patents describe those nice trick but let start from the beginning with the SG-1000.

SG-1000, Mark III & Master System

All three first SEGA consoles used the same interface derived from the Atari 2600 joysticks DE-9 ports. While maintaining joystick compatibility with Atari the pinout is a bit different. VCC is on pin 5 rather than 7 and the 2 paddle analog inputs are replaced with digital one.

I couldn't find documentation on the exact meaning of TL, TH & TR labels, I assume T is for trigger and so TL is probably for Trigger Left (Button 1/ Start) and TR for Trigger Right (Button 2). Not sure about the H in TH however this was the light gun light input.

All 7 IOs are input for the system.

Megadrive/Genesis

3 buttons controller

This is where the fun start! To add an extra 2 buttons while maintaining Master System compatibility the controller use a multiplexer to toggle between two banks of inputs. The switch is done via the TH pin that now become an output from the system.

The TH pin is pull up on a Master system so that will activate the right button bank for SMS compatibility. Some games like Alien Syndrome hold TH low, however, which prevents using the Genesis controller.

You may think that using an IC in the controller would break Atari compatibility due to VCC pinout mismatch. However the TH line is pull up to VCC inside the controller and the 2600 power output on the TH line will power the IC via that internal pull up as well as enabling the right buttons bank.

6 buttons controller

Again the goal here is to add an extra 4 buttons while maintaining compatibility with all the above!

It is done by modifying the banks content following 3 rapid successive read cycle. The third cycle will contain data to identify the 6 buttons controller (0x0 on RLDU while TH low) and the extra button status will be available on cycle 4 while TH is high. The extra buttons are trigger if 3 falling edge arise on TH within ~1ms.

To be able to detect between the 3 and 6 controller on the third cycle while TH is low the RLDU value will be 0x0, while for a 3 buttons controller it will be either 0x1, 0x2 or 0x3 since the dpad direction U and D are physically impossible to press simultaneously.

Games with non-standard polling pattern will have issue with this controller.

Official Multitap

The official Multitap introduce a serial protocol that will be used by most new accessories going forward. The Multitap higher level working is well explained in SEGA patent US5607157 but the low level protocol is better describe in patent US5872999A. The Three-Wire Handshake protocol works a bit like QSPI except that the clock (TR) from the system is active on both edges. TH from the system is used as the chip enable and TL is sent from the device to signal that RLDU lines are ready.

 RLDU value while TH is still high and immediately following the falling edge are used to identify the peripheral. I call the raw 8 bits value ID0 but the real value of interest needs to be computed to obtain ID1. For the megadrive/genesis multitap ID1 is 0x7. The ID1 one take advantage of D-pad direction from the same axis not being able to be press simultaneously and from some of the unused bits.

static uint8_t IRAM_ATTR get_id1(uint8_t id0) {
    uint8_t id1 = 0;

    if ((id0 & 0x80) || (id0 & 0x40)) {
        id1 |= 0x8;
    }
    if ((id0 & 0x20) || (id0 & 0x10)) {
        id1 |= 0x4;
    }
    if ((id0 & 0x08) || (id0 & 0x04)) {
        id1 |= 0x2;
    }
    if ((id0 & 0x02) || (id0 & 0x01)) {
        id1 |= 0x1;
    }
    return id1;
}

At the higher level the first two nibble sent are always 0x0 & 0x0. The actual data then start and a nibble for each of the multitap port is sent for identifying the device on each port.

0x0 for a 3btns pad, 0x1 for a 6btns pad, 0x2 for the SEGA mouse and 0xF if nothing is connected.

The format of the following nibble depends on the device connected. If no device is connected in one port, no data is sent for that port. No padding is used and 2 nibbles is sent for a 3btns pad, 3 nibbles for a 6btns pad and 6 nibbles for the mouse. 

EA Multitap

EA released its own multitap for it's sports games. This one require both ports to be connected to the multitap. All outputs from the tap come from port 1 on TR-TL-U-D-L-R, system control is done via TH on port one and TH-TR-TL on second port. Second port UDLR are not connected. So port 1 behave like a regular controller while the 3 control signal on 2nd port control which controller is active on port 1.

The tap look to be detected at boot time by pulling 2nd port TH high which will trigger the tap to put TR-TL-U-D-L-R low on the first port. 2nd port TH is always low other than that.

Each controller status is read in sequence at 200 us interval every frame. Data is read as usual by toggling port 1 TH to select the active buttons bank. The active controller is selected via TR & TL on the 2nd port.

Mouse

The mouse uses the same Three-Wire Handshake protocol as the multitap. ID1 is 0x3. As with the multitap the first 2 nibbles are fixed but to 0xF & 0xF this time.

The 4 buttons are in the 4th nibbles active high (unlike all the other accessories) and each axis take 2 nibbles.

As we will see later, the Saturn is compatible with all genesis peripheral. The Saturn mouse is actually nothing more than the Megadrive/Genesis mouse with its cable replaces for a Saturn one!

Some Genesis games support the Three-Wire Handshake improperly and rely heavily on the mouse timing behavior. Example Wacky World:

In this example trace above, we see that if BlueRetro set "data ready" (TL) the game go read the data too fast. You can see the select line goes back up much later as it's timing is hardcoded rather than following the protocol.

But why would the transmission fail in that example? Beside the games waiting for nothing everything else is ok, right? The game actually fail because it read the last data byte after releasing the CS line!! But in the above example the bus was already set back to the ID1 value.

If we add a 14us delay this fix it! But note that the game expect the TL line to go back high after CS is released.

Saturn

The Saturn switched from the old DE-9 connector to a custom 9 pin connector. The interface remains the same, however. The Saturn BIOS actually support all the devices including the Genesis ones. Simply making a DE-9 to Saturn cable will allow using 3btns, 6btns (including extra btns), the mouse and even the Team Player multitap in the BIOS! All Saturn devices are supported too including keyboard and multitap. Note that my Saturn is using BIOS v1.01, I'm not sure if all version support all devices.

Digital controller

The digital controller works a bit like the genesis 3 buttons pad but with an additional select line (TH & TR). TL is unused and data only output on RLDU. ID1 is 0xB.

Analog controller

The analog controller uses the same Three-Wire Handshake protocol as used in late Genesis accessories.

The big difference is that SEGA assigned a generic ID1 0x5 for all Saturn serial devices. 2 new serial protocols are also described in patent US5872999A but as far as I know no device actually used them. All 3 protocol generates the same ID1 value and so they are distinguished via the raw ID0 value.

The first nibble now is ID2 which will identify all devices that use ID1 = 0x5.

For the analog controller ID2 is 0x1. The following byte is the length in bytes of the data. A 0x0 followed by ID0 always end the frame.

One would expect the switch used to toggle between analog and digital mode to set same TH/TR selection protocol in the digital mode as used on the regular digital controller. However doing so keep using serial protocol but change ID2 to 0x0 and only buttons status is sent.

So it looks like support for the serial protocol was mandatory for all games. However Golden Axe: The Duel does not support this and so it's impossible to use the analog controller at all. Also I noticed in Bug! that in the intro FMV the game do not support the analog controller digital mode and so it's impossible to skip it! Digital mode work fine in gameplay however. Problems like this are probably limited to game around the Saturn release.

Multitap

The Saturn multitap work differently than the genesis one. No header identifies devices individually, they are instead identified by their ID2.

Essentially each controller data is appended one after the others. If no controller is connected to a port, then 0xF 0xF is reported for that port. Multitap ID2 is 0x4 and bytes length is always 0x1 but this is only the size of the multitap header. The first nibbles of the header indicate the number of port on the multitap (always 0x6). The following diagram comes from patent US5892974A.

Keyboard

Keyboard work like a PS/2 keyboard with make and break code at high level but using the Three-Wire Handshake protocol at the low level. ID2 is 0x3. See https://plutiedev.com/saturn-keyboard for more detail.

Megadrive/Genesis retro-compatibility

As I said in the intro, the Saturn BIOS is compatible with all Megadrive/Genesis accessories. Here a sample of the 6btns controller trace done in the Saturn BIOS:

The Saturn multitap also support Genesis devices. They are all reported with ID2 0xE. To tell between 3btns, 6btns and the mouse you need to look a the byte length. 3btns will be 1 bytes, 6btns 2 bytes and mouse 3 bytes.