Homemade Console Controller > PC Adapters...why Parallel Port?

[Jakobud]

I've been looking into making a SNES control pad hack so I can use the pad on my PC.  But all the tutorials on how to make a homemade adapter are all for Parallel ports.  Why is this?  I mean parallel port is easy to work with and solder I guess, but I would think someone would have come up with a way to make adapters for USB connections by now.  My mobo doesn't even have a Parallel port on it.  It's such old unused technology.  I dont even think you can buy Parallel port Printers or Scanners anymore...

I have seen Parallel > USB adapters which is another option, but I wish I could just figure out how to wire up a console controller straight to a USB connection...

Anyone have any idea how difficult this is or know anything about it?

[jakejake28]

have you thought of finding a cheap, small usb gamepad, and wiring the snes pad to the gamepad, and the gamepad via usb to the pc?

[DAmnb]

Yeah its pretty weird that there are plenty of PSX->PC USB adapters but no SNES->PC.
Found a site about N64 and PSX homemade USB adapters and he said that he was going to add support for SNES next but it was last updated 1999  

[DarkKobold]

I've actually looked at the code off that site. Not incredibly difficult.

http://www.stndev.btinternet.co.uk/

The biggest problem I've had is that the cypress dev kit went up from 100 bucks to 500.

I wanted to make a hardcoded binary identifier, so I could hook up Nintendo, Genesis, N64, PSX, SNES, and others directly to my cab, and they would just work, no switching of drivers, no problems working. (I would have to chop of the end, and put a 15 pin end on the controller) Also, you'd be able to play any game for any system. A dream right now. But not an impossible dream.

Actually, Im curious if anyone else is interested in tackling this project with me. I've got one interested friend. It will be quite the undertaking.

[Jakobud]

Well I think there are just little demand for SNES > PC adapters (commercial ones anyways) or else people would be selling USB ones.

I figured that the big problem with making USB adapters was because you had to do some microcontroller programming.

Dark, that sounds really really cool man. I would love to help but I just dont know anything about programming hardware.  From that site, looks like there is some major assembly coding that needs done...yikes.

[Howard_Casto]

There is a project I'm working on that will be an "anything" to usb via ddp.  I haven't bought it yet, but I plan on getting one of those 20 dollar usb to printer port adaptors.  As they actually show up in windoze as a printer port rather than a printer, it should be useable for dpp.  Maybe not in xp though but I'll soon find out.  

[Jakobud]

Cool howard.  Keep us posted

[paigeoliver]

Umm, actually I am pretty sure that most printers are still parallell port, and I have never seen a really good one that was USB. The only USB printers I have ever seen are absolute junk.

Also, as far as I know most motherboards still have parallell ports on them, and probably will continue to have them for a long time. There is simply too huge of an install base of high dollar parallel port printers for PC makers to start dropping that port off most models.

You also may not realize this, but lots of companies still use DOS programs for their main systems, and those don't tend to work with USB stuff.

[SirPoonga]

Umm, actually I am pretty sure that most printers are still parallell port, and I have never seen a really good one that was USB. The only USB printers I have ever seen are absolute junk.

You don't look hard enough.  My printer is only USB and it is one of the best photo printers on the market, had it for about 2 years.  Epson Stylus Photo 785EPX.  It has more features than I ever used, partly because I don't use the built in pcmcia port for printing pictures directly off of media.

[Jakobud]

paigeoliver are you serious?  Goto CompUsa and look at all the printer interfaces. I bet out of 20 printers you will find only 1 or 2 that have parallel (and I bet even those have both interfaces on them).  

"The only USB printers you have seen are absolute junk... " hmm.  That's an odd statement.  Thats like saying that every single car that uses Goodyear tires that you've seen is a piece of junk.  Poonga is right. You aren't looking hard enough.  

The fact is that all new printers these days print at very high dpi and they print and high number of sheets per minute.  Parallel is too slow for all that throughput.

[Howard_Casto]

And besides, the whole reason I'm going usb is so I don't have to deal with the printer port.  A usb cable is tiny, slender, and has 5 volts I can tap into for pads that support rumble.  A parallel port can be easily blown, can't handle high amounts of power, uses a huge, bulky, connector cable and is different from mb to mb(so dpp might work on one system, but not the other).  

Getting away from parallel is the plan, even if I have to open up the dpp source, get donations for a usb chip kit and create a device we can all use.  

[_Iz-]

Is dpp = Direct Pad Pro?

any idea why it's been dropped from the ziplabel.com site?

[Jakobud]

Its been gone from there for a while. I'm not sure why.  I recently stumbled upon this though:

http://www.arcadecontrols.com/Mirrors/www.ziplabel.com/dpadpro/

seems like BYOAC mirrored it a while back.

Howard what are you envisioning here?  Are you talking about producing something? Some sort of universal connector for any gamepad?  Like a USB connection that goes out to a proprietary connection that could be connected to any number of different types of gamepads?

[tom61]

any idea why it's been dropped from the ziplabel.com site?

They removed it for bandwidth reasons (it was taking too much up).

Howard the SNESKey drivers are open, they should give you all the info/code you'd need to make your own interface. (more so that even what DPP supports) You'd have to re-write the PC side drivers anyway, so starting with SNESKey won't set you back any.

[Howard_Casto]

Its been gone from there for a while. I'm not sure why.  I recently stumbled upon this though:

http://www.arcadecontrols.com/Mirrors/www.ziplabel.com/dpadpro/

seems like BYOAC mirrored it a while back.

Howard what are you envisioning here?  Are you talking about producing something? Some sort of universal connector for any gamepad?  Like a USB connection that goes out to a proprietary connection that could be connected to any number of different types of gamepads?

Pretty much.  If this parallel port usb adaptor works then there won't be any need. (Although don't be suprised if I buy a bunch up and sell kits.   )  Otherwise, I'll have to get to work.  You see, except for early controllers like atari, all controllers simply send a serial signal.  All they need is that, a timer lead, ground and possibly some power.  Up until now drivers have ignored this fact and used various pins to detect the type of joystick. I would have the driver sample the signal upon connection and determine the controller.  Although I'm not a device driver programmer, so I would probably need at least some help.  

[paigeoliver]

Ok, I haven't looked at printers in like 2 years, so I guess the market has changed since then.

[DarkKobold]

There is actually quite a few problems with the parallel to USB. If you look at D-Pad Pro, it requires driver switching, different pins for each pad, etc. That is why I abandoned the idea of D-Pad Pro to begin with

1st off, the ends of each controller have to be spliced. Some controllers require pull-up resistors, some don't.  

2nd, by having hardcoded identifiers, you can allow the controller to be recognized when plugged in. I don't know how you plan to "sample" the data coming in. If no buttons are pressed, then all the data is a constant high, and each controller is seen as identical. You would have to be holding a button when plugging each in. And then there are still interfacing/syncing problems.  

3rd, Some controllers require a clock (SNES, NES, etc) where as some have internal clocks. (N64, PSX) You have to be able to sync that info. And also account for the difference in button #s. Its not a small task.

4th, if your going to be using USB, all of the following should be done chip level. If you look at the link I posted earlier, the design follows this idea. The device driver only recieves a normal joystick input, regardless of what controllers is attached.  Hope your good at ASM.

Finally, I just have to mention, why is it when I said I was doing nearly the same thing as Howard, I was ignored? I guess that just goes with the territory. Not complaining. Just curious.

[eightbit]

Finally, I just have to mention, why is it when I said I was doing nearly the same thing as Howard, I was ignored? I guess that just goes with the territory. Not complaining. Just curious.

Howard is practicaly a legend in his own mind around here....  

He's been around for a while and has contributed much to the scene...

[Howard_Casto]

Going over your points/questions:  


There is actually quite a few problems with the parallel to USB. If you look at D-Pad Pro, it requires driver switching, different pins for each pad, etc. That is why I abandoned the idea of D-Pad Pro to begin with  

Different pins yes, driver switching, not so much. I won't get into that, but lets just say you really only need to switch for three major types of controller: pre game port, nintendo, sega, and playstation.    Also I plan on using the usb dongles, which means I install several drivers and the ones that differ get a seperate "port".  

1st off, the ends of each controller have to be spliced. Some controllers require pull-up resistors, some don't.  

The resistors aren't required.  They are a fail-safe required for some parallel ports. I've built many of these interfaces before and never used a single resistor.    No the ends don't have to be spliced.... you go on ebay and buy the old, broken console, buy an extension cable, or do what I'm doing, namely buying up old multi-taps and using their sockets.

2nd, by having hardcoded identifiers, you can allow the controller to be recognized when plugged in. I don't know how you plan to "sample" the data coming in. If no buttons are pressed, then all the data is a constant high, and each controller is seen as identical. You would have to be holding a button when plugging each in. And then there are still interfacing/syncing problems.  

Your looking at the problem from the wrong end.  The driver would be very intelligent and the device type would be super generic (i'm figuring 8 axis 32 buttons) with a dumb chip, so that windows doesn't need to know what the driver is doing.  The ones with identical clocks have identical chips and thus can use the same polling method.  The ones without clocks all have different (and somewhat complex) circuitry. Running a small amount of voltage through the controller *could determine the type.  It is an complex process, but far less expensive than making an "uber chip" on the usb end of things.

3rd, Some controllers require a clock (SNES, NES, etc) where as some have internal clocks. (N64, PSX) You have to be able to sync that info. And also account for the difference in button #s. Its not a small task.

see above.... about the buttons what exactly are you talking about?  You setup the driver to have WAAY more buttons, enough to accomidate the most complicatd controller.  When a simplier controller is plugged in, those buttons just don't work.  Some controllers will have issues with this, but it could be managed on a controller by controller basis.  This is probably the simplest part of the project.  

4th, if your going to be using USB, all of the following should be done chip level. If you look at the link I posted earlier, the design follows this idea. The device driver only recieves a normal joystick input, regardless of what controllers is attached.  Hope your good at ASM.

I disagree. If I have to go to the trouble of making a custom interface, I want the most expensive end (namely the usb chips and the programming service)  to be generic, so that people can afford to make/buy their own.  Although doing the hard work at the driver level will be considerably more complex, I feel it will make for a more practical solution.  I'm not good at asm, but I will learn if need-be.  

Finally, I just have to mention, why is it when I said I was doing nearly the same thing as Howard, I was ignored? I guess that just goes with the territory. Not complaining. Just curious.

Sorry about that.  My guess is because of my reputation. Lots of people have come and gone around here saying they are "a gonna" do this and that, but generally when I say "I'm a gonna"  a piece of software or a tutorial, ect is up and running within a month. (This will definately take longer, so don't get any bright ideas.) Once you are around a little longer and produce some stuff people will take you more seriously.  Afterall, it used to be that nobody listened to me.

I hope you can do this instead of me though, namely because I don't want to.  It's just usually when you want something hard done around here.....

[Jakobud]

Sorry Dark, I guess when i read your post and goto "hardcoded binary identifier" my mind sort went numb for a while.  Howard said it a little easier I guess so he didn't actually loose my attention

Maybe if both of you guys are serious about doing something like this, then why not join forces and see what could be accomplished

[DarkKobold]

Ok, a response to Howard, plus a little conclusion.

Different pins yes, driver switching, not so much. I won't get into that, but lets just say you really only need to switch for three major types of controller: pre game port, nintendo, sega, and playstation.    Also I plan on using the usb dongles, which means I install several drivers and the ones that differ get a seperate "port".  

Thats actually somewhat true - but  the order that the buttons are sent is also different, which still requires switching interface.


The resistors aren't required.  They are a fail-safe required for some parallel ports. I've built many of these interfaces before and never used a single resistor.    No the ends don't have to be spliced.... you go on ebay and buy the old, broken console, buy an extension cable, or do what I'm doing, namely buying up old multi-taps and using their sockets.

Its good to hear you've built these previous interfaces. That is one thing I didn't do. I agree the ends don't HAVE to be spliced. Infact, for most people, it would be better if they didn't. However, I want to try and idiot proof the process. You plug in a 15 pin connector (typical radio shack part, "You've got questions, we've got blank stares")  and the driver/usb chip reads the type of controller, and adjusts on the fly.


Your looking at the problem from the wrong end.  The driver would be very intelligent and the device type would be super generic (i'm figuring 8 axis 32 buttons) with a dumb chip, so that windows doesn't need to know what the driver is doing.  The ones with identical clocks have identical chips and thus can use the same polling method.  The ones without clocks all have different (and somewhat complex) circuitry. Running a small amount of voltage through the controller *could determine the type.  It is an complex process, but far less expensive than making an "uber chip" on the usb end of things.

Actually, I think YOU are looking at things on the wrong end!   But isn't that the beauty of colaborating on a project? Getting input from more people is never a bad thing. I think that you hit it on the nose when you said it would be extremely difficult to program things on the driver end. I think you are slightly misguided about USB. Once you have the ASM to program the chip, each chip is only $5 - $20. The programming is the same price whether your code is 2 lines long or 3000 lines long. In all my research, I've yet to find a "pre-programed" USB chip. Regardless of what you do, your going to have to put code on the chip, and ASM is much easier than any higher level stuff. (At least to me)


see above.... about the buttons what exactly are you talking about?  You setup the driver to have WAAY more buttons, enough to accomidate the most complicatd controller.  When a simplier controller is plugged in, those buttons just don't work.  Some controllers will have issues with this, but it could be managed on a controller by controller basis.  This is probably the simplest part of the project.

I agree, except for the decoding location. As before, chip level encoding is by far the easiest. If you look at the link I posted earlier, the guy who wrote that program was a frickin genuis!   His code would make it EXTREMELY simple to add more controllers to the mix.  I fully plan to copy his source, and start adding to it. The only part I don't understand is how his controller syncs the data.


I disagree. If I have to go to the trouble of making a custom interface, I want the most expensive end (namely the usb chips and the programming service)  to be generic, so that people can afford to make/buy their own.  Although doing the hard work at the driver level will be considerably more complex, I feel it will make for a more practical solution.  I'm not good at asm, but I will learn if need-be.  

I think I pretty much answered this earlier. As soon as you enter the realm of microcontrollers, is a base cost.

Sorry about that.  My guess is because of my reputation. Lots of people have come and gone around here saying they are "a gonna" do this and that, but generally when I say "I'm a gonna"  a piece of software or a tutorial, ect is up and running within a month. (This will definately take longer, so don't get any bright ideas.) Once you are around a little longer and produce some stuff people will take you more seriously.  Afterall, it used to be that nobody listened to me.

I hope you can do this instead of me though, namely because I don't want to.  It's just usually when you want something hard done around here.....


I am really hoping to be able to do this. At this point, I feel a little overwhelmed though. I do know plenty about microcontrollers, programming, and EE in general (its my major  ) But signal syncing, learning real world apps, etc, still working on that one. I am trying to find as much help as possible at the moment.

I think the biggest thing we differ on is our goals . My goal is to have every controller with  a spliced on 15 pin end, and to be able to plug that 15 end into an interface, and have that interface send the same thing a normal controller would, with all of the axis, buttons, etc. Then to have a normal HID driver interface take this info, and use it as a joystick. Also, since that link already has 70% of that done, it is a job of adding controllers.

[ryantheleach]

Howard, was this all talk or did you actually get somewhere with this?

[ryantheleach]

http://www.stndev.btinternet.co.uk/

http://www.zen35383.zen.co.uk/stnield/ website moved

[northerngames]

could try the:

XBCD drivers

xbox controller

xbox usb dongle mod

and these to hook them up

http://forums.xbox-scene.com/lofiversion/index.php/t510168.html

would be nice to break it all down to the chips and wires only to make a smaller adapter rig but it would be a skilled task.

[Howard_Casto]

Howard, was this all talk or did you actually get somewhere with this?

Since this writing (this thread is frikkin 4 years old!  way to live in the past) retropads came out with farily cheap nes/snes/whatever 2 usb adaptors.  There wasn't any need to use my methods anymore.