Why the Genesis controller works on the Atari?

[Andromeda Stardust]

Something weird occurred to me while studying the Atari and Genesis pinouts. First some background info (you can skip this if you want)

 

So far, I've made homebrew Arcade controllers for the NES and Atari using off-the-shelf parts. I'm also in the process of building an SNES controller as well and I have future plans for a Genesis 6-button model. The arcade controllers are modeled after their real life counterparts. The NES, SNES, and future Genny controllers are all made from 18x8x4 inch plywood boxes. The Atari controller is a 8x8x4 inch square. The NES and Atari arcade joysticks use an Ultimark Mag-Stik which can be switched on the fly between 4-way and 8-way operation. The SNES and Genesis arcade joysticks will use a Happ Competition (8-way), since the usefulness of a 4-way joystick on a 16-bit console is questionable. All my controllers utilize detachable extension cords to connect to their respective consoles.

 

The NES arcade controller (my first arcade controller project) had a special digital turbo control which I designed from the ground up, using a 4-bit counter for speed selection, and a 555 "one stop" timer (tuned for about ~5ms) to prevent malfunction on games that poll the controller multiple times per scanline. It works flawlessly on the original NES as well as the RetroUSB adapter (which polls the controller at 120Hz instead of 60Hz - as a result, the turbo function runs twice as fast on the USB adapter).

 

On the Atari arcade joystick, I recently added 1M-ohm Paddle wheels to the sides in addition to the joystick controls, fully utilizing all nine pins on the DB-9 connector. Additionally there are three switches in the back, one to disconnect both paddles, and two more switches to optionally reverse the movement on the L & R paddles individually.

 

The SNES arcade controller features light up buttons that glow when pressed, and a switch to optionally disable the LED lamps. Custom breadboard includes a no nonsense textbook schematic including two CD 4021 chips.

 

Finally, my future Genny project will use a toggle switch for 3/6 button operation rather than holding down the "mode" button at startup. It will also use a separate smaller RadioShack pushbutton for access to use the "mode" switch as additional input while in 6-button operation. Sadly, a working schematic for a true 6-button Genesis controller is not available and/or is ridiculously complicated, so I will be committing treason against retro preservation purists by sacrificing an official 6-button Genesis controller and wiring the arcade switches directly to the contact pads.

 

You can view photos of the arcade controller projects here:

http://www.flickr.com/photos/30203515@N04/sets/72157629736738048/

 

Back on topic, now for the bizarre part of the whole thing:

 

As many of you may well know, the Genesis 3-button controller works nicely as an Atari VCS gamepad, with "fire" being tied to the "B" button, and a VCS joystick will activate A+B on the Genesis. What you may not realize is that the Genesis/Atari pinouts share a common ground but have VCC +5V wired to different pins! The select line of the Genesis Controller, pin 8, is actually VCC on the Atari console. Pin 5 is VCC on the Genesis console, which is actually the left Atari Paddle analog input. The right paddle input is tied to the "C" button on the Genesis gamepad whenever the select line is held high, or "Start" whenever select is held low. Because the Atari VCC is tied to the "Select" line on the Genesis controller, select is obviously always held high.

 

I was reading some documentation on the Genesis / Sega Master System controller formats the other day, and I noticed that the "Select" line (pin 8 on the Genesis 3 button controller is held high by a pull up resistor whenever it is left disconnected. I assume this is to maintain backwards compatibility with Master System games: when "Select" is high, "B" and "C" correspond to the default action buttons on the SMS controller. By some sort of lucky coincidence, this same pull-up resistor also holds the VCC input high on the Genesis controller when the "Select" line is connected to +5V (it also has the beneficial side effect of permanently triggering the "paddle connected" flag by holding the left paddle input high, allowing homebrew games the option to use this flag to detect the presence of a Genesis controller, enabling a custom software kernel to poll the right paddle input in order to detect whenever the "C" button is pressed). Despite being a kind of @$$-backwards circuit logic, this pullup resistor presumably passes enough current to allow the 74HC157 logic chip (and the custom 6-button chip as well) to operate properly, despite the fact that the wiring for the Genesis controller is totally incorrect whenever it is plugged into the Atari.

 

In summation, the SMS controller works on the Atari, and the Genesis controller was designed to be backwards-bompatible with the SMS system, so with the help of some dumb luck and electrical voodoo magic, the Genesis controller also works on the Atari. Effing sweet, because the Genny 3-button gamepad is the third best gamepad around (it is bested only by the NES and SNES)!

 

And the Genny pad is certainly a far cry from the VCS CX-40, which is one of the worst joysticks on the planet.

 

Also the sucky CX-40 joystick was my primary reason for building the arcade controller to begin with, which I use almost exclusively on my Atari.

Edited April 2, 2013 by stardust4ever

[RevEng]

You don't need a special kernel as such to read 2 buttons - just some non-kernel asm code. But one should ensure that the paddles don't get grounded during vblank; a minority of genesis pads have multiplexer chips that don't recover within a frame if the +5v gets removed.

 

Some related reading: reading 4 buttons on a sega genesis controller.

[Andromeda Stardust]

You don't need a special kernel as such to read 2 buttons - just some non-kernel asm code. But one should ensure that the paddles don't get grounded during vblank; a minority of genesis pads have multiplexer chips that don't recover within a frame if the +5v gets removed.

That would explain why the "C" button read for both my 3 button Genesis controller and Sprybug's Genesis controller worked during beta testing of the ROM for Princess Rescue, but other people who used the six button controllers or even a different 3-button Genesis controller on a different Atari, swore the Genesis "C" button functionality was completely broken:

That's exactly what I was using when I made this video as "proof" that the Genny controller worked, but other users swore it didn't.

http://www.youtube.com/watch?v=gm_cpH806Ss

The culprit was that the default Batari Basic kernel Sprybug used to program the game was draining the Paddle inputs during V-blank. The solution turned out to be a very simple ASM fix.

 

I don't know what the exact value of the pull-down resistor is, but my future Genesis arcade controller will use two LED lights to indicate 3-way/6-way operation. I have the schematic worked out in my head: the center tap of the "mode" toggle switch will be connected to ground. I use a toggle switch, so that the switch can be set prior to booting the Genesis console or plugging in the controller. There is no need to remember to hold down the switch every time I boot the game console. Each poll will be tied to the minus side of an LED lamp (with inline resistor, rated for 12V max), one yellow and one red. The plus side of each lamp will connect to Genesis VCC. The minus side of the red lamp also connects to the MODE input on the PBC, while the minus side of the yellow lamp will float whenever the switch is open. The net result is the yellow LED will illuminate when the mode switch is in the 6-button position (MODE = high/open), and the red LED will illuminate when the mode switch is in the 3-button position (MODE = low/closed). Both LEDs will illuminate if the accessory MODE button is momentarily pressed while the switch is in 6-button mode. The resistor inside the LED lamps will likely drain more current than a standard 10k pull down resistor can provide to the circuit. If the value of the LED resistor << the value of the pulldown resistor, then it would likely cause the voltage across the Genesis chip to drop well below the 5V nominal operating voltage and potentially cause the controller to malfunction. This might cause compatibility problems if I want to use my custom arcade controller on the Atari, and I do plan on adding a bright red Atari FIRE button (to be wired parallel to the Genesis "B" button) in the upper left corner of the joystick.

 

Duh! I just worked out the solution in my head while composing my post: If I add a reverse-biased diode to the schematic (negative end on the Genesis VCC+, positive end on the Genesis SELECT), then it will have absolutely no effect if the controller is used in conjunction with the standard Genesis pinout. When the Genesis arcade controller is connected to an Atari console (with +5V improperly wired to the SELECT line and the VCC supply line connected to the left Paddle input), the reverse biased diode will maintain a minimum of +4.4V across the 6-button Genesis VCC input at all times. And since the paddles will often short this pin to +5V when rotated all the way clockwise, there's no risk of damage either. I love electronics!

 

Some related reading: reading 4 buttons on a sega genesis controller.

So it is in fact possible for the Atari to access all of the original buttons on the Sega Genesis 3-button controller? WOW!

 

...Oh, I read the link and it seems you have to modify the controller to do it. If you want more buttons, you might as well use the console switches or a numeric keypad.

Edited April 2, 2013 by stardust4ever

[RevEng]

...Oh, I read the link and it seems you have to modify the controller to do it. If you want more buttons, you might as well use the console switches or a numeric keypad.

 

Its not as effortless and universal as something pre-built, to be sure. But swapping two wires and adding a resistor between them in a less-than-$5 controller is in bundled-with-cart territory.

 

It's also possible to modify an adapter to do the same thing, but I don't think it would be significantly cheaper than a modified controller.

[Andromeda Stardust]

Its not as effortless and universal as something pre-built, to be sure. But swapping two wires and adding a resistor between them in a less-than-$5 controller is in bundled-with-cart territory.

 

It's also possible to modify an adapter to do the same thing, but I don't think it would be significantly cheaper than a modified controller.

It is a great idea none-the-less. But one thing a programmer must also consider is how many people will realistically have the modded controllers at their disposal? Another issue is how much CPU resources will the controller polling process eat up? The VCS was a pretty gimped system from the start, but that's part of the retro appeal. Most advanced homebrew games use nearly every cycle of CPU time allotted to them.

[RevEng]

Yep. It's really best to bundle it with a game rather than expecting people to do the mod.

 

It takes 3 cycles per genesis button check. There are over 5000 cycles available in non-kernel parts of an NTSC frame; CPU isn't really an issue here.

 

There's actually more of a CPU hit for reading+decoding keyboard, paddle, or driving controllers.

[Andromeda Stardust]

I can understand keyboard because the system has to poll the inputs with an actual signal rather than just passively read the joystick states. With paddles, you have to sit and wait for a cap to fill up with charge, and count the number of cycles required to do so. But reading a driving controller is no different than reading a joystick. If fact, it should be faster because there's only 3 inputs to poll instead of five (because left and right aren't used). What the game engine does with those logic states after it reads them is another story. The last binary encoded value would have to be stored in RAM (2 bits) and compared to see if it has changed. In the case of Indy 500, if the value has changed, is it clockwise or counterclockwise? Then you make necessary adjustments to other variables. But that is all in the game logic. The actual reading of the controller itself would be no slower than a joystick. It's not how the Atari reads the joystick; it's what it does with the input signal that makes the game great.

[RevEng]

Reading the Gray code bits the driving controller returns is pointless unless you compare them to the previous bits. Without that comparison it won't operate as a driving controller. If you need to do operations on the controller data before that data is actually useful, you need to include the time for those operations in "time to read+decode" the controller.

 

Certainly reading driving controllers is closer in time scale to reading joysticks or genesis controllers when compared to paddles or the keyboard controllers. I was originally just making the point that one doesn't need to worry about using 3 cycles per button, as it's shorter than many other viable options. Nobody is sweating 3 cycles here or there per-frame in non-kernel time.