A couple of interesting issues I’ve discovered now that I have 4x 8bitdo v1 adapters to test with:
Issue 1 - init fails if 4x 8bitdo adapters are connected to hub when hub is plugged in or USB64 initializes
If I plug 1-3x 8bitdo v1 adapters into a USB 2.0 hub and plug the hub into the USB64 (or boot the USB64 with the hub already plugged in with 1-3x adapters) the USB64 initializes fine and all 3 work.
If 4x of the 8bitdo adapters are plugged into a hub at the time the hub is plugged into the USB64 (or if it already is plugged in when the USB64 receives power and initializes), the TFT only displays one controller, and the outputs don’t actually pass to the N64 on the one detected controller
However, if I plug 3 in at initialization, so they’re detected as in the first bullet, and then plug the fourth after, all 4 work fine.
I added some debug to the code to get more into, and I can see that it thinks all USB connected controllers are controller 0 when 4 are plugged in to the hub at the time the hub is plugged.
This doesn’t seem to be a power issue - I’ve tried a powered USB hub as well. And it doesn’t seem to be a hub issue, as I’ve tried 3 hubs with the same behavior.
Issue 2 - nondeterministic USB port assignment to N64 output ports
Say you are using 4x controllers with a USB64, and you have all 4 plugged in at initialization. It seems like the controllers are assigned N64 ports randomly, such that the ports on one boot might be USB port 1 = player 2, USB 2 = player 3, USB 3 = player 1, USB 4 = player 4. On the next boot, the same ports will be randomized and could be 1,2, 3, and 4 respectively.
Currently, one can workaround this by booting with just one controller plugged in, then plugging them in in the player order you want one by one, but it’d be ideal if the ports on USB hubs could be initialized in a deterministic order, so that one could just leave the USB64 hooked up to 8bitdo adapters paired to a controller each in a cabinet, and never have to open the cabinet to plug in adapters on each boot to determine which controller is mapped to player 1, 2, 3, and 4 on this boot, or to have to turn on all 4 controllers and try them until you find the one mapped to player 1 on each boot to play single player games.
Neither of these are big deals that don’t have workarounds (just boot with one in the hub and plug the rest in for multiplayer in player order on each boot), and might be upstream issues in the USB library, but thought I’d mark them down just in case!
A couple of interesting issues I’ve discovered now that I have 4x 8bitdo v1 adapters to test with:
Issue 1 - init fails if 4x 8bitdo adapters are connected to hub when hub is plugged in or USB64 initializes
I added some debug to the code to get more into, and I can see that it thinks all USB connected controllers are controller 0 when 4 are plugged in to the hub at the time the hub is plugged.
This doesn’t seem to be a power issue - I’ve tried a powered USB hub as well. And it doesn’t seem to be a hub issue, as I’ve tried 3 hubs with the same behavior.
Issue 2 - nondeterministic USB port assignment to N64 output ports
Say you are using 4x controllers with a USB64, and you have all 4 plugged in at initialization. It seems like the controllers are assigned N64 ports randomly, such that the ports on one boot might be USB port 1 = player 2, USB 2 = player 3, USB 3 = player 1, USB 4 = player 4. On the next boot, the same ports will be randomized and could be 1,2, 3, and 4 respectively.
Currently, one can workaround this by booting with just one controller plugged in, then plugging them in in the player order you want one by one, but it’d be ideal if the ports on USB hubs could be initialized in a deterministic order, so that one could just leave the USB64 hooked up to 8bitdo adapters paired to a controller each in a cabinet, and never have to open the cabinet to plug in adapters on each boot to determine which controller is mapped to player 1, 2, 3, and 4 on this boot, or to have to turn on all 4 controllers and try them until you find the one mapped to player 1 on each boot to play single player games.
Neither of these are big deals that don’t have workarounds (just boot with one in the hub and plug the rest in for multiplayer in player order on each boot), and might be upstream issues in the USB library, but thought I’d mark them down just in case!