DualShock 2 - getting it to work

Jofo

I've soldered 1K8 resistors, and so far no luck, still plenty of random input. Even if I leave the joysticks idle in Emulationstation menu...

rbaker

@mrbwa1 do you have a circuit diagram? Post it if you have. Are you trying to hold the input high until a switch is pressed?

mrbwa1

@rbaker said in DualShock 2 - getting it to work:

@mrbwa1 do you have a circuit diagram? Post it if you have. Are you trying to hold the input high until a switch is pressed?

I don't have a diagram for this circuit. I have just seen similar issues with other sensors. I'm not sure if this needs to be pulled up or down to get rid or random inputs.

There is a bit of info here: http://store.curiousinventor.com/guides/PS2/

Looks like they are calling for a pull up on the ACK line (pin 9). Not sure of the voltage, but if it is 5V, a 4k7 resistor is pretty common. 10k is the next common value used in a lot of stuff. Even 1k should be sufficient.

Jofo

But isn't ACK used only for Gamepad -> PSX communication? As the site says, it basically used to detect, whether a gamepad is present or not.

I was told that I should reduce frequency in the driver, so will try to play around with it

mrbwa1

I went back and read the GPIO documentation and it looks to be a little different than interfacing to USB. It seems like the timing could be an issue, so reducing frequency may help a bit. Sadly, it would really take an oscilliscope on the lines to see if there is noise in the signal, or if it is an issue on the software end. My limited knowledge is more about working within the guidelines of designed circuits and I tend to get tripped up with issues like this when they do occur.

Jofo

My colleagues have a rather expensive equipment at hand, but also a lot of work, so I will try to play around with the driver first, when it fails, I will probably ask them to hook it up on oscilloscope and see what happens...

Jofo

I think I got it running!

I had a bad IDE cable, I replaced it with a new one, fitting on connectors more tightly. But that didn't sort out everything - the random input was still there, I had to modify the driver and re-pack it it into .deb file and then install. The original driver has the clock set to 3us (333KHz), I've tested 5us (200KHz) and 6us(166KHz). The 200KHz was working fine for some time, but then I got issues again, so I decreased the frequency even further and it seems I've hit the nail. I left emulation station running overnight, just in a menu, and in the morning, the screen was exactly as I'd left it - no random movement in the menu, no random start-selects so far. I've tried some games as well and it seems just fine.

It's gonna be a bit long, but I'll explain every step. I am attaching both 200KHz and 166KHz version of the drivers and all the necessary scripts. Try them out, also You can modify the driver by yourself:

https://mega.nz/#F!10olyToD!DHh95iLfgokhdcAgSOhmFA

Installing new driver from compiled package

First, it is necessary to uninstall the current gamecon driver, thats carried out as

sudo dpkg -r gamecon-gpio-rpi-dkms

Install the new driver (from the folder where the .deb located) as

sudo dpkg -i gamecon-gpio-rpi-dkms_1.2_all.deb

From my experience, all the driver configuration scripts should be unaffected by the reinstall, so now just reboot

sudo reboot

To verify, if the driver was correctly installed, go to

/usr/src/gamecon_gpio_rpi-1.2

and look into gamecon_gpio_rpi.c on the line 622, the value for GC_PSX_DELAY should correspond to the value mentioned at the driver (e.g. 5 or 6) and not 3.

Modifying and compiling the driver by yourself
I've created a bunch of scripts in the scripts folder, so ideally copy it as is. First of all, manipulating with .deb packages MUST be carried out as fakeroot, otherwise file permissions are messed up and the package won't install afterwards, but if You follow this guide, it should be just fine. I have provided the original .deb file (can be also found in ~/Retropie-setup) to start with. Directory tmp is where the .deb will be extracted and where You can do modifications, directory new is where new .deb will be made (if You use the scripts I've provided). I connect to my RPI3 via putty, so I can have multiple consoles running at the same time and I recommend doing the same.

in the script directory, give execution rights on all the scripts by running (you need to do this only once)

chmod +x extract.sh pack.sh install.sh uninstall.sh

Run fakeroot, so just type fakeroot into the terminal. You should now be root@retropie, the follwing scripts even don't need to be run as sudo.
Navigate into the script directory and first extract the .deb package by running

./extract.sh

The tmp folder now contains the extracted .deb file. Make sure you are still in the terminal where You are the fakeroot!

In tmp navigate to /usr/src/gamecon_gpio_rpi-1.2/ and edit gamecon_gpio_rpi.c. You can play around as much as you like, as mentioned above, the clock is on the line 622. According to http://store.curiousinventor.com/guides/ps2 , You should be safely able to go for as low as 10us (=100KHz).
When done editing (still in the fakeroot console!), it's time to pack it back. Go back to the scripts directory and launch.

./pack.sh

A new .deb package should be created in the new folder.

Exit the fakeroot environment by typing

exit

You should be back as pi@retropie. The install process does not work as fakeroot.

To install it, it's imperative to uninstall previous version first, so if You have not uninstalled the old one, hit

sudo ./uninstall.sh

then

sudo ./install.sh

The install.sh installs the .deb package from new directory. You can check the installation the same way as in section 4 in Installing new driver from compiled package. The .c file there correspond to the changes You've made.

Reboot

sudo reboot

OPTIONAL

Testing - I used multiple ways to test the result. You can either just boot into the Emulationstation and leave it in certain menu and check from time to time as to what happens (I share monitor with my PI, so from time to time, I switched input and looked what is going on , if the selected menu item changed, a popup window is shown, ...). You can also start a gaming session of course :D

Other way is to use jstest. Upon booting, I killed Emulationstation (killall -9 emulationstation). Then I fired up another console (for second controller), and on each I run

jstest /dev/input/jsX

where X is the respective number of the PSX controller (if no other controllers, it's usually 0 and 1). Each console gets one controller. Over time, the content of both consoles should NOT change (you also should not press anything :) ), that means no random input.

One final note - if You want to edit the driver again, You have to delete all the content in tmp and start over! (but without setting the exec rights, they stay)

Hope it helps, I am going to do some more testing with my setup :)

mrbwa1

@Jofo Danit! Foiled by a bad cable. I should have thought of that.

Jofo

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...

mrbwa1

@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.

Jofo

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...

Jofo

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.

Jofo

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.

Jofo

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_controller

So 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.

Jofo

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 :).

Jofo

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?

PET2001

@Jofo

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.

Jofo

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...

Jofo

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!

Jofo

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 ;)