Playstation Controller

[bitartrate]

Hi Uli, I have not been able to find a playstation controller that works. I used the shmup as my test software as well as writing a small program. Firmware I tried was both "v0.88-alpha" and "v0.88-alpha-346" Controllers I tried where 3 different dual-shocks, 1 pelican, and 1 interact propad. Thank you!

[uli]

Sorry, can't reproduce that. For me, both "DO:?PAD(0):LOOP" and "DO:?PAD(2):LOOP" work as expected with a PS2 Dual Shock controller.

Have you verified that all the connections are good on the VS23? The GPIOs are used for the PSX controller only.

[bitartrate]

I will recheck my work and look at it as a physical problem. Thank you, Uli

[bitartrate]

I rechecked my work and am showing continuity on appropriate pins. I found that if I run "DO:?PAD(0):LOOP" before running sokoban then sokoban starts locked up until I press the arrow keys a while. Then the game accepts playstation control just fine until the player dies. At that point a "engine" type sound plays perpetually and the machine locks up. I found that "v0.88-alpha" will do this but playstation controller will not work in "v0.88-alpha-346" even using the above method.

[bitartrate]

I have found a model that works. It is the Sony brand SCPH-10010. I can only get the controller to work with firmware "basicengine-firmware-default-v0.88-alpha-346-g4d5b.tar" and the shmup demo game hangs with the controller plugged in.

Do you want me to delete this bug report and assume it is actually a problem with the shmup game?

[uli]

If there is a controller that works, it's most likely a firmware issue. I would assume the timing is marginal for some reason.

I think we will have to do some experiments here. Do you think you would be able to compile the firmware yourself?

[bitartrate]

I would be able to compile it but I need some direction. I tried to compile it last night but it failed with error "make[1]: No rule to make target '../.git/index', needed by 'version.h'. Stop. Makefile:24: recipe for target 'native' failed make: [native] Error 2".

I downloaded the Git to my local machine and tried to compile it there. I googled the error and got a vague sense that I need to make a .git folder and compile from there. Does that mean I compile within the Git website?

I see that in Psx.h in the sourcecode you have a remark which states 50uSeconds. If you can tell me where to change that variable inPsx.h I would be happy to play with it. Or, perhaps in the future a [timing] parameter could be added to PAD command?

Until I hear from you this might help... if I do an operation on PAD(num) such as IF....THEN I have to hold down a button on the PSX controller then press a button on keyboard before the condition gets operated on. ON:?PAD(0):LOOP works perfectly but if I do: 10 ON 20 p=PAD(0): rem I have also tried PAD(2) 30 IF p AND UP THEN: rem I have also tried IF p AND UP THEN PRINT p all on one line 40 PRINT p 50 ENDIF 60 LOOP

Then I have to hold both a PSX button and an arrow button on keyboard. So I believe you are correct that it must be a timing issue in the firmware.

[bitartrate]

I have studied and I am now able to compile and the output firmware runs. I have found Psx.h and Psx.cpp but i don't understand yet where the timing values (_delay) are actually given an initial value.

[uli]

The controller driver is instantiated in basic_init_input(), using the PSX_DELAY macro for timing. You may want to increase that slightly and see if it helps.

If it doesn't, you can also try to uncomment the delayMicrosends() call in Psx::shift():

        DIGITAL_WRITE(_clockPin, HIGH);
        // Additional delay unnecessary because of VS23 GPIO overhead.
        //delayMicroseconds(_delay);

I have tried to keep the protocol timing as fast as possible because bit-banging the PSX controller protocol takes so much time that it may slow down programs, but I may well have gone a bit far there.

[bitartrate]

Using the SHMUP.BAS as the test I have confirmed that setting #define PSX_DELAY to 3 makes the PSX controller respond very reliably but the performance of BASIC does suffer.

However; uncommenting delayMicroseconds(_delay);

and setting delayMicroseconds(_delay*5); in Psx::read(): makes the PSX controller unreliable and makes the player and enemy ships very "jerky"

and setting delayMicroseconds(_delay*7); in Psx::read(): makes the PSX controller reliable but makes the enemy ships skip a frame (not sure of jargon, it makes them "jerk")

but setting delayMicroseconds(_delay*10); in Psx::read(): makes the PSX controller very reliable and makes the enemy ships run most smoothly although the enemies still seem to skip a little.

Currently recommending delayMicroseconds(_delay*10);

It seems to be interacting with the video timing. Is there a more logical way to time this to the video?

[uli]

I have now tested four different PlayStation controllers (FTR: SCPH-1200, SCPH-110, SCPH-1080 and SCPH-10010), and I don't have any timing issues whatsoever.

That said, I have had a bunch of issues with the system hanging when accessing the PSX controller while plugging a controller in or out, switching to analog mode, or sometimes randomly, presumably as a consequence of a communication error.

I have pushed a fix for these issues (commit cecd6ec0a2f8095bf3f8d33212b7a10cc807d991); please check with the next nightly build if these fix your problems as well.

[bitartrate]

This nightly build V0.88-alpha-358 (basicengine-firmware-default-v0.88-alpha-358-gcecd.tar.gz) cures the PSX problem outlined in this issue. Oustanding job, Uli!