DualShock 2 - getting it to work
-
I'VE GOT IT!
I have a working rumble driver for PSX pads! It was so satisfying playing Crash Bandicoot 3 with the controller rumbling :)
One good thing about it is that I didn't have to modify any RetroArch source files, I don't know why, but along the jsX files, there are also udevX files for the pad, and udev rumbling is supported in RetroArch, so no changes there.
But before releasing it, I need to test it a bit more, because this morning I had some unwanted input again, but it's because I've rewritten the whole thing. In the meantime, get yourself a 7.6V power adapter....
Stay tuned!
-
I hereby present gamecon_gpio_rpi version 2.0
This version is only interesting for those who would like to make their PSX pads rumble, the other types of pads are uneffected. I am opened to any feedback.Download (both modified 1.2 and new 2.0 as 166 and 200KHz):
https://mega.nz/#F!10olyToD!DHh95iLfgokhdcAgSOhmFA
Preliminary guide:
Download: https://mega.nz/#!E0YQGaRS!FYMMQbAQKkJQc60PDkm4Ees-DXrhtqN1o1BrqvXKdLM
Changelog
- Added rumble support for PSX pads. Every PSX pad is implicitly created as memoryless FF device.
- If your config is different from having one pad with data wire at GPIO2, changes in wiring are required, read bellow
Hardware
-
a 5-9V power source is required in order to drive the rumble motors. I use voltage-adjustable adapter set to 7.6V with maximum output 1A, but it's more than enough. The higher the voltage, the stronger the rumble. For those who prefer gentle rumble - go for 6V, those who want to feel it well - go for 7.6V. 5 volts works, but barely noticeable. Having an adjustable power source gives You freedom of choice.
According to http://store.curiousinventor.com/guides/ps2, one pad takes around ~300mA when rumbling. The adapter's ground should be connected to the ground of the setup as well (physical pin 6 on RPi, pads pin 4), the + goes to the pads pin 3. I recommend soldering a diode on + to prevent damage from reversed polarity. -
SELECT (pad pin 6) is now per-pad and no longer shared between all the pads. Goes as follows (in terms of gamecon driver):
PAD3: GPIO27
PAD4: GPIO22
PAD5: GPIO15 (as in version 1.2)
PAD6: GPIO17- also don't forget about the 1K8 resistor between 3.3V (pin 1) and each DATA wire.
Enjoy ;)
-
I have tested the drivers and so far I am satisfied, no random input (I let in run for a day non stop and no unwanted button presses). I've added 200KHz version as well.
-
Great! A working gamecon driver with force feedback - thanks you for your hard work!
I tested the 200 kHz version on my RetroPiE Playstation setup using one of my favorite games, "Need for Speed High Stakes". Force feedback works on both controller ports, but it's using only the bigger (left) motor of the Dualshock controller. Is this by design or could it be a flaw in my setup? I'm using GPIO 15 and 17 for the select lines. My controller motors are powered by 7.5 v (using a step up circuit behind a 5.0 v/3 a power supply).
-
Nice, someone using it!
The way it operates - the small motor has only turn-on turn-off, e.g. no power levels. The big motor has 254 power levels (0=off), but one web says it won't spin under value of 64. What I do is test if power for small motor is nonzero and map interval for large motor to 0-192 - not fully cos I felt it's just too strong in Retroarch (although I have not tried whether the 64 threshold is present on my controller. I will try to build another version for You - with the 64 threshold in mind).
I am using 166KHz version, and I got random Select AGAIN. Two day nothing, but yesterday... Have You encountered any random input during gaming? Maybe I'll switch to the faster driver as well...
-
It seems I had an error in one of the commands, it should be working now, the repository was updated for both 166 and 200KHz versions.
-
I can confirm: the new version of your gamecon driver delivers force feedback using both motors. Great! But the 200 kHz version produces ghost input after a few minutes. I'm going to test the 166 kHz version now.
-
Tested the 166 kHz version for about four hours - no ghost input so far. Wonder why force feedback makes the 200 kHz version more susceptible for ghost input.
-
The problem is that I've made more changes in the driver between those two releases, so I might have done something that damaged the timing. I will investigate... in the meantime, do You still have the original .deb that didn't have the random input issue, but had small motor rumble missing? I might need it...
-
A few minutes of actual gaming and I had ghost input even with the 166 kHz version - mostly "Start" and "Select". Also rumble is very weak on my controller, but I already identified the lines in the source where I might be able to change that (thanks to your code commentary).
I still have the driver version with only the big motor working. I'll be happy to provide it to you.
-
That would be nice, upload it for me please, cos I don't do any subversion, which is probably a mistake :D I will try to diff it with the current version and see whats the problem...
-
-
The link does nothing... you need to right-click the file and choose "Get link"
-
Sorry for the confusion - I've shared the file on Google Drive
-
Thanks.
So that 2.0 200KHz in the archive was working well for you, in terms of random input?
-
Yes it was. Tested for about 12 hours in Emulationstation (with the game menu open, were a random button press would bring up the menu or start a game) an for various, although short game sessions (were the current driver resets the game or exits RetroArch after just a few minutes because "Start" or "Select" are erroneously detected).
-
When I get home from work I will look into it... in the meantime, try the older working version if You happen to encounter any random inputs
-
Well, the changes are only marginal to be honest...
But I might be up to something. I've managed to find this web on the WebArchive
This guy puts quite significant delays between bytes - 60us! Thats less than what he used when transmitting/receiving bits - 100us (thats just 10KHz clock). Current driver has only 25us as gap between bytes, not speaking of clock (5-6us). I will try to experiment with it, I've set the clock to 7us (142KHz) and delay between bytes to 12 clocks (12*7).
I have updated the repository (2.0 142KHz) and I've also included new "SDK" for 2.0, the scripts have changed a bit. Simply edit/overwrite the .c file that is in the directory and run sudo ./do.sh - it will unpack the package, update the .c file, calculate new MD5 hashes, pack it together and install.
-
Still random input...
What I am testing now is to read the data not straight when the clock edge goes up, but after a half-clock interval. I hope this will finally work, I am leaving it running as I am off to work
-
I've uploaded an 8us version of driver that so far has not caused much trouble. Try it
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.