First a little history (skip this if you know about the Linux driver)...
But... We're not done yet. Poking around at the adapter, it appears that 0x13 is not a 'secret' but rather one of several commands, 0x11 for rumble being another. By basically fuzzing the adapter, I've started to work out some of the other commands. The goal of this thread is to document what we know, and allow others to contribute new findings.
So, without further ado, what I found:
VID = 0x057E PID = 0x0337
The adapter exposes two USB endpoints, one in, one out, which we already knew. Commands are written to the in endpoint (0x81) and responses, if any are read from 0x02.
Commands:
So back in 2014, when the adapter first came out, ToadKing managed to sniff the communication between SSB4 and the adapter using a dev board (likely BeagleBone?). From this he (or she) deduced that by sending the byte 0x13 to USB endpoint 0x81, the adapter began spewing back packets containing the data from the controller. AFAICT, ToadKing assumed (claimed?) that the 0x13 was a 'secret knock' so to speak. By the same sniffing method, 0x11 was discovered to be the rumble command. From this, he (she) made Linux drivers that got ported to Windows and OS X.
But... We're not done yet. Poking around at the adapter, it appears that 0x13 is not a 'secret' but rather one of several commands, 0x11 for rumble being another. By basically fuzzing the adapter, I've started to work out some of the other commands. The goal of this thread is to document what we know, and allow others to contribute new findings.
So, without further ado, what I found:
VID = 0x057E PID = 0x0337
The adapter exposes two USB endpoints, one in, one out, which we already knew. Commands are written to the in endpoint (0x81) and responses, if any are read from 0x02.
Commands:
0x11 - Rumble
Send: 5 bytes [0x11, R1, R2, R3, R4]
Receive: none
To turn on rumble, set the corresponding R to 0x01, or to 0x00 to turn off
0x12 - Rest positions
Send: 1 byte [0x12]
Receive: 25 bytes, 1 cmd (0x22) followed by 4 sets of [JoyX, JoyY, CstickX, CstickY, Ltrigger, Rtrigger]
Gets resting or base positions for the analog parts of the controller (joysticks, analog triggers)
If polling has not been started will return all zeros except for byte 0, status?
0x13 - Begin Polling
Send: 1 byte [0x13]
Receive: 37 bytes, 1 cmd byte (0x21) plus 4 sets of 9 bytes:
[status, BtnStateH, BtnStateL, JoyX, JoyY, CX, CY, LTrigger, RTrigger]
The 'knock', will make the adapter begin sending updates to endpoint 0x02 every time it is read.
Required before rumble and rest positions will work?
0x14 - Suspend Polling
Send: 1 byte [0x14]
Receive: 2 bytes [0x24, WasPolling] 1 cmd byte (0x24) plus 0x01 if we were just polling, 0x00 if not
Stops the updates that 0x13 sends, useful if you just need a break, or are no longer interested in data
0x15 - Kill?
Send: 1 byte [0x15]
Receive: ERROR
After sending 0x15 and trying to use the device, libUSB gives an IO error, leading me to believe that 0x15
turns off the adapter and requires it to be unplugged and reconnected to begin working again
0x16 - ???
Send: ??? [0x16, ...]
Receive: ???
Definitely a valid command, but no idea what it does
0x17 - ???
Send: ??? [0x17, ...]
Receive: ???
Definitely a valid command, but no idea what it does
0x16 and 0x17 stall the polling data, just like an incomplete 0x11 packet, while 0x10, 0x18, 0x19, etc appear ignored. This makes me think 0x16 and 0x17 are other commands that require multi-byte packets. Fingers crossed for JOYBUS...
Some more about the status bytes and button masks is known and implemented in the drivers and in Dolphin. I will update this after I read through those and figure out the status bytes for 0x12 and 0x14. Many of the things I initially labeled 'status' appear to actually be the command bytes for the packets the adapter sends back.
Right now I just wanted to get the new info out there and seek any more info people have. I ran through all bytes from 0x00 to 0xFF and these were the only ones that I saw responses to, but there could still be others that don't return or require multi-byte packets. Originally I had hoped that there might be a general purpose JOYBUS mode lurking in there, but the chance of that seems slim (unless it's 0x16 and 0x17). The adapter gives no indication that a GBA link cable was inserted while polling via 0x13 either. In other words, controllers yes, GBA link no. Chime in with any more info you may have and I'll add it above.
