[SOLVED] PS1 controllers random input

Jofo

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.

Katemonster

Took me a minute to read through your thread. I will talk about where I'm at currently.

My setup involves a 4.6k ohm pull-up resistor. I've changed the wiring from the original gamecon driver in order to match the wiring schematic of the PSone. In short, DATA, CMD, CLOCK, and ACK are all wired together, but ATT (this line actually wakes up the desired controller) is separate. Sounds like you've gotten by without it, but I did a test recently where I took the original driver and applied "filtering" to the select button inputs, and I got random pushes of the start button. I'm guessing the behavior is 100% like what you're experiencing.

This is very promising though! Good work on your driver, I'm mostly glad to hear that somebody else had luck with it. I admit, I lost a lot of faith when this thread mostly got crickets.

BTW, to get rid of random button pushes (in my case, the select button, constantly), I added a "filtering" mechanism, where I kept track of the button "history" of the select button. Only if I've seen the button pressed for more than 5 cycles (~100 ms or so) do I send the input to the GUI. Doing this made my issues disappear entirely. I'm very sorry, I keep happening to check this post when I'm away from my PC. I will try very hard to post both versions of the driver when I get home, the one with the original wiring, and the one with the updated wiring.

Your colleague is absolutely correct, however, about using a dedicated microcontroller due to timing changes. During many instances, I was able to leave the controller sitting on the desk without experiencing random inputs, however, the moment I entered a game (a.k.a. added CPU load) the random inputs started. That's why I ended up resorting to my "filtering".

My latest scheme involves playing with the Intel NUC, and I wrote a PSX reader in Arduino and am using it to communicate with the NUC via USB serial. I wrote the NUC-side driver using C++ and UInput, and only got it working last night, so I can't speak on random inputs quite yet, but just looking at the bus in a serial reader, it seems extremely reliable. I'm not 100% ready to post this one yet, since it's still very experimental, but so far, very promising. Technically, the same code should compile on the Pi. I just need to minimize the CPU load. I'm jealous you were able to figure out rumble, though - I'm glad somebody else cares about rumble thumbs up

Katemonster

OK, I'll begin posting my files that I am working with.

First, my version of gamecon_gpio_rpi
The wiring I've spoken briefly about, but here goes, PSX on the left, Pi on the right:
Data(all) - GPIO14
Command(all) - GPIO15
Clock(all) - GPIO18
Acknowledge(all) - GPIO23
Attention/Select(Player 1) - GPIO0
Attention/Select(Player 2) - GPIO1
Attention/Select(Player 3) - GPIO4
Attention/Select(Player 4) - GPIO7
Attention/Select(Player 5) - GPIO2
Attention/Select(Player 6) - GPIO3

I won't say it's perfect, but I found it very reliable in the tests I did. I use a PSX_DELAY of 5, by the way. Also of note, since it should be relatively easy to copy paste into your code, is my "filtering". Without walking you through in detail, if you look at all references of gc_psx_select_state and GC_PSX_SELECT_PROTECT , hopefully it will be clear. Otherwise, ask! :)

Next is my NUC stuff, for anyone curious. I will say, one advantage the Arduino has over the Pi, is that the internal pull-up resistors seem to work well with the PSX input lines. I do not use external pull-up resistors.
psx bus reader INO file
project folder of NUC-side code

The project borrowed a lot from xboxdrv. I don't know how I would have figured out uinput without their example. I already was able to make the controllers hot-pluggable, the driver detects when one has been plugged in or removed. I'll surely be adding rumble support to my NUC based on your code, Jofo. :) I'll post it when it's done.

Jofo

Thanks! I will look into it...

EDIT: implemented in my driver, testing...

Katemonster

@Jofo Have you had time to test out my filtering?

Jofo

The filtering works, but I had another problem - once a time, on higher clock, I was experiencing a burst of random inputs at once (but not Select, like Start and couple of buttons, even X, O etc.). So I've implemented some checks to the reading routine to eliminate those as well, testing now...

Katemonster

@Jofo well, being that I now have several versions of the PSX bus reader, I can talk about my results with all versions.

The original version of the driver, even with the Select button filtered, definitely had sporadic issues with input glitches. My updated version was nearly perfect after filtering the Select button. I'm pretty sure the Acknowledgement line implementation is what did it. I'm pretty confident in that one.

However, the Arduino reader is 100% perfect. So far I've needed no filtering, it all just works. I need to work on the CPU usage of the driver though, still, but for what it's worth, it should work on the Pi. Just plug the Arduino in with USB.