Controller recognition Intermittently fails with Retro-Bit controllers

[jerellsworth]

I'm still doing research on this, but I wanted to go ahead and start an issue in case there's any previous work on it (I couldn't find any other mentions on the internet).

I've found that, in some situations, no button inputs from Retro-Bit 6-button controllers are detected. Sometimes power cycling the MD fixes it, but usually not. I presume that something about these controllers is out-of-spec in a way that JOY_init, in particular, is vulnerable to.

What I've found:

• Problem occurs with several different instances/colors of this product: https://www.amazon.com/Retro-Bit-Official-Genesis-Controller-6-Button-Arcade/dp/B07NXX77V1?ref_=ast_sto_dp&th=1
• The problem does not occur for commercial games.
• The controller works when wired through a Team Player.
• Games affected do not explicitly invoke any joypad initialization code and rely on SGDK defaults.
• Games work fine in several emulators and with OEM 3-button pad.
• Tested with SGDK 1.90 (Sorry it's not most recent, but I don't think joypad stuff changed in 2.00).
• Tested on a USA OEM Model 2.
• Tested loading via Mega Everdrive X5 and Pro.

You might assert that these controllers aren't supported, which is fair enough, but they are extremely common and prominent on Amazon so it would be nice if they worked.

I'll post more as a do further research. Let me know what I can do to help. I appreciate all the work y'all do on this project.

[jerellsworth]

I wrote a minimal test rom to check what was happening https://github.com/jerellsworth/joytest. After initializing, the port that the controller is in registers as PORT_TYPE_UNKNOWN and the joypad as JOY_TYPE_UNKNOWN.

[RealMalachi]

I see two potential culprits:

1. TH_CONTROL_PHASE makes all controllers start with TH low, whereas pretty much every 6pad protocol I've seen starts with TH high. This slight difference might be throwing off some aftermarket 6pads that were only tested with the usual TH high protocol.

2. SGDK relies on the last TH low write to receive a nybble of bytes that are all set. This was planned to be used for additional controllers by Sega, but that ended up not happening going off of Sega Saturn documentation of the MDs 6pad. It doesn't rely on all those bits being set, but it does rely on two of them which due to there positions compared to all the other nybbles, I could easily see an aftermarket reproduction making them clear instead of set like they're meant to be.

Semi-related to this problem, I ran into some issues with this type of aftermarket controller in SGDK projects, IIRC also Mortal Kombat 3 as well, where any time you press MODE it'll activate the controllers 3pad compatibility mode, instead of only doing that when the console boots up or when it's being plugged in. This prevents it from acting as a button when it needs to, and also risks accidentally pushing the MODE button when holding the controller tightly and disabling the extra buttons. To fix that, you have to unplug the controller because the controller itself was set to 3pad mode, not the software.
I'll be doing some controller tests soon, hopefully both of these issues can find a resolution out of that.

[jerellsworth]

@RealMalachi Thanks for taking a look at this!

[RealMalachi]

I've done some test on my aftermarket controller. As I thought, it's directly correlated to reading the last TH low nybble, which seems to "reset" the controller in a way, allowing any press of the MODE button to act as if it was the first.
This isn't actually that bad, because that nybble can still be used for initial controller detection, just not every single frame like how SGDK currently handles it. I'll try to get a retro-bit controller after christmas, let's hope its problem has a similar solution