Rumble and wireless assistance

[richw]

Hi all,

Has anyone got a controller with 'rumble' motors? Ideally, something which is still pretty popular, like: PS 3/4/5, or XBOX (360 or later) devices. I only have:

• A cheapo Chinese clone of an XBOX360 wired controller (even though it's wireless) and it doesn't contain any motors. It claims to support rumbling, but testing it out in Windows, shows that it doesn't.

• An ancient PS 1 (!) to USB adapter with an old 'dual shock' PS 1 controller. Whilst I have got this to work, in that I can control the motors successfully, it doesn't work in the same way as the more modern PS/XBOX devices would, so it's a bit of a dead-end.

I am also interested in controllers like the XBOX360 wireless one, as I recall there being issues with that in the past (flashing lights? poor battery life?).

I've attached a prototype build of USBJoystick (still marked 0.24 - but it isn't!). I would be grateful if anyone can try this module out.

Code: Select all

*USBJoystick_List

lists each controller with its slot number and what it can do (Rumble, if the driver knows how).

Code: Select all

*USBJoystick_Debug <slot>

adds technical detail: how output reaches the controller, and whether it has an OUT endpoint.

If it says Rumble try

Code: Select all

*USBJoystick_Rumble <slot> 65535 0 800

then

Code: Select all

*USBJoystick_Rumble <slot> 0 65535 800. 

These run the big (low-frequency) motor and then the small (high-frequency) one, for 0.8 seconds each.

Code: Select all

*USBJoystick_Rumble <slot> 0 0

should stop it if anything sticks.


If it doesn't say Rumble, and you're experimenting

Code: Select all

*USBJoystick_SendOut <slot> <bytes> 

sends bytes straight to the controller's OUT endpoint, if it has one. The slot's Debug page shows whether it does.

Code: Select all

*USBJoystick_SendReport <slot> <report-id> <bytes> 

sends a HID output report over the USB control pipe. This is for controllers with no OUT endpoint, such as my simple PlayStation adaptor.

Bytes are in hex. Each command prints one line saying what it sent, or says exactly what was wrong.


On the XB360 wireless malarkey, it would be nice to see if we can set the ring to 'player 1'. So please try these:

Code: Select all

*USBJoystick_SendOut <slot> 01 03 06
*USBJoystick_SendOut <slot> 00 00 08 46 00 00 00 00 00 00 00 00

Do either work? The idea is to stop the four flashing LEDs, and have one steady LED.

The 'pattern' could be varied (that is the last byte of the first line, or the fourth byte of the second, where it's 40+pattern).

Pattern:
00 all off
06 to 09 - LED 1-4 steady
02 to 05 - LED 1-4 flashing
0A - rotating
01 - all blinking


I would find useful/interesting:

• The *USBJoystick_List and *USBJoystick_Debug output.

• The exact commands you tried, and what the controller did.

• If it errors or does nothing, the Reporter output from around that moment.

These commands send raw bytes to your hardware, so a guess might make a controller do something odd. Unplugging and re-plugging the controller should reset it!

[JonAbbott]

I am also interested in controllers like the XBOX360 wireless one, as I recall there being issues with that in the past (flashing lights? poor battery life?).

I have a selection of XB360 wireless controllers, so will try to test this for you.

I also need to update USBJoystick in ADFFS 2.89 and test some games. I'm hoping to also use some of the new SWI to support dual sticks on the couple of games that could use them, Bloodlust and Conqueror spring to mind.

[richw]

I have a selection of XB360 wireless controllers, so will try to test this for you.

Great, thanks. I'm looking to see if I can also buy some knock-offs from eBay, but it's never clear what you're going to get with a clone!

I also need to update USBJoystick in ADFFS 2.89 and test some games. I'm hoping to also use some of the new SWI to support dual sticks on the couple of games that could use them, Bloodlust and Conqueror spring to mind.

I wouldn't rush to those new SWIs just yet: they are very much drafts. I will probably be making some tweaks to them before long. I'm trying to keep some basic functionality in-place (such as the auto-map for the basic Joystick_Read, and then some new SWIs for enumeration and additional axes/buttons, and soon rumble). I also want to be able to expose a slightly lower-level interface which, say, SDL could harness (it has all sorts of community-led cleverness for dealing with the large number of controllers out there in the real world).

I never thought that some legacy games could be candidates for this. Ideally, you don't want to try patching in brand-new controller enumeration and mapping screens (!) so maybe we can think of a way to make that work.

Oh, and I also want to see what the wider community thinks. Ideally, it would become acceptable to end up in the ROOL Wiki/PRM. I appreciate that this may be the most difficult part.

[JonAbbott]

I've just gone to test this and both this and 0.24 trigger an Abort on a Pi3 due to an unaligned read.

I suspect you just need to tweak the compile options, but should you need to look at the code, in the uncompressed 0.24 @ +7858:

Code: Select all

LDR R3,[R3,#2]     ; R3=&2025F3B8

[richw]

Oh, rats! That'll be why someone on the ROOL forums said there was an AODT when they ran it, and I couldn't see why! I'm running on a combination of RPCEmu and Pi 1, so pre ARM v7.

I've re-issued 0.24 based on the ROOL GitLab CI output (which should be the latest Norcroft, which should be v7 safe by default).

For this test version, please see attached. I've gone with ROOL's advice from https://www.riscosopen.org/wiki/documen ... y%20primer and added the compiler flag. My DDE is from 2016, so wasn't making v7-safe code by default.

Would you mind trying again with this module?