So I did get a reply from Brook, it was actually speedy, I was very slow with the holidays. After a little back and forth, I got a drop of the v1.0 software, which appears to still be working now. That said, I don't think it'll work forever, given the way the drop is set up. To get the v1.0 firmware for the Zero Pi:
1. Go to the download page for the Zero Pi.
2. Download the firmware updater (Windows).
3. Rename the installer, adding a _BETA to the end (Brook ZERO-Pi Fighting Board_BETA.exe)
4. Run the updater, it should say that the latest version is v1.0 and install that firmware.
Doing this *did* get my Zero Pi to the v1.0 firmware, but I had issues there that are likely specific to my setup: for some reason, the SDL mappings on the Zero Pi were no longer any good, several buttons became completely unmappable in games. I went back to the v1.1 firmware, which didn't have this issue.
crabfists wrote: ↑Thu Jan 06, 2022 1:20 pm
I am wondering why the board detects the MiSTer as a Switch? Is this a quirk of the board or a quirk of MiSTer?
This is an interesting one. To my limited understanding of the MiSTer (I'm primarily concerned about Linux here), it uses the Linux kernel as it's baseline. (Somebody please correct me if I'm wrong, however, the rest of this
should still be accurate.) I did some debugging with the Zero Pi, with both firmware versions, using dmesg, udevadm, and other such tools to try to figure out what is actually happening. With v1.1 of the Zero Pi, the following events are observed:
1. The kernel adds the Zero-Pi (c12/131/4014).
2. The kernel binds it.
3. The kernel is unable to poll the USB device properly: can't set config #1, error -71
4. The kernel unbinds the device.
5. The kernel removes the device.
6. The Zero-Pi presents itself again (f0d/aa/200)
7. The kernel is able to communicate with this and the pad works as expected in Switch mode.
With the v1.1 firmware, there are several different device identifiers for the Zero-Pi:
Xinput mode (probably): c12/131/4014
PS3 mode: c12/130/100
Switch mode: f0d/aa/200
It's worth noting the kernel successfully gets PS3 mode and I suspect that if the PS button was wired to the board and was subsequently pressed after connection it would work. It's very important to note here that Windows only ever has c12/131/4014 show up (I don't know if the others ever do, however, in device manager that is the only one I ever see)
On to my theory of why: I think that when an Xbox 360 controller (what Windows detects this as) is hooked up to a system, it does some early, low level signalling to the device to configure it accordingly. This seems to be a reported issue with other xbox controllers based on an investigation into the github repo of the xpad kernel driver, which manages xinput. The issue here may be, in part, that the Zero-Pi is too smart: when xinput fails, it moves on to using the Switch mode, which seems to be supported in the kernel properly. I believe this is less intentional and more a coincidence than anything.
Sadly, Brook said that they did not have Linux supported by the Zero-Pi, though they had some ideas and may implement something in the future.
In regards to the v1.0 firmware, which I had far worse issues with... Some quick notes (mostly off memory here). The Zero-Pi actually still failed in xinput mode. It initially presented itself as c12/131/4014, the kernel couldn't deal with it, and it came back as c12/130/100. I'm not sure if this actually means it was in some weird PS3 failover state or what, I didn't spend too much time investigating. That said, Select
did work as expected.
Based off this, I believe that the v1.1 firmware may still be preferable to the v1.0 firmware, at least in terms of Linux desktop usage. If MiSTer does not use SDL bindings for the controller, you may be better off with the v1.0 firmware.
I do have a few ideas for making the v1.1 firmware fully work, though I haven't tested them.
1. Use a 5V powered NAND gate to take input from Select and 3P, wiring this up to 3P and wiring Select to Select.
It's been a while since I've done hardware hacks, but assuming this is active low this should work! If it's not active low, the type of gate would simply need to be changed. The basic idea here is pretty simple. The Brook board provides 5V off one of it's headers (I think, need to double check, but some level of VCC is available). To have Select work, both Select and 3P need to be pressed. Using logic gates, it should be possible to have Select press both 3P and Select, while retaining the functionality of 3P.
2. Try to use both headers on the Zero-Pi, allowing 3P to be hooked up directly to a 3P and Select to be hooked up to both Select and a 3P.
I'm not sure if this one would work, but if it does it's far simpler to implement. There are two sets of input headers on the Zero-Pi: the easy header set and the screw terminal set. One might be able to wire things up like this. That said, if the pins on the hearder/screw terminals go to the same pin on the SOC, it likely won't work correctly, as pressing 3P would then always also trigger select.
3. Find a Linux kernel/USB guru who knows more than I do and make a kernel patch to have the correct signalling be sent to the Zero-Pi.
Sadly, I don't have the expertise to do this one myself. That said, I don't actually believe that this would be too crazy a thing to get done. Using Wireshark, it's possible to monitor USB communications. By using Wireshark on the Windows PC, the initial signalling between the Windows NT kernel and the Zero-Pi could be captured, allowing a patch to be written for the Linux kernel that would allow it to send the same signalling, preventing it from ever leaving the initial xinput state.
I'm also trying another thing on the side: the more expensive Brook board (Universal Fighting Board) offers the ability to force xinput mode (Xbox 360 input, in this case) by holding 3P prior to plugging in the board. That may be the simplest solution possible for my application, but may not be for yours.
I'm glad things are working as well as they are, given that there isn't any official support and the Zero-Pi working as well as it does in my case is really more just a happy accident. Hopefully this post is of some help! I'll add a post with the results of the Universal Fighting Board (I'm somewhat optimistic) and will also post if I try any of the Zero-Pi ideas, though I might not implement those if the new board works.
crabfists wrote: ↑Thu Jan 06, 2022 1:20 pm
Not having a select button (or having to press a button combo) would be a deal breaker for me.
One quick thing to note in this regard, the change here was quite intentional for the switch: Select+3P is "-" and Select+4P is "Capture". I don't know how useful it really is to have Capture as an explicit button, as I don't own a Switch, but this seems to have been done intentionally with that in mind. If you were to implement the hardware mod, you would remove the Capture functionality, though I'm guessing that just takes a screenshot which... doesn't really seem that useful, ha.
EDIT: Just adding the result of the UFB here instead of in a new post, as there isn't a whole lot to say since everything is working properly in xinput mode and it doesn't directly pertain to the Brook Zero Pi issues specifically.
