[FR] Prototype for a new PADEMU driver implementation (360 pad, Wii pad, PS3/PS4 joysticks, pads/joysticks officials & generics, etc) [PADEMU]

[JohnnyonFlame]

Right now it is a prototype that drops into OPL's sources and replaces ds34usb, I'd like to know if there's any IRC, email group, steam chat or forum where I can discuss about my implementation and get feedback on it.

Supports rumble and whatever, but I didn't test multitap yet, don't have any more controllers to do so.

Wiimote Xbox360 Gamepads (Generics) Arcade stick (PS3) Arcade stick (PS4) Arcade stick (Generics)

[rickgaiser]

Hello @JohnnyonFlame , I've been thinking of extending PADEMU also. It's really impressive work by @belek666 so I think you would want to get in contact with him.

I've created https://github.com/rickgaiser/pademu_playground repository to make testing PADEMU more simple, perhaps this is of interest to you also?

Things I've been thinking of:

• the usb bluetooth driver + HCI + l2cap protocols can be split off into a generic bluetooth driver module (preferably into ps2sdk). btstack.irx?
• the ds34bt and ds34usb drivers can be split off into separate PAD drivers. pad_ds34usb.irx and pad_ds34bt.irx?

For example, when using:

• ds34usb: load pademu.irx, pad_ds34usb.irx
• ds34bt: load pademu.irx, btstack.irx, pad_ds34bt.irx
• xb360bt: load pademu.irx, btstack.irx, pad_xb360bt.irx
• wiiuprobt: load pademu.irx, btstack.irx, pad_wupro.irx
• etc, etc...

I think the best place to discuss this is on psx-scene.com forum in the OPL subforum. Or perhaps on ps2-home.com?

[JohnnyonFlame]

Thanks @rickgaiser!

If I ever get around to my other ideas (generic hid pads via USB or BT, etc), this will indeed come in handy. Debugging by launching into OPL consumed 60% of the time I spent coding.

This sounds like a good idea on paper, but I'm not too sure how conservative do I need to be with resource usage when it comes to the IOP Ram, it would be good to hear from someone more experienced than me, seeing this is my first time coding for the PS2, but PADEMU really could use with a bit of a review to lower code duplication.

And yeah, OPL, PADEMU and the related software are a really impressive work. Hope to see it continue to develop and grow. :)

[belek666]

@JohnnyonFlame Great to hear that you are working on new controller implementation. Multitap needs only support 4 pads in drivers. I was also thinking on adding support for generic hid controllers but parsing hid reports to usable format is difficult and PADEMU would need to support buttons remapping.

@rickgaiser I think that we should keep additional modules in OPL as small as possible and keep them simple. Creating generic modules may make adding support for different controllers easier but how much IOP ram it would take? As for btstack for ps2sdk maybe better way would be port some more advanced library like Smalltooth and implement socket api onto it.

Thanks. I'm glad that I could added something usable to great project as OPL is.

[TnA-Plastic]

Thank you for creating the playground @rickgaiser /Maximus32!

I think it is rather awkward to have a new IRX for every new input-device. It would be interesting, if we could rather have only 2 IRX and a set of 'config-files' for different input-devices. That would enable us to have support for almost any input-device which can be connected and it would technically allow button-remapping quite easily (if the structure permits it).

[TnA-Plastic]

On another note, it would be interesting, if @belek666 's BT-Driver or a more stream-lined version of it (not specifically for the current kind of purpose, but a generic driver) could be officially merged into the PS2-SDK! I suppose we could see people playing with this kind of device-connection and build some stuff based on it, like SMS playing audio via a BT-Speaker/Box (just an example). ;)

[rickgaiser]

Thanks. I didn't know it was still being used. I have a lot of local changes in my playground that may be usefull. I'll see if I can clean them up and push them.

If anyone is interested in porting a complete bluetooth stack I would suggest to look here: https://github.com/bluekitchen/btstack. Just clone the repo and start porting. There is no need to add complete git repo's into ps2sdk.

[TnA-Plastic]

Hah... Yes, I am a bit late on the PADEMU-Game... :-)

I use it since the beginning (simply for playing with a DS3 via BT) but I am interested in having a lib, which can retrieve the needed information about the input-device from a 'human readable file'... The idea behind it is to give users the opportunity to create their own kind of 'drivers' and make allot more devices capable of being used on a PS2.

i.e. like a kind of 'BDM' for 'input-devices'.

The 'readable files' would include Device-Specific informations (VID, PID, BUTTON-NUMBER/SIGNAL to Char-link [possibly], etc.)

Technically those files even could be created 'on-the-fly' with a similar approach like that tool which creates an inf for libusb... I don't remember the name of the tool however... :-/

[rickgaiser]

@TnA-Plastic the only use for these drivers (so far) has been for in-game use, so I think these drivers need to be as small as possible. Parsing human readable files would make the driver a whole lot bigger, plus there would still be need to be controller specific drivers.

@JohnnyonFlame did you get the awnsers you where looking for? Do you have a working OPL example or source code somewhere?

[JohnnyonFlame]

@rickgaiser I've got a working prototype on my HDD and on my PS2 currently, Prices for the XBOX360 controllers skyrocketed and I can't get a second pad to actually test this thing.

My main issue is that I'm unsure how will my code act when more controllers are added since I'm not too sure on how to properly work with the mutexes, also there are loads of things I need to rename and some minor code rework. Feel free to @ me on the PCSX2 Discord at #development-homebrew if you have two or more 360 wireless controllers for testing, I'm always on invisible mode but I'll answer whenever I see it.

Still, I tested the prototype by playing the entirety of Silent Hill 3 with the wireless 360 pad, everything worked perfectly, including disconnecting controllers and vibration.

EDIT:: Also, I need an adapter to plug the PS2 into a smaller screen so I can debug this thing without running around the house like an absolute lunatic.

[mirh]

If you are making some generic pad code, couldn't you "wrap HID into whatever the system api is" like ViGEm and similar? Then you could just have some stupid per-pad .ini file to add them.

[TnA-Plastic]

Damn... I had written an in-deep and very long reply and then my SmartPhone went off! 😢

@rickgaiser: Indeed, the in-game-code needs to be as small as possible!

I think it is quite possible to create an 'IDM' ('Input Device Manager/Mapper') which would act like a bridge between the device-drivers (specifically USBD.IRX and something similar but not exactly the same as PADEMU(.IRX[?]) and could map the input to a configured button and most of the necessary code would not run in-game... I think the approach would work with almost the same amount of code/RAM like PADEMU uses during runtime in-game + the added benefit of making more HIDs compatible via external config instead of compiled and thus 'rigid' IRX/Programm + the added benefit, of having button-remapping for any device (even original controllers!).

The 'device-config' doesn't need to be 'human readable, but it atleast should be an external file in this approach (i.e. 'DEVICEID_config.cfg', where 'DEVICEID is replaced by something like a PID-VID-Combo.

That file and its creation could be similar to what 'Zadig' does for 'libusb' on Windows.

A second config 'DEVICEID_Button.cfg' could hold the values which are returned from the input-device (i.e. when a button is pressed) and which PS2-Buttons, or action they correspond to.

I can see a problem for Multi-ELF-games however... There must be taken care of parameter-transition (the button-Config, etc.) for Multi-ELF-games as well, or the input device would stop working after a second-stage-ELF-start. That's a problem for later...

Edit: Oops... I accidentally already posted! I am still updating this post.

[rickgaiser]

Here's what we got: The current situation has USB in a separate module (usbd.irx), and the rest is all in 1 module.

I would suggest to at least split the PADEMU part into a separate irx. Call it pademu/IDM/whatever. Then new projects like this xb360 one will be simpler to add. In theory you could even connect multiple drivers, and play with 1 ds3 AND 1 xb360 controller. Plug and play compatibility with regular controllers would also be very welcome.

Adding button mappings would be possible at the pademu/IDM/whatever level, but it will not be possible to magically support other HID controllers like this. A special PAD driver would still be needed.

EDIT: @TnA-Plastic 'Zadig' matches a VID/PID to the libusb windows driver. So instead of a windows driver you would then need a libusb driver for your device. But you still need a driver. Note that windows and linux also have special drivers for ds3/4/other PAD's.

[TnA-Plastic]

GitHub seemingly doesn't realize, that I edited my post again (time-stamp is wrong)... I hope you all take a look at it again. :'-D

Anyway, I leave it that way. I think those who read it, will understand it.

@rickgaiser: Yes, splitting off the PADEMU into a separate IRX would be good (I am not sure, if it is split off... That's why there are those brakets and a questionmark. ;) )!

You still got me a bit wrong (just like @SP193 got you wrong about BDM and Block-devices)!

IDM is NOT the PADEMU-Part which runs during in-game!

This is, what would be in RAM during runtime in-game: -USBD or 'USBD-BT-Combo' (I mean the stripped and combined code, DS3BT.IRX uses...) -the 'generic-input' to 'PS2-Input'-Programm (a.k.a essentially the PADEMU-Code, but with some changes) -the input-values and their DS2-Counterpart (from the external Config)

IDM would merely act like a configuration-bridge before the game is started during PADEMU-Hooking (during the debug-colors)!

I think this would give us pretty much the same flexibility with HIDs, like BDM gives us with partitions and filesystems on storage-devices! 🙂

Edit (regarding your edit): I think, that splitting off PADEMU like you suggested would help solving that issue, if it really is necessary... (to solve an 'issue')

To put my idea a bit into perspective... I recently had a defect(ive) XBOX-Classic-Controller and soldered a USB-Cable to it... I tested, if it works by simply looking, if it would return values, if I press a button (tested on Linux without a special driver for it, but via libusb simply).

So that's what we could get on the PS2 as well, right? Some values, which we cannot interpret, because of a missing 'driver'.

My idea is, to give PADEMU the missing information by external files and IDM is, what would set up the device during game-launch.

[TnA-Plastic]

To round it all up... Essentially, the Structure-Chart (is that the correct word?) would be quite the same like the one that you posted, but with one difference...

So it would be like this:

-USBD/USB(D)BT on 'the bottom' like now.

-PAD-Driver, which essentially makes sense of the input-values from the HID (those which I can see in the terminal, if I use this libusb-debug utility on Linux [I forgot the name, but will ask my 'living Encyclopedia'.].).

-PADEMU which does the translation from 'input-value' to 'in-game/DS2-button-value'

IDM would read the external device Config files and set up communication between PADEMU and USBD/USB(D)BT.IRX! ;)

It (IDM) would be like a combination of a configureable abstraction (the PAD-Driver, but replaced by a Programm, which gets the values from external files) which is is the code running in-game and then an external part, which namely are those external Configs and possibly a config-generator for the HIDs.

But the biggest part of IDM (which reads the Configs and configures the communication between the two other parts), would not run in-game but only during start.

[kurocygnus]

Any news about this? I'm interested in using my xbox one controller via bluetooth.

[JohnnyonFlame]

My current xbox controller has a broken analog. Until I can fix it I wont be doing much work on this. I should sometime release the current prototype code for others to clean if they feel like it.

And @kurocygnus no, I don't have a Xbox One controller to test, and they're fairly expensive, so that's completely outside of the scope of this project. The code isn't really interchangeable like that.

[iohann95]

Hey, anything new about that?

I want so bad to use generic USB controllers... Like my USB arcade stick for PC...

There's anything someone like me can do? like someone to donate a controller, or someone to donate money... I dont know... It just would be so cool

[drallo]

Likewise - I would be very keen to have arcade stick support for the PS2 as it has some amazing fighting games on it! Can anyone please continue the work for this?

[drallo]

Or even just support for PS3/4 arcade sticks, if generic USB sticks are too hard?

[ElPatas1]

@JohnnyonFlame, discussion about this can also be done here:

https://www.psx-place.com/threads/open-ps2-loader-requests-sugestions-ideas.29712/

Best regards.

[drallo]

So excited that this project has been reopened!! I can’t wait for increased controller support on PS2, especially the PS4 arcade sticks!

[juju4666]

My current xbox controller has a broken analog. Until I can fix it I wont be doing much work on this. I should sometime release the current prototype code for others to clean if they feel like it.

And @kurocygnus no, I don't have a Xbox One controller to test, and they're fairly expensive, so that's completely outside of the scope of this project. The code isn't really interchangeable like that.

I'm not a PS2 programmer or anything, but doesn't the Xbox One controller use Xinput just like the 360 controllers? Most Windows applications detect them as being the same thing (not really comparing Windows to OPL here plz). Xbox One controllers are also very PC friendly; you just connect it and off it goes. I don't recall it being like this with wireless 360 controllers. Anyway, you can also let the community test stuff, right? At least I'm able to volunteer my good old PS2 and my Xbox 360 and Xbox One controllers. I even have the Elite, which would be cool to use with how it maps stuff to the back buttons.

[JohnnyonFlame]

I have acquired a couple 360 controllers and a XBO one. No word when I'll resume work on it. I have, however, managed to dig out the prototypes from my old HDDs, and have most of the setup (missing some power cable) to see it through.

I'd love to see some ideas bounce around on how to make controller support more generic, maybe a vid/pid table on mmcd or mass0:/ pointing to a config file?

[belek666]

@JohnnyonFlame Hi I've made some work on making pademu modular and added modules drafts for xbox controllers. If You like to help me finish them here is my repo https://github.com/belek666/Open-PS2-Loader/tree/modularPademu

[TnA-Plastic]

@JohnnyonFlame You asked if there is a place to communicate (beside the usual boards/forums).

The PS2 Scene Discord might be something for you. --> https://discord.gg/Bd3A7v8

Awesome work @belek666! PADEMU is already cool, but this might become something "really big" (in the sense of "widely used" and supported and maybe even contributed project).

[ez2torta]

Bump so i can know the status of all the forks that have been mentioned here :)

[TnA-Plastic]

The "modular PADEMU"-Idea is still alive. There are just too few people coding for the PS2 and those who do already do a lot of things.