DualShock 2 - getting it to work

Jofo

I have a variable voltage 1A adapter, but yes, if there is no support in driver, no rumble.

I am looking to the driver, I will need to read documentation about the protocol, but the driver itself is surprisingly small. I hope that I will get some help from Katemonster...

Jofo

I will try it with the pullup resistor - but my colleague said that the pullup resistors on chip must be enabled first, so maybe that's why it does not work and a physical resistor is required...

Jofo

OK so upon discussing it (my colleagues develop HW and boards) and looking into the source code, the on-chip pullup resistor is enabled in the driver and it seems that on such a long cable, the pullup resistor on chip is insufficient, that's why it is probably necessary to solder another such resistor to the controller wire harness. I will try it out today and report progress.

Jofo

@PET2001 we must be blind...

https://github.com/RetroPie/RetroPie-Setup/wiki/GPIO-Modules#gamecon_gpio_rpi section FAQ

Q: PSX pads do not operate reliably or at all

A: GPIO pins P1-07 and P1-26 do not have on-board pullup resistors which are required for reliable operation with PSX/PS2 pads. Connect an external pullup resistor (1.8k-4.7k) between the pin and 3.3V (P1-01) if you use it with PSX/PS2 pad.

So this resistor is needed between physical pins 1-3 and 1-5 (if two controllers). I will try it

mrbwa1

That makes sense. Onboard pullups tend to be in the 10k-50k range, so I would imagine you need something a little stronger with a long cable. Funn thing is that I have run into this with sensors on Arduino all the time, yet I didn't think og it here. In retrospect, it makes perfect sense: there isn't enough resistance to pull up to a logical 1, so the input is floating between logical 1 and 0, hence the false inputs.

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