[SOLVED] PS1 controllers random input
-
I've done a bit more digging on this. I'm beginning to suspect the problem is CPU-related. The problem is nearly non-existent in NES games, but happens very frequently on CPU-heavy SNES games. I couldn't get the problem to happen at all in a console with jstest. Perhaps the driver isn't built to handle small hiccups in the Cpu while trying to poll the controller's bus. I will try to read through the code of gamecon to see if anything obvious pops out at me.
-
I found someone say that the controllers accept a 5v input. I switched the input voltage to the 5v rail and saw no difference in behavior. At this point I've mostly ruled out voltage as a concern.
Thus, I'm looking more critically at the gamecon driver. The PSX originally had combined data pins and separate command pins, but the gamecon driver has the exact opposite. What for? I also wonder if the lack of an ACK pin is causing some sort of bus race condition occasionally. I tore into the gamecon driver today to implement some of these changes. I think I will have time tomorrow to check the results.
-
I assume You are connecting the connectrs to GPIO, right? I actually had the same issue on PSX emulator when testing it, I though it was because I just wildly hooked the controller on the wires (no soldering).
Other thing I've read is that solder joints in the gamepad connector may deteriorate over time and re-soldering is a good option, or at least cleaning the connectors.
-
@Jofo The build I've been using for the testing is a bread board with no soldering, just female-to-male Jumper wires. I de-soldered the controller board from the PSX and am pushing the Jumper wire connectors onto the bare pins on the inside of the case. My PSone build was soldered though. Did the same thing.
-
I rewrote large portions of the driver to separate the command pins and join the data pin. I also implemented the acknowledge pin. However the problem still happens. I switched controllers just for fun. Same issue there as well. Now with the acknowledge pin implemented though, I can see huge timing problems under the hood. The controller goes in and out when the system is stressed. Very curious. I do wonder if these GPIO's just aren't reacting as quickly to the commands as the driver expects.
-
After everything, I started tinkering with the clock phase length. Raising it caused the issue to disappear.
My theory is that, under load, the driver's timings start to decrease, making it wait for too short of a time between inputs.
Now that I've implemented the acknowledge line, it should be fully possible for the driver to support auto detecting when a controller is plugged in or unplugged. This way, any inputs are cleaned up if a USB controller is plugged in.
-
Auto-detection on GPIO would be perfect! But I don't understand the last sentence... that means if You plug in an USB controller, the GPIO controllers will be disabled, or?
-
@Jofo the idea is that, the driver doesn't create any input devices if nothing is plugged in. That way, emulators don't get confused if nothing is plugged into the controller ports. I don't know if it helps anything, it was just a thought.
-
That is a great idea! But I guess it wont be so easy, because there are many types of controllers that can be hooked on the GPIO.
-
@Jofo I was really just talking about the PSX support, I can't speak off the top of my head about how "smart" other controller buses are.
Anyway, I've got a bit more tinkering to do, but from what I can tell, my problem is fixed. I played Star Fox for SNES for like 10 minutes without any random button pushes. I don't think I'll bother putting this fix anywhere since not many people seem to be using it.
-
Well I am definitelly interested in the fix
-
@Jofo I took some time away from the playstations to finish my Sega Genesis project, so I put this down for a minute. I've not forgotten about this, though.
Today I found a thread stating that the delay function the driver relies on to do its talking to the controllers, is heavily influenced by CPU frequency scaling, which can absolutely cause these issues. Do you still have your project? Can you check which CPU frequency scaling governor you are using?
I'm going back to the drawing board to try and see if I can get the best of both worlds - accurate delays while leaving the CPU frequency scaling active. I am going to look into tapping into the Pi's on board timer to guarantee microsecond-level timing
-
I still have not build the adapter, getting the parts now, but I am willing to help.
How do I check the governor?
-
It requires a library to read it, don't even worry about the governor.
I actually played with my CPU governor to see what would happen. I even set it to performance. I was actually surprised to see that I got almost the same results. I used the cpufrequtils library to set it.
The one bit of good news, though - I was able to find the "best" delay value for the clock. I found that if I turned it really high, the pad in digital mode worked great, but in analog mode it was almost non-functioning.
So at this point, I have it working, but I don't know how to get the fix to you. I can try to walk you through the process of editing the C file with the new delay value, but it will require re-compiling. I don't know enough about Linux to try and get you a new .deb file.
-
BTW does the driver have any GIT/SVN repository? Maybe instead of sending me the changes You can commit it to official repository...
Another thing mentioned f.e. here, section 4.4:
http://blug00.blogspot.cz/2016/03/retropie-gamecon-driver-readme-friendlier.htmlWouldn't the delay fix this issue?
I still don't have the adaptor built, so cannot test, hopefully this/next week
-
@Jofo Try it and see. I didn't even know about the delay. I never even found that particular blog post in my searching, it may have saved me effort early on. The documentation on this driver is just plain awful, and the support on the forums is clearly non existent.
I'm done with my PSX projects and have moved on to my PSone projects. Funny enough, the PSone has a different controller pinout - the ATT line is unique for each controller and all other wires are combined. So I had to change the driver so that I could re use the PSone board on those and save myself some hassle with making my own PCB, since unfortunately, the ports use the PSone board for clearance.
My PSone projects require hot plugging of the controllers and there's just too many hiccups in the communication on the Pi to try and salvage anything from it. So I've moved my controller communication logic into a small microcontroller and am using I2C to communicate with the Pi. I want to add rumble support down the line anyway, so I'm just going to roll my own uinput driver to send the I2C messages. Thus I'm not bothering to mess with the gamecon driver anymore.
-
So rumble is not supported in the GPIO driver? And where can I download source code for the GPIO driver?
-
@Katemonster I've found the source code for the driver, can You please send me Your edited version? Thanks.
-
@Jofo I'm not at my PC but if you still want it I can send it. I have the original driver (without my changes to the wiring) and my version of the driver. Before we go messing with your driver though, are you actually having problems?
-
I have created a rumble-capable driver, requiring some re-wire, but I am having difficulties with random start-selects, although I've reduced clock quite a lot, now at 8us and "so far so good" - testing it.
https://retropie.org.uk/forum/topic/6395/dualshock-2-getting-it-to-work
When I spoke to my colleagues, who design boards & stuff, they said it's almost impossible to resolve it without a dedicated chip. There will always be a possibility of an error, because f.e. the udelay may get interrupted, the whole driver re-scheduled, etc.. so what we try to do is to reduce the error to an absolutely minimal rate.
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.