UniCon (Universal Controller Adaptor) W.I.P.

[Howard_Casto]

I'm having a go at making my own universal adaptor.  Please see the "what would you like in a console adaptor" thread for more info.  

In any case I'm going to document my progress both in the hardware and software in this thread.  

I will also post logic routines on how to get all of the various controllers interfaced.  There are quite a few site on the net that describe protocols and pinouts for various controllers, but they don't do such a great job of explaining the best way to "fake" the console in question so that you can just plug in a controller and it will work.  I will try to help with that.


Please check this thread for status updates.

Current Status:  Planning / Research Stage and Hardware Testing

[Howard_Casto]

Notes, General:

The first thing you need to understand is if you are making a uinversal adaptor for all (or most) consoles you will need dip switches.  I will reserve 8 for dips which gives me a maximum of 64 combinations with two pins left over for special modes and thus a total of 256 different controller types.  That should be more than enough.  Keep in mind that once you've scanned the dips upon startup, you can free the rest up and use them as inputs.  

This is also why I chose to put a db25 connector on the avr and make individual socket panels for each console.  I can solder the appropriate dip positions closed, thus eliminating the need for the user to have to set settings when changing controller type.


Another approach could be used that would reduce the needed pin count from 8 to 1 but it's a bit risky.  A person could use a single analog pin, and instead of varying the combinations of pressed pins, one could simply put a different valued resistor on the pin for each pinout.  The downside of coure would be that a under powered usb port could get the wrong value and over time resistors fail which could also cause issues.  It is, however a valid and rather elegant approach.

[Howard_Casto]

Notes:  NeoGeo

NeoGeo controllers connect to a standard db15 computer connector.  This is the gameport that used to be on the back of sound cards for the lamens.  

The pinouts are as follows:

1=GND/Common
2=None
3=Select Button
4=D Button
5=B Button
6=Right
7=Down
8=+5v
9=None (Actually Reports the status of the d-button as well for some odd reason)
10=None
11=Start
12=C Button
13=A Button
14=Left
15=Up

If you want to start with an easy controller to interface with this is the one.  The inputs are straight up switches with no circuitry.  Because of it's simplicity and safeness (no voltage or analog values to muck up the usb reports) I will have my adaptor default to neogeo mode.

On top of that on the controller end of things, there is only one type of neo-geo controller, at least electrically.  You have a 4 button controller and that's it... nothing else was ever released.  Now later on that made it in a gamepad form and used the 5v to power the auto-fire option, but still, one controller type and that's it.      

Also note that if you want to give users the option to build their own joysticks this is the interface you should give them.  With the unused pins you have the ability to make a 7 button joystick with a start and select/coin button as well as having 5v available for more exotic stuff like optical gates (gorf joystick, ect).  So I suggest pins 2, 9 and 10 be wired up to buttons "E", "F" and "G" just in case the user wishes to take advantage of them.  

It should also be noted that this is a lot of pins for the typical AVR to handle.  Even if the avr can handle the pins, your generic connector probably can't.  

The solution, at least in theory is to use a matrix.  Setup two ground lines, one for each player.  Set them up as outputs.  Wire both player 1 and player 2's buttons to the same pins.  Now you should be able to "turn off" (set low) one ground at a time and read the button values for each player.  This reduces our pin count from 30 to 16.  You could also expand the number of players from 2 to 4 (again, for custom sticks) and only use 18 pins.  


Notes:  Atari 2600

The Atari is equally simple to interface, but due to the fact that there are several different controller types and no real way to auto-detect them you might need to include a settings switch/button to select controller type.

The Atari uses a standard db9 connector port (a PC serial port)

The atari port has 6 unpowered pins (1-4 & 6) and a digital ground (pin as well as two analog inputs (pins 5 & 9) and +5v (pin 7) that is used in place of a ground for the analog ports and as power for any chips.  As you'll see below though, often the analog pins are also used as digital pins.  This is no big deal as when the digital button trips the pin it will just show up as full "on" via an analog read.  

We can actually use this to our advantage, by also turn on a digital button for our usb joystick whenever the analog value is full on.  


Pinouts are as follows:

Joystick/Paddle/Booster Grip (Omega Race)/Lightgun)

Joystick /Trackball (trackballs on the 2600 are an emulated joystick)
1=Up
2=Down
3=Left
4=Right
5=NC
6=Fire
7=+5v (Note:  Not used by standard joystick, BUT 5v is needed to power third party controllers with auto-fire chips)
8=Ground
9=NC

Paddle (Tennis Controller)

1=NC
2=NC
3=2p Fire
4=1p Fire
5=1p Axis (Grounded to pin 7)
6=NC
7=+%v
8=Ground (For fire buttons ONLY)
9=2p Axis (Grounded to pin 7)


Booster Grip (Omega Race Controller)

First note that the booster grip is just a slip-on grip to the standard joystick, it simply adds two extra fire buttons.  Many third party controllers use this pinout though.

1=Up
2=Down
3=Left
4=Right
5=Front Trigger (Grounded to Pin 7)
6=Fire
7=+5v
8=Ground (Digital inputs ONLY)
9=Top Trigger (Gounded to Pin 7)

Lightgun

1=Trigger
2=NC
3=NC
4=NC
5=NC
6=Light Sensor (Grounded to Pin 7)
7=+5v
8=Ground (Trigger ONLY)
9=NC

Racing Controller

Note that thus far the racing controller appears to simply use two data lines to emulate a quadratic encoder (think spinner in mame terms).  

1=Data1
2=Data2
3=NC
4=NC
5=NC
6=Fire
7=NC
8=Ground
9=NC

Without going into much detail, data 1 and data 2 send either a 0 or a 1 on each line in various patterns.  Comparing the last set of the data to the current set allows you to determine the direction and possibly speed (though in this case the "spinner" is too low-res for any real speed data).  

Although it is impossible to detect a racing controller at startup, due to unknown spinner position, it IS possible to detect it on the fly.  One of the encoder patterns will be 1,1 (both pins pressed) and since up and down can never be pressed at the same time, we know a racing controller is inserted anytime we see both up and down pressed at once.

Also note that essentially all 2600 controllers (with the exception of keypad controllers, which I will cover in a sec) fall into one of these categories, regardless of their shape or control type.

Also note the fact that each controller type uses the same pins for wildly different uses.   The paddle, joystick and lightgun controllers can coexist with the same protocol quite nicely as they use the same pins for digital and analog outputs.  Only the pin orders are mixed up.

One could auto-detect paddle controllers in the Atari's start-up routine by checking for an analog value on pins 5 and 9.  If there is an analog value on either of those pins map pins 3 and 4 to buttons instead of directions, otherwise default to the joystick mappings.  Alternatively anytime we see pins 3 and 4 pressed at the same time, we can assume paddle controllers are inserted as well, considering left and right can never be pressed at the same time.  The lightgun uses an odd pinout, but considering the rarity of lightgun use it should be OK to assume a lightgun is a joystick and just have the user map the trigger to the up button in their emulator.  

Now the omega race controller is using the pins normally used for analog axis to add two more buttons to the joystick.  We can probably auto detect for that as well.  Again, check for analog values upon start-up, if we are in "joystick" mode map the two analog pins to fire buttons.  

Now we will need to have a switch/button to detect the final type of 2600 joystick as there isn't a way to auto detect it... namely the "keypad" class of controller.  

It uses the pins as a 4x3 matrix.  Pins 5,9, and 6 are the columns and pins 1-4 are the rows.  To read it you setup the columns as outputs and turn on one at a time, getting the value of 4 of the buttons from each column.

The grid is like this

    5|9|6
1 |1|2|3
2 |4|5|6
3 |7|8|9
4 |*|0|#

Pin 7 connects +5v to pins 5 and 9, as they need it to work.  A resistor is put on lines 5 and 9 inside the controller giving a very specific voltage  on those pins.  It could be used for detection, but it probably wouldn't be that accurate.

One final note is that virtually all game consoles prior to the NES use some form of the 2600 pinout.  Even if you need different connectors, you can essentially use this protocol for all pre-nes consoles.  Simply rearrange the pins as needed.

Notes:  Atari 7800

The 7800, for the most part uses the same protocols as the 2600.  It also uses the same port.

The standard controller has a digital joystick and two buttons.  (This next bit is unconfirmed) For backwards compatability with 2600's and their games, both buttons are also connected to the digital "Fire" pin.  So essentially, this controller shows up as an omega race controller.

Standard Controller Pinout:

1=Up
2=Down
3=Left
4=Right
5=Right Button (Grounds to pin 7)
6=Fire (Either Buttons)
7=+5v
8=Ground
9=Left Button (Grounds to pin 7)

How do both buttons ground to the analog pins AND the fire button without issue?  To be frank it doesn't concern us, so long as they work.  It's probably a double switch or a internal chip or something.  Regardless, we can treat a 7800 joystick as a omega race controller and not worry about it.  Just keep in mind that on our usb joystick button 1 will be EITHER button on the controller and 2 and 3 will be Left and Right respectively.


Notes:  Vectrex

I just want to point out how silly supporting Vectrex controllers is.  Vectrex controllers currently go for 100 bucks on ebay and since the first controller is hard-wired to the console you would have to buy two, for a total of 200 bucks to play a two player vectrex game on the pc, which I might add, will NEVER be able to properly replicate the vectrex screen on a raster monitor.  So while it is possible to support, I can't really see anybody ever using it.  

The vectrex uses the 2600 db9 port as well as a modified 2600 protocol.  The controller itself has an analog joystick and 4 buttons.

Vectrex pinout:

1=Button 1
2=Button 2
3=Button 3
4=Button 4
5=X Axis
6=Y Axis
7=+5v
8=GND
9=-5v

Now the odd thing about the vectrex protocol is that it uses -5v.  
According to gamesx.com:  

"The joystick potentiometers work by voltage division between -5V and +5V. Actually, it uses a couple of resistors on each side to make it more like -3.4V to 3.4V."

Wha?  Wiring diagram please?  I mean it is possible, you can hook three wires up to the typical pot and I suppose you could hook -5v to one end +5 to the other and send the middle wire to the axis pin, but the question would be why, considering you could just ground the pin like on the atari.  For our purposes, it might be possible to simply ignore the -5v line and ground the -5v pin instead.  That would give us a voltage range of 0 to 5v instead of -5v to 5v.  It halves the resolution, but it could work ok.  It would have to be tested.

Regardless, this -5v poses a problem for adaptors.  You can't get -5v off of USB so you would need a wall wart that supports negative voltages.  It seems like a lot of work for a controller that is so expensive most people won't have one.


Notes:  Sega MS/Genesis

For whatever reason Sega thought it would be a good idea to make their controllers backwards compatible with the 2600 and they are.  Unfortunately they put the +5v on a different pin, making it dangerous to use most Atari controllers on a Sega console.  Regardless here is the master system pinout.

Most Sega consoles use a standard db9 connector port (a PC serial port)

1=Up
2=Down
3=Left
4=Right
5=+5v
6=Button 1 /Light Sensor (light phaser)
7=Trigger (light phaser)
8=Ground
9=Button 2

Note that like many consoles, the signal is inverted, so 1=off and 0 = on.  

The genesis pad uses the 7th pin from the Genesis model as a "select" line.  It is set to an output and the rest of the pins give one set of values when pin 7 is on and another when it's off.  For six button pads the select pin is turned on and off one more time, the third time gives the values of the last three buttons and the 4th time resets the internal chip.  

The pinouts for genesis pads are as follows:

1=Up/Up/Z
2=Down/Down/Y
3=*/Left/X
4=*/Right/*
5=+5v
6=A/B/*
7=Ground
9=Start/C/*

(*= always in a "pressed" state)

So with a bit of effort an auto-detecting, on-the-fly parsing function for all Sega pads can be made.  

You would:

1.  First setup pin 7 as an input... check to see if it gives off a "1"... if it does then a light phaser is connected and you are done otherwise....
2.  Setup pin 7 as an output... set it low to read the first values of pins , if pins 3 and 4 are pressed then it's a genesis controller (left and right can't be pressed at once) Otherwise it's a master system controller, you can read the current values of the pins and you are done.  

3.  If it is a genesis controller, go ahead and change the select line 3 more times.  You can go ahead and use the values from the third pass as z y and x since if you do have a 3 button controller, it won't matter about the erroneous data (those buttons won't be used in your emulator).  Unfortunately, there isn't a way to know for sure if a genesis controller is a 6 button or 3 button, thus the inclusion of a "mode" button on a genesis pad.    Now for a one time check at start-up, we can be fairly certain.... if on the third pulse immediately after plugging the controller in pins 3 and 4 are "pressed"    again then it's a 3 button controller, otherwise it's a 6 button as "X" should be open on the third pass.

Note that the saturn pads simply expand upon this same protocol even further, but since they need a different connector, we might as well just use a dip switch to put things into "saturn mode".


Notes:  NES/Snes

The nes and snes are both serialized controllers, both use the same protocol and both have 7 pins.  The only difference is that the snes has more buttons and thus you read the serial signal longer.  

The pinouts are as follows

Nes:

1=+5v
2=Data 2
3=Data 3
4=Ground
5=Clock
6=Latch
7=Data 1

Snes:

1=+5v
2=Clock
3=Latch
4=Data 1
5=Data 2
6=Data 3
7=Ground

How you parse a nes/snes controller is quite simple.  First you set "latch" to high and keep it high.  This tells the chip in the controller to gather the current button states.  Now you set clock low (it's normally high) once and get the value of the first button via "Data 1"  (0=pressed) and repeatedly set clock high and low again until you have retrieved the value of every button.   Once you get it, set the latch low and then high again and repeat the process anytime you wish to get the status of the gamepad

The serial data for nes is in this order:

A
B
Select
Start
Up
Down
Left
Right

For the snes serial data expands from 8 bits to 16 and is in this order:

B
Y
Select
Start
Up
Down
Left
Right
A
X
L
R
*
*
*
*
(*= always high)

It should be noted that if you try to set the clock pin more times than there are inputs, the value of data 1 will always come back as "pressed".  We can use this to tell if we are dealing with a snes or nes gamepad.  We can read a full 16 bits... since the nes only has 8 buttons, bits 9-16 will come up as pressed.  Since the last 4 bits on a snes controller are NEVER pressed, we know that it must be a nes controller if they come up as pressed and a snes if they don't.

Pretty nifty eh?

The snes mouse expands even further, from 16 to 32....the first 16 mimic the snes gamepad with the following exceptions:

1.  Positions 9 and 10 (normally buttons A and X) report the values of the left and right mouse buttons.
2.  Position 16, is held low instead of high.  This is how we can tell it is a mouse  as 16 will NEVER be low.  

Bits 17-32 for the mouse are as follows:

Y Direction (0=up 1=down)
Y bit 6
Y bit 5
Y bit 4
Y bit 3
Y bit 2
Y bit 1
Y bit 0
X Direction (0=left 1=right)
X bit 6
X bit 5
X bit 4
X bit 3
X bit 2
X bit 1
X bit 0

The 7 bits for x and y are the amount of motion since the last poll.  Please note that these values are inverted (1 = off, 0 = on)

The super scope probably uses the same protocol as the mouse or something very similar but I'm not sure yet.  





The data lines 2 and 3 are used for special controllers.

For the nes zapper, they are used as unseralized "straight" pins.  

Data 2 is the light sensor, which BTW is NOT inverted (1=light 0=no light )

Data 3 is the Trigger, which is inverted as normal.  So it is quite simple to auto-detect a zapper... when doing the initial serial check of Data 1, everything should come up "0" (which is impossible unless the controller is unplugged) but data 3 should be a "1"

The nes power pad uses data 2 and 3 in a serialized fashion to get the data from the extra buttons.  While you are strobeing on and off the clock line, the power pad sends serialized data down  2 and 3 at the same time but NOT the normal data 1 line. So again, detecting a power pad is easy.  Read all 8 bits and if data 1 is all 0 (which again, is impossible) but you get some 1's in data 2 AND data 3 then it's a power pad

This is the data you get: (the numbers refer to the labels on the power pad on the numbered side)

Data 2|Data3
*        |7
*        |11
*        |10    
*        |6
8        |9
12      |5
3        |1
4        |2

(* = always low)



The Vaus (arkanoid) controller, snes super scope and konami justifier all make use of data 2 and 3 as well, but I haven't found a lot of info on them.  The power glove also makes use of data 2 and 3, but only on the official power glove game.  It would be interesting to go ahead and get this working though as it essentially gives use access to the raw finger data on the glove.

Some misc notes about the nes/snes protocol:

1.  Afaik only one "special" controller is ever supported at a time as far as the games are concerned.  This is probably due to the fact that controller 1 on      the original famicom was hard-wired into the system.

2.  98% of all games expect the "special" controllers to be plugged into controller port 2.  Again this is due to the original famicom design.

3.  Due to the universal way that all nes/snes controller operates the same 5v,gnd,latch and clock for all controller ports and read multiple controllers at once.  Also because of this you can add player 3 and 4 (and on the snes 5) ports with just one extra line per player.  (Data 2 and Data 3 aren't needed on anything other than ports 1 and 2).

4.  Because of #3 it is probably simplier to just add 4 (or 5) ports to the adaptor rather than adding multi-tap support, which would needlessly complicate the start-up detection.


Notes:  Tg16/Turbo Duo/PCE

The turbo grafx family of consoles use a protocol similar to the genesis.  They use either a 8 pin Din or a 8 pin mini din as a controller port.  

The pinout is a bit unclear, but afaik it is this:

1=+5v
2=Up/I Button
3=Left/II Button
4=Down/Select Button
5=Right/Run (Start) Button
6=Select Line
7=Reset / (Also Auto Fire Pulse)
8=Ground

Again, like the genesis controller there is a select line that is used as an output and again depending upon the value of the select line you'll get either the values of the d-pad or the buttons.  Altough the speed of the pulse isn't important, in terms of reading the pad, it is in terms of the auto-fire function.  Apparently you should pulse high the Reset pin every time you wish to check the status of the buttons.  This acts as a timer for the internal autofire chip as well as resetting the multiplexer.  

Also like the genesis, there is a 6 button variant of the gamepad.  No special pulse technique on the select line is necessary though.  Every time you change the select line you will randomly (NOTE:  random isn't the best choice of words, but as far as I can tell there isn't a way to detect which group will be sent) be sent the above values (U  L  D R, I II S R) or (- - - -, III IV V VI) where "-" equates to a pressed signal.  Since all the directions on a d-pad can't be pressed at once, we know that when the first set of data we get is all pressed, we are getting data for the other four buttons.  

Because of this very unique protocol, pad identification is done as the controller is parsed.  We simply leave the last three buttons unpressed unless we happen to get a "all pressed" signal on the first poll, in which case we fill in the values of the other 4 buttons.


Notes:  N64/Gamecube

Much like the NES/SNES  share the same protocol, so do the N64 and GC.  The sent data is diferent, but the way that it is sent is identical.
The pinouts are as follows:

N64 Pinouts:

1=+3.4v
2=Data In/Out
3=Ground

GC Pinouts:

1=+5v (for Rumble)
2=Data In/Out
3=Ground
4=Ground (Only used in 3rd party controllers)
5=??
6=+3.4v
7=Ground

As you can see, even though the gamecube controller has more pins, they are all used for ground, so it is essentially the same pinout.  Something to note is the unusual voltage.  Almost all controllers work on 5v, but these two work on 3.4v.  Using a voltage regular is an option, but it should be done to the connector itself and NOT the avr as everything else will need 5v.  Another option is to simply use some resistors.  It is unknown if running 5v through a controller will hurt it or if voltage effects the clock speed.  

The only pin you will really be dealing with is the data pin.  It is bi-directional, meaning that it serves as an input AND an output.  What you do is set the pin as an output, send a serial message telling the controller what you want, IMMEDIATELY set the pin back as an input, and read the data.

The reason you need to set the pin back right away is due to the insane speed at which the controller sends data.  It is a standard serial protocol with each bit signaled as a series 4 high and low pulses 1us in length for a total of 4us per bit.  That's FAST!!

Now officially, the bits are as follows:

0=low,low,low,high
1=high,high,high,low

This isn't the case in reality though.  Because the transmission rate is so fast the signal can get a bit dirty depending upon the type of controller and the manufacturer.  I know from personal expenience that even official n64 controllers can have a different timing from this.  

Sometimes it is a bit faster or it lags like so:

0=low,low,high,high
1=high,high,low,low

The solution?  Well we just need to take a 4us sample and ignore everything but the last 1us, comparing to make sure there was a transisiton at some point from low to high or high to low, with the last part of the transition being the inverse of the actual bit value.  

Here is an example of how I would read incoming data:

Lets say your are expecting 8 bits of data.  You should immediately set the data pin as an input and start listening.  You should also setup a 64 slot array (8 bits x 4us).  Once the data line pulls low (the data line is always high when inactive) start saving data into that array as quickly as possible.  Once you get all of the data, compare 4 us at a time to figure out the bits you are getting.  

There are also other complications in regards to this protocol, but I will document them later.

[Howard_Casto]

Hardware Wip:

Teensy has arrived and is working properly.  Awaiting more parts.

[Beley]

....  I will reserve 8 for dips which gives me a mamimum of 64 combinations and thus 64 different controller types...

wouldn't that give you 256 combinations?

[Howard_Casto]

....  I will reserve 8 for dips which gives me a mamimum of 64 combinations and thus 64 different controller types...

wouldn't that give you 256 combinations?

Yeah, in binary format it would be 256, sorry.  I guess I should have clarified, 64 console types, plenty of sub-types (like a trackball for a 2600, ect...)

[SavannahLion]

Unfortuantely they put the +5v on a different pin, making it impossible to use atari controllers on a sega console.

That isn't entirely a true statement. It would not be possible to use any Atari controller on the SEGA if the controller requires the +5v line. It is, however, possible to use the CX40 (Atari joystick to you laymen) on the SEGA Genesis (and guessing the SMS as well) since the CX40 makes no use of the +5v at all.

A more accurate statement would be that it's largely a moot point to even use the Atari controllers on the SEGA hardware because the Atari controllers do not have enough buttons per player anyways.

Which leads me to the Atari pinout notes:

The atari uses a standard db9 connector port (a pc serial port)

Pinouts are as follows:

(Joystick/Paddle/Booster Grip (Omega Race)/Lightgun)
1=Up/None/Up/Trigger
2=Down/None/Down/None
3=Left/2p Fire/Left/None
4=Right/1p Fire/Right/None
5=None/1p Axis/Front Trigger/None
6=Fire/None/Fire/Light Sensor
7=+5v
8=Ground
9=None/2p Axis/Top Trigger/None

The chart implies that +5v is used across the four controller types there. It is not. The Joystick makes no use of the +5v at all.

Other notes but these are more nit-picky than anything else.

The wheel does use similar pinouts but making the statement that it's essentially a joystick is rather misleading due to how the wheel responds on the pinouts. IOW, the statement implies that a joystick can be used in lieu of a wheel. I haven't bothered to chart the behavior, but I don't think this is actually possible?

The keypad can be detected but it's going to be hit and miss.

You forgot the trackball.  


edit: Oh and I almost forgot. Might be a good idea to note the SEGA and ATARI controllers use DE9 (colloquially DB9).

[Howard_Casto]

Unfortuantely they put the +5v on a different pin, making it impossible to use atari controllers on a sega console.

That isn't entirely a true statement. It would not be possible to use any Atari controller on the SEGA if the controller requires the +5v line. It is, however, possible to use the CX40 (Atari joystick to you laymen) on the SEGA Genesis (and guessing the SMS as well) since the CX40 makes no use of the +5v at all.

A more accurate statement would be that it's largely a moot point to even use the Atari controllers on the SEGA hardware because the Atari controllers do not have enough buttons per player anyways.

Which leads me to the Atari pinout notes:

The atari uses a standard db9 connector port (a pc serial port)

Pinouts are as follows:

(Joystick/Paddle/Booster Grip (Omega Race)/Lightgun)
1=Up/None/Up/Trigger
2=Down/None/Down/None
3=Left/2p Fire/Left/None
4=Right/1p Fire/Right/None
5=None/1p Axis/Front Trigger/None
6=Fire/None/Fire/Light Sensor
7=+5v
8=Ground
9=None/2p Axis/Top Trigger/None

The chart implies that +5v is used across the four controller types there. It is not. The Joystick makes no use of the +5v at all.

Other notes but these are more nit-picky than anything else.

The wheel does use similar pinouts but making the statement that it's essentially a joystick is rather misleading due to how the wheel responds on the pinouts. IOW, the statement implies that a joystick can be used in lieu of a wheel. I haven't bothered to chart the behavior, but I don't think this is actually possible?

The keypad can be detected but it's going to be hit and miss.

You forgot the trackball.  


edit: Oh and I almost forgot. Might be a good idea to note the SEGA and ATARI controllers use DE9 (colloquially DB9).

I appreciate the help, but you are incorrect in a couple of your assumptions.  

On a sega port 5v is on pin 5, on an atari port pin 5 is a digital/analog input.  If you happen to press the top fire button on an omega race, controller, for instance, you have just crossed 5v to ground in an improper and possibly fried your master system/genesis.  (Actually I can't confirm that on an real genesis, but I do know that in the case of a avr, if you cross vcc and gnd you will fry the avr and your pc at worst, or just reset your pc at best).  Yes the standard atari joystick is safe to plug in but virtually every other atari controller isn't. So long story short it is dangerous to assume that the sega controller port is atari compatible.  

On your second point, the pinout chart is correct.  Regardless of if the controller actually uses the 5v, pin 7 is pumping out 5v at all times.  Just like I noted the 5v on the neo-geo pinouts even though it isn't even used on the original controllers.  It is always important to label voltage pins since hooking them up to the wrong thing can fry your pads, your avr, your console ect....


The wheel IS a joystick.  The thing is it uses mechanical tricks to rapidly press left or right.  It's basically using something sort of similar to an optical chopper, but a mechanical version. You can actually hook up a atari driving controller to the left/right inputs on an ipac and use it like a spinner in mame... I've done it before.  That being said, no you couldn't use a joystick in place of the driving controller on an atari, not because the atari wouldn't recognize it, but because you couldn't possibly tap left or right as rapidly as the driving controller allows you to.  I'll be glad to go back and double check with a scope though once I get things rolling.  I've got a couple sitting to the left of me.

**update**

Opps on that one! Should have double checked before I said anything.  Upon cracking open the controller, it uses the Up/Down pins, not the Left/Right pins. 
As to what it actually is... well I'm getting conflicting reports.  I saw one site say it was a pot and that's wrong.... they must be confusing it with the paddle controllers.  Another said it sent a 4 bit binary encoding regarding position and that's wrong... I think they were thinking of an intellivison controller or something similar.  The only two explainations that would actually be valid would be a quatrane encoder (like a traditional spinner) or what I was referring to.  I cracked open the gray housing the reveals all of the internals and at least by looking, it could be either one.  If it is an encoder then it's the strangest one I've ever seen.  It is unpowered, meaning that you would get constant signal from the last position even if the wheel isn't moving.  Odd!! 

But I do distinctly remember hooking one up to my i-pac just for fun a year or so ago and playing a decent game of Arkanoid with it.

I think I'm going to have to play with this one a bit to figure out exactly what it is.  Either way it shouldn't be hard to implement.  I won't update the atari section until I am certain of what it is.

****

**update**
The next bit about the trackball is confirmed.  Now if you are talking about 5200/7800 trackballs, those work differently, but I haven't went into documenting the other atari systems yet.
****

No I didn't forget about the trackball.  Like I said in my last note, all other atari controllers regardless of control type or style show up as one of the ones I've listed.  The wico trackball has an internal DAC and it shows up as a joystick, using the same inputs.  Again, you can hook it up to your ipac.    Now if some of the "official" trackballs use some different sort of protocol then I apologize and I need to know about it.  

It's important to remember that I'm documenting pinouts and protocols for the purpose of figuring out how to interface various controllers to the pc... the physical controls or attributes of the controllers don't really matter, just their electrical properties and serial/analog protocols.

[SavannahLion]

On a sega port 5v is on pin 5, on an atari port pin 5 is a digital/analog input.  If you happen to press the top fire button on an omega race, controller, for instance, you have just crossed 5v to ground in an improper and possibly fried your master system/genesis.  (Actually I can't confirm that on an real genesis, but I do know that in the case of a avr, if you cross vcc and gnd you will fry the avr and your pc at worst, or just reset your pc at best).  Yes the standard atari joystick is safe to plug in but virtually every other atari controller isn't. So long story short it is dangerous to assume that the sega controller port is atari compatible.  

Please don't patronize me. I make no mention in using anything other than a CX40 (joystick) in the SEGA console. In fact, I make mention to the contrary that you can NOT just use any controller on the SEGA. My beef is with the chart, see next blurb.

On your second point, the pinout chart is correct.  Regardless of if the controller actually uses the 5v, pin 7 is pumping out 5v at all times.  Just like I noted the 5v on the neo-geo pinouts even though it isn't even used on the original controllers.  It is always important to label voltage pins since hooking them up to the wrong thing can fry your pads, your avr, your console ect....

The chart is incorrect. Here's why. the chart can be easily misinterpreted to mean that all the controllers in question leverage +5v when in fact, not all the controller types use +5v nor even have the ability to do so. Specifically, again, I'm referring to the CX40 and any controller that uses the same pinout. A more accurate chart might appear as such:

(any idea how to add borders here?)

Pin	Console	Joystick (CX40)	Paddle
1	D	Up	N/C
2	D	Down	N/C
3	D	Left	R Fire
4	D	Right	L Fire
5	D/A	N/C	L Axis
6	D	Fire	N/C
7	+5v	N/C	+5v
8	Gnd	Gnd	Gnd
9	D/A	N/C	R Axis

To common layman, D = Data, A = Analog, N/C = Not Connected. I make no assumptions about whether the console is capable of I/O on these ports. That is an exercise left to the programmer to work out.

Note: I've left the other peripherals off to save myself work.

TBH, I wouldn't even use a pin chart without an accompanying diagram of the actual pin arrangement. But that's just me. My point is, my table attempts to make it very clear about what pins each controller uses and the console. The reason is two fold, while I accept that your chart is intended for your specific AVR application, it is not very well organized if one wants to use a minimalistic approach with an AVR that supports only the CX40 (common in robotics). By understanding that only six of the nine pins (again in reference to a CX40) have any sort of worthwhile connection at all, a person can opt to take a very minimalistic approach in a future design. The same can be held true with just about any design that opts not to support anything outside of a very specific controller.

Opps on that one! Should have double checked before I said anything.  Upon cracking open the controller, it uses the Up/Down pins, not the Left/Right pins.  
As to what it actually is... well I'm getting conflicting reports.  I saw one site say it was a pot and that's wrong.... they must be confusing it with the paddle controllers.  Another said it sent a 4 bit binary encoding regarding position and that's wrong... I think they were thinking of an intellivison controller or something similar.  The only two explainations that would actually be valid would be a quatrane encoder (like a traditional spinner) or what I was referring to.  I cracked open the gray housing the reveals all of the internals and at least by looking, it could be either one.  If it is an encoder then it's the strangest one I've ever seen.  It is unpowered, meaning that you would get constant signal from the last position even if the wheel isn't moving.  Odd!!  

But I do distinctly remember hooking one up to my i-pac just for fun a year or so ago and playing a decent game of Arkanoid with it.

I think I'm going to have to play with this one a bit to figure out exactly what it is.  Either way it shouldn't be hard to implement.  I won't update the atari section until I am certain of what it is.

Now that I'm home (but still not on my dev PC). I had to rack my brain to understand WTF you meant by "quatrane encoder" and can only assume you mean quadrature encoder? If that's the case. My notes confirm the same and it was what I was trying to allude to in my last post. It's a 16 position spinner wired to 2 bits with quadrature encoding. That's why it works so nicely with your iPac (I thought OptiPac supported this, when did iPac get that support?). It's the same encoding scheme used in a lot of arcade and PC spinners.

I won't discuss this any further and deleted my crappy DROID written chart since it looked like garbage anyways. I will mention that you should not always get a constant signal, even at "last position" except in 3/4 of the total positions. Power, as it were, comes from the data pins 1, 2, as these are left to float (the RIOT probably has internal pull ups but it appears the type of TTL tech used then did not always require pull ups as we like to use them.) and pin 6 has its own pull up resistor. As I'm sure you know, applying any decent microcontroller to the wheel would be trivial. It would be more work to debug the software.

It's important to remember that I'm documenting pinouts and protocols for the purpose of figuring out how to interface various controllers to the pc... the physical controls or attributes of the controllers don't really matter, just their electrical properties and serial/analog protocols.

Ensuring accurate hardware and electrical information is my concern.

Since I've written all of this already....

Most Sega consoles use a standard db9 connector port (a PC serial port)

I've mentioned this once already but it was steadfastly ignored. DB9 is the colloquial name. The correct, and proper, name for that connector is DE9. The E and B denote the size of the connector. So a DE9(AKA DB9) is the same physical size as a DE15 but not the same size as a DB25 or DA15. At a minimum, you might want to note what is what. Especially if some poor bastard really does find a 9 pin D-subminiature with a B shell.

Now for a one time check at start-up, we can be fairly certain.... if on the third pulse immediately after plugging the controller in pins 3 and 4 are "pressed"    again then it's a 3 button controller, otherwise it's a 6 button as "z" should be open on the third pass.

I think you meant X, not Z. Z would and should be open on all the passes.

[Howard_Casto]

I think I understand your concerns now.  The main thing you want to remember though is that these are just my notes that I'm pulling off from the net/and or my own personal notes.  They are far from accurate or complete yet.  When I leave something a bit vauge it is because I'm unsure of the specifics right now. 


I wasn't patronizing you, I feel like you are skimming over something fairly dangerous and assuming that the lamen knows what we know. 

Just as an example I've seen many usb adaptors that are billed as compatable with the atari 2600, master system and genesis.  They don't have a switch to change the settings from atari to sega either.  I can only assume then that the 5v line is active and wired for sega.  Granted 99% of the people out there think of the old digital joystick when they think atari and that's what they use, however any of the more hardcore that want to plug in something more exotic might be in for a unfortunate suprise.  The reason that comment was in the docs (maybe I should be more blunt about it?) was to let builders know that it is NOT a good idea to use the same physical connector for the atari and the sega consoles, even though it is tempting because they are so similar. 


I think that's a good idea with the atari chart with the N/C, that is acceptable to me and will probably make things a lot clearer.  I didn't just want to leave it blank.  Make no mistake though, the chart isn't incorrect, it's just a bit vague in your opinion, and I agree with that completely.  That is because the data out there on atari controllers are a bit vague and I'm going to have to check them personally, believe me I'll fill it out better as we go.  The digital joystick and the tennis paddles are well documented, the rest almost aren't at all. 

Yes I meant quadrature encoder... the spell check must have butchered that one pretty bad.    But no, ipacs don't support spinners, at least not my first generation ipac on my old cab.  That's what makes me wonder what is going on in the thing.  Yeah I know how they work, regarding the bit patterns I just meant that it seemed like a crazy way to do an encoder considering someone might have wanted to do a driving game that also supports the joystick.  But the CX series is a wierd little box... the develpers hacked that thing to bits. 

I don't have pictures of the connectors posted because I haven't gotten that far yet.  Tried to do it in "ascii mode" but the forum kind of mutilated them so I erased them for now.  The intention was to link to the best sites with info on the individual controllers when I'm done.  I'm trying to "dumb things down" a little bit with my own personal notes because I've noticed that many of the notes on the net go into agonizing detail about stuff like timing and such, which is nice if you want to write a console emulator, but are often unnecessary when making an adaptor.  (The exception of course being the n64/gc which are the most picky controllers I've ever seen, timing wise).  I'm trying to summarize a lot of it and then I can point to more detailed info as well.

I didn't ignore the thing about the DE9, I was looking into it.  To be honest I've never heard the term before and I didn't know wtf you were talking about.   I appreciate the explaination.  It looks like according to wikipedia at least (yeah that's accurate)  that pretty much all D-sub connectors are sold as "DB" connectors anymore.   Maybe I should just use the more generic "d-sub" term from now on and just make a note about the E size??

Anyway, the avrs are in....  I'll start to work this weekend and hopefully we can get a few of these stranger atari controllers sorted out.  Thanks for the help man. 

[Howard_Casto]

I haven't posted an update in a while so I thought I should. 

Right now I'm pulling my hair out trying to get the AVR to show up as 5 gamepads. 

Getting it to show up as a joystick is quite easy... getting it to show up as the 5 joysticks, with the buttons and axis that I want, is like pulling teeth.

I'm pretty sure whoever created the HID device descriptors used to work in Hell.... or the DMV. 

I've tried a few of these libraries that are supposed to make hid descriptor building easier, but it actually makes things worse because like mame, they are so vast I can't tweak things. I'm thinking I'll have to use the generic sdk from amtel as it is pretty bare-bones.

Sit tight, once I get this figured out things should move along quite rapidly. 

[ChadTower]

On a sega port 5v is on pin 5, on an atari port pin 5 is a digital/analog input.  If you happen to press the top fire button on an omega race, controller, for instance, you have just crossed 5v to ground in an improper and possibly fried your master system/genesis.  

You know what?  You may have just solved a long standing mystery for me.  I have probably fixed 25 Master Systems over the years with a bad 7805.  Now I finally know why this system fries its VR but none of the others do!  


OTOH, I've cleaned up/refurbed a lot more Genesis than that and never seen a Genesis with a bad 5v regulator. There must be something different in the Genesis in that regard.

[SavannahLion]

It appears Gennies have an inductor on ground. No such inductor exists on the SMS. Maybe that has something to do with it?

[Howard_Casto]

I'm glad the info was helpful......  I knew about this because I saw my friends master system blow when we tried to plug in an atari 7800 controller back in the day. 

Anyway, good news on the progess front. 

I looked over the HID descriptor docs at usb.org (UGH!!) and managed to cobble together a working descriptor almost from scratch.  That means I probably understand it enough to proceed with the real work, namely the individual console protocols. 

Right now the AVR shows up as a single usb gamepad with 6 axis and 32 buttons, which should be more than enough.  I'm debating over if I should include a hat switch for the d-pads.  It's trivial to add, but it'll add another byte to the length of the gamepad report.  If we were only doing a single gamepad I would say "no big deal" but we will potentially be doing 5, and 5 extra bytes is going to hog the bw enough to where it might hurt performance.  I also have to mirror the d-pad axis to four buttons anyway for "dance mat"  support. 

Any thoughts on that are welcome. 

Anyway I need to work on the descriptor a little bit more.  First I need to look into how a person sets up force feedback.  Info on that is virtually non-existant and I need it for the n64 and gamecube controllers. 

Then I need to look into compositing the avr into 5 gamepads.  This isn't particularly difficult, but writing the function to manage the requests and route them to the proper functions can be tricky if you are careless. 

Anyway, I'm saying this time next weekend I should have enough free time to get the hid side of things fully implemented and hopefully have the main "controller selection" function in place as well as working protocols for the simplier, pre-nes consoles in place.

[SavannahLion]

Anyway I need to work on the descriptor a little bit more.  First I need to look into how a person sets up force feedback.  Info on that is virtually non-existant and I need it for the n64 and gamecube controllers.

You mean on the PC side?

[Howard_Casto]

Anyway I need to work on the descriptor a little bit more.  First I need to look into how a person sets up force feedback.  Info on that is virtually non-existant and I need it for the n64 and gamecube controllers.

You mean on the PC side?

Yeah... I can setup "user defined" outputs, but those would require an external driver.  I need to figure out how to do it in pure HID. 
I really haven't looked into it very hard though... been quite busy lately.

[thebyter]

Sorry for not noticing this thread earlier, but there's a good chance you'd be interested in a "Bliss Box".  Even if you don't buy a device from Cory, it's all open source and there may be helpful information for you.

http://spawnlinux.dyndns.org/Bliss-Box/

Thanks!
The Byter

P.S.  I have no connection with Bliss Box; I've never met the man, seen a device, get any kickbacks, etc.  I just have seen posts on other forums (Underground Gamer, specifically) and noticed the similar concepts.

[Howard_Casto]

Sorry for not noticing this thread earlier, but there's a good chance you'd be interested in a "Bliss Box".  Even if you don't buy a device from Cory, it's all open source and there may be helpful information for you.

http://spawnlinux.dyndns.org/Bliss-Box/

Thanks!
The Byter

P.S.  I have no connection with Bliss Box; I've never met the man, seen a device, get any kickbacks, etc.  I just have seen posts on other forums (Underground Gamer, specifically) and noticed the similar concepts.

I'm aware of BlissBox, thanks.  It was mentioned on a previous thread.  Although I might sneek a peak if I really need to, I would rather not.  Afterall, he is selling adaptors as well, so it would be a pretty crappy thing to do.  Also their goals are totally different and thus most of the code isn't helpful (changing device status, only one controller, ect...). 

[SavannahLion]

I couldn't find it on the Bliss website but IIRC there is a difference in how the Bliss handles some of the I/O.

Edit: Removed out of date information.

[Howard_Casto]

Ok looked a little more into FF this weekend.  It isn't looking all too good. 

With much difficulty (including a registry patch?!?) it is possible to do FF in pure HID without drivers.  The problem is the size of the descriptor.  Normaly a joystick might take 10-15 lines of HID entries to get working, taking maybe a hundred bytes or so.  The FF output descriptor, even the most basic one, takes something like 3 pages of HID entries, with 1500 bytes!  On a pc pgoram I would say "no big deal" but on an avr that's a lot of space, especially considering what I am trying to do with it.

Now I'm pretty sure that we have enough room anyway BUT....

The reason the report is so long is that the "constant force" effect (the most basic ff effect) would  send about 30 variables to the avr.  We only need 3 (power, direction for left or right motor, and duration).  Seems like kind of a waste considering I can setup a generic serial stream and send just the 3 bytes we need.  Heck, until we get to the xbox 1, power and duration aren't even needed variables, it's just off and on. 


I think for now I might just ignore FF.  I'm going to go ahead and setup the avr as 5 gamepads, make my main function, and go from there.  I need to go ahead and order more hardware as well.  I think I have a good enough grasp that I know we can go forward, so I'll order project boxes and connectors.