Nes/SnesThankfully, nintendo had the common sense to use a serial protocol for their controllers, which makes things a ton easier wiring-wise. The nes and snes protocol is identical, only, obviously the snes controller has more inputs.
The pinouts are as follows:
Nes:
Pin#: Function:
1 +3.3V (Some sites say 5, but the nes/snes only outputted 3.3 to the pin)
2 DATA 2 (Special Controllers Only)/Zapper Light Sensor
3 DATA 3 (Special Controllers Only)/Zapper Trigger
4 GROUND
5 CLOCK
6 P/S
7 DATA 1
SNES:
Pin#: Function:
1 +3.3V (Some sites say 5, but the nes/snes only outputted 3.3 to the pin)
2 CLOCK
3 P/S
4 DATA 3 (Special Controllers Only)
5 DATA 1
6 DATA 2 (Special Controllers Only)
7 Ground
How you get data is suprisingly simple. The p/s or "latch" pin is used to trigger a poll. We ground this pin and then the states of all the buttons are stored on a chip in the controller. Now everytime we ground the clock pin, one of the button states is sent, in order for a total of 8 pulses for the nes, and 16 for the snes. We buffer all of these states to get the status of the entire controller. Something that's useful to us is that the nes pad will continue to output 1's if you try to read past 8 bits (we'll get to that later). The two extra data pins are used for stuff like the zapper/super scope and the arkanoid controller. Little is known about them but it should be possible to add support if we can find some specs.
Anyway.... each button's status is sent in order... here is the order:
BIT#: FUNCTION:
------- --------------
1 B (A on the nes)
2 Y (B on the nes)
3 Select
4 Start
5 UP
6 Down
7 Left
8 Right (Last button polled by NES)
9 A
10 X
11 L
12 R
(The remaining pins are rarely used)
The snes mouse uses an additional 16 bit buffer, activated if the un-used bit 16 is turned on, but it's too complex to post here. Just rest-assured it could be easily supported. Then again, why you'd need support for the snes mouse on a pc is beyond me.
As mentioned in the atari section, the chip in a snes controller could be used to lengthen the number of inputs we have to 16 or more, making it possible to hookup two 2600 pads via the parallel port. From what I understand, this chip is quite cheap and if nothing else a snes controller could be canibalized, simply taking each pin on the atari controller and soldering it to a button contact on the controller.
Zapper:
I finally found the zapper schematics. Basically pins 2 and 3 are used as raw switches, one for the trigger in the gun, and another for the photosensor. As you all know the zapper is NOT a real lightgun, rather simply a light sensor and a switch. Basically what goes on is when the zapper's trigger is pulled every target on the screen is covered with a white box. If the gun is aimed at a white box, it trips the sensor inside the gun and that signal is sent back to the nes letting it know that the target is hit. Since many games use multiple targets (like duckhunt, with 2 ducks on the screen at any given time) what the nes actually did was rotate potential targets in a loop, only putting the white square on one at a time. When/if the light sensor is tripped, the nes made note of which target was currntly highlighted and used that to determine which one was hit. I've discovered, unfortuantely that the photsensor is some sort of funky ir-sensor (meaning lcd displays are probably out as they don't emitt ir) and some rudimentary timing IS involved. Basically the gun runs at 15khz and your standard crt monitor will run at around 31khz. Tv-out should work great though. Also, apparently, by adding an inline resistor to the works you can get it working reasonably well on a computer monitor. The zapper ONLY works on port 2 on the nes, so we only have to worry about reading the two pins on that port.
Supporting the zapper on a hid interface would be quite simple.... we simply wire these extra two pins to some spare raw inputs on the hid chip (probably buttons 9 and 10 as the nes pad only has 8 inputs). Then we'd get a button pressed when the trigger is pulled and another if the gun is pointed at light. It'd be up to nes emu programmers to add support. Quite frankly though, I don't see why they wouldn't. Assuming the timing is good on the emulator it'd take about 10 minutes to add the code and seeing as how this is how the nes carts originally worked, if anything there's a major hack somewhere in their code, probably using getpixel to check for white at the current position of the mouse cursor.
Arkanoid Vaus Controller:
I thought this one would be hard to implement, but actually it won't be. The controller uses the 8 bit buffer normally used for the buttons to send the hex value of the pot. The pin for the zapper button is used to detect the button press. (Which is raw btw.) Now of course there isn't any way of detecting if the arkanoid controller is connected. Arkanoid got around this problem by making the game one player and always assuming that the nes gamepad was in port one (which could optionally be used to control the game) and the vaus controller was in port 2. We can essentially do the same in our hid chip by mapping a spare analog axis to the hex value of controller 2 at all times. Since neither the nes or snes have any analog axis to worry about (unless we decide to map the dpad to one, in which case we'd still only need 4 out of the available 8 for two controllers) this should work fine.
Satellite and Four Score (4 player adaptors):
Still farily easy but more data on the physical hardware is still needed. (Anybody wanna send me one to take apart and ruin?
) The adaptors made use of both ports, with both ports simply sending along 16 bits (two controllers each) and an 8 bit id string telling which, if any controllers are connected. The p/s switch is sent to port 1 only though and you mgacially start getting data from BOTH ports, which makes me wonder how it knew to do that. My guess is if we took apart a 4score, we'd find it makes use of those elusive two extra pins to detect a connection. This is the only part that needs looking into.
So hid implementation is fairly simple, just read the data for all 4 controllers and map them to buttons....oh wait.... we only have 32 digital inputs! Well that's ok, while the typical chip reaches it's physical limits at around 32 buttons (unless you want a controller with the responsiveness of a slug.) I'm pretty sure that the virtual limit is around 64, so we are still good. If not then we just map our dpads to our 8 available axis, remembering to turn off the arkanoid axis off in this very special situation.
PowerPad:
I'm a bit confused on this one. The specs I found say it's read like a normal pad essentially with an 8 bit buffer as normal, but the powerpad had 8 inputs! The specs go on to say that in the 3rd and 4th bit the status of two buttons are given. How exactly is that possible? My guess is plugging in one of these bad boys to a completed adaptor would clear things up. My guess is some buttons share the same input and the games are coded in a way that you won't notice. Regardless, hid interface would be easy.
Microphone:
The famicom (NOT the nes) had a microphone on the second controller (which did NOT have start and select buttons). the microphone was 1 bit (probably sounded horrible) and added nothing to gameplay other than hearing your own voice over the tv. Since the famicom controllers were premenantly attached to the console, and we already have a better way of doing this on the pc (a microphone, duh!) this won't be implemented.
PowerGlove:
??
My guess is the pg had some sort of processor that translated all of the finger motions and positional data into button presses, because the nes simply isn't designed to handle the load translating all that crap would be. The exception might be the positional data, as I've heard on some other adaptors that the pg buttons work, but not the motion sensing. Supporting this rather useless controller would be a low priority anyway.
Super Scope:
??
Super Multi-Tap:
??
It is also of note that there are several versions of this device on the snes and the protocol may or may not be different. My guess would be it works exactly like the 4-score except obviously with more bits to handle the extra buttons on a snes pad.
Mouse:
(see notes on snes above)
It'd surely be possible to add support, but unless we are at the console adaptor stage (as in all these controllers to the xbox or wii) is there really any point? I mean it'd really complicate the code and what emulator is going to bother adding support when every pc on the planet has a mouse.
Proposed Hookup:
Data 1 1p= hid chip switch 31
Data 1 2p=hid chip switch 32
5v=hid power supply
Ground=hid ground
Data 2 1p=Not Connected
Data 3 1p= Not Connected
Data 2 2p= hid chip switch 9
Data 3 2p=hid chip switch 10
clock 1p+clock 2p = hid clock output? (physical switch undetermiend atm)
p/s 1p + p/s 2p=hid output 1 (physical switch undetermined atm)
Proposed function:
(Note that since the powerpad, powerglove, mouse and super scope are undocumented atm, these controllers aren't taken into account yet.)
we would need two, 32 bit buffers and an integer variable called "padtype"
padtype 0 = nes
padtype 1 = 4score
padtype 2 = snes
padtype 3 = multitap
trip p/s switch to reset buffers in both ports
Read bits 1-8 of BOTH ports by reading the bits, storing them in a buffer, triggering the clock latch and repating 8 times
Read the next 8 bits the same way..... If bits 13, 14 or 15 are turned on then the pads are either single nes pads or a nes 4 score as
those bits are NEVER used on a snes pad.
If we've determined it's a nes protocol (13, 14 or 15 are on) then we check to see if bits 13 and 14 are on (up and down). Since these can't be pressed at the same time, we've determined that they are regular pads if they are both on and we dump the buffer for this second set of bits and set the padtype to 0. If not then we keep it for pads 3 and 4 and set the padtype to 1.
If we determined it was a snes protocol (13, 14 and 15 are off) then the two buffers are merged to make the two pads. We go ahead and read another 8 bits. If 13, 14 and 15 are off then we can assume that it's a multitap and we go ahead and read the other 8 bits to finish up our buffer for pads 3 and 4 and set the padtype to 3. If they are on then it was a normal set of snes pads, we dump that 8 bits and set the padtype to 2.
Now that we've figured all of that out, we handle our special controllers.
If padtype doesn't equal 0 (nes) then we do nothing if it is then we set the value of analog axis 5 to the de-hexified value of pad 2's buffer (for arkanoid controller). We also replace hid buttons 9 and 10 with the raw values of those inputs (for arkanoid's button and the zapper signals).
Finally done with all the polling, we take the contents of both buffers and dump them out on the hid's output lines, changing the status of all those controls. There's really no need to reset the chips on the controllers, as that'll be done first thing next loop.
references:
http://pinouts.ru/Game/snescontroller_pinout.shtml (I'm using the pin numbering of this site)
http://www.gamesx.com/controldata/nessnes.htmhttp://nocash.emubase.de/everynes.htm#controllers
Home
Help
Search
Login
Register
Send this topic
Print
Topic: Universal Console Connector Project (Read 17760 times)
