DualShock 2 - getting it to work
-
@Jofo Danit! Foiled by a bad cable. I should have thought of that.
-
It was not only cable, but it improved with a new one. Updated driver had to fix it... now I am studying, how to put rumble into the driver...
-
@Jofo The emulators support rumble now? That's cool. I don't have rumble on my controllers (usually the non rumble ones sell for a lot less) I have picked up.
-
Apart from two Dualshock 2s I also have a Dualshock 3 and it rumbles when I play PSX games, so I assume that there is support...
-
I've been studying the driver, and I think it's possible to add support for rumble, although I still have to find some tutorials about writing linux input drivers... But I think it will also have to include some soldering work...
As You know, no matter how many PSX controllers there are hooked up to the PI, they all share Command, Select and Clock, but each has dedicated Data wire. This is viable configuration for reading all the controllers at once - what the driver does is puts Select to active low, which is shared (that means "I am speaking to all the controllers"), and basically reads status for all controllers at once. But I am afraid that when You want to make a pad rumble, You need a dedicated Select wire for each of them, so You can actually select, which pad will actually ruble. Although most of You probably have the pads at PAD5 and PAD6 (from gamecon perspective), in order the driver to be robust, another 3 more GPIO pins will be needed as allocated by the driver (theoretically 4 PSX controllers can be hooked up - the number 6 is because GPIO1 and 2 are not present on RSPi 2B/3). This should not be issue for the driver. In real, provided You have 1 controller - none, if You have two controllers - one extra GPIO for Select.
-
About the rumble support, this is a comment in udev_joypad.c from Retroarch source files
Udev/evdev Linux joypad driver.
More complex and extremely low level, but only Linux driver which can support joypad rumble.So, the rumble should be supported, if I am correct, gamecon should be in the category of udev/evdev devices.
-
I've started playing around with the rumble, I've created a test program to read and write commands to the pad, my source of knowledge is this:
https://gist.github.com/scanlime/5042071
http://store.curiousinventor.com/guides/ps2
http://www.lynxmotion.com/images/files/ps2cmd01.txt
https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
http://gamesx.com/wiki/doku.php?id=controls:playstation_controllerSo far - a mixed luck. I can get it to rumble, but it's incredibly random, it very randomly responses to the rumble command (90% it does nothing), I don't know why. Other commands are stable - I can poll the state, I can enable config mode, force it to analog and it works, but making it rumble in a deterministic way - well that seems like a challenge... any help is welcome.
In the meantime, in order to eliminate HW problem, I will try to test the pads with some real PSX.
Another interesting note - the joypad turns to default state after like 3 seconds of not receiving any command.
-
Making progress here!
I've probably found the reason, why it behaved randomly - for some reason, the pad seems to need at least 5ms idle when entering config mode and also before the vibration mode is enabled. There is also one more complication - whenever You switch controller from one mode to another, the rumble has to be re-enabled. So in the driver itself, this will have to be taken care of - or make it force to analog and that's it :).
-
The question now is - which GPIO pin(s) should be allocated for the second and possibly 3rd and 4th controller? I propose GPIO17, 27 and 22 (physical pins 11, 13 and 15) Or maybe re-arranging the whole layout?
-
Thanks a lot for providing the modified gamecon drivers! I tested my setup with the 5us version and had no ghost input during my 24 h test (mind however that I am using two 1,8 kOhms pullups. Without the pullup resistors, the 6 us version might be the better choice).
I found it not necessary to uninstall the original gamecon driver, as "dpkg -i" will happily install the new driver over the old one, even if they come with the same version number.
I don't know why the PSX_delay opition was removed from version 1.2 of the gamecon drive. I would be nice to have it back for an easier way to fine tune the setup.
-
Thanks for sharing feedback, I am glad it works.
I have successfully implemented the HW changes I've made, also prepared the driver for force feedback (the PSX side is basically ready), but studying more about the APIs, the driver uses old Joystick API and that is not supported in the RetroArch for force feedback. So now, I think the only way is to rewrite the driver using new evdev API, which should be compatible with the force feedback system present in retropie. I think I will take inspiration in Dualshock3 driver...
Or - update RetroArch with support in the linuxraw_joypad module, which seems as a more viable way...
EDIT: I've found this
https://github.com/flosse/linuxconsole/blob/master/utils/fftest.c
which seems to test FF on joysticks written in the old Joystick API... I think I can use this code to update linuxraw_joypad.c file in RetroArch sources to support FF. First, I will also have to finish the driver itself... will take some time, but I think I can hack it :P The fftest utility will aid me in testing I hope...
-
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...
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.