Issue with chineese controlers.

[CSab80]

Hi,

Swiss 927. GameCube PAL. XENO chip.

Some chineese controlers don't work with Swiss.

With the native interface there is no problem, neither while playing a game. But these controlers can't work with Swiss.

Any idea ?

Regards,

Cyril

[Papy-G]

Do you talk about wired or wireless ones? I've read that wireless ones can have weird behavior, while I don't have any to confirm. For the Wired ones, I personnally have two clone flavors (the silicone thumbsticks ones, and the hard plastic thumbstick ones), and no ploblems so far.

[CSab80]

Hi, It's about wired chineese clones. Except Nintendo stickers ou engraves, there are the same. But, strangely, these controlers can be used with another GameCube... Both GC are purple PAL with soldered Xeno chip. I have tried to use old releases (912, 906) : nada... Thanks for your help.

[rapperskull]

Sorry for opening another issue. I couldn't find this one. I would like to bring here what I already said. This particular controller works with the Swiss interfaces and some games (most notably Animal Crossing), but not with others. I don't know if it is the same problem or not.

[rapperskull]

I don't know if this could be useful, but I discovered that the chinese controllers reports 0x09004300 instead of 0x09000300 as type. As I understood from here the third byte represents the status of the device. Unfortunately, I was not able to find what that bit of difference means. Hope this can help.

[Extrems]

This is what I reverse-engineered from the original controller: https://github.com/extremscorner/gba-as-controller/blob/gc/controller/source/main.iwram.c#L77-L85 It has no meaning as far as I know.

[rapperskull]

So it's one of the only two undocumented bits. BTW what does the origin bit do?

[Extrems]

IIRC it's set when holding X + Y + Start for 1.5 seconds.

[rapperskull]

Well, that's not completely true. That bit is clear if the controller is present at startup and set if connected after startup. This means that unplugging and plugging again a controller sets it (and also clears the mode bits). The X + Y + Start combination resets the controller, so the bit is set as a side effect (and also the mode bits are cleared). Incidentally, the only controller I have that does not reset with this combination is the chinese one. Don't know if the two things could be related. BTW unplugging and plugging it again does set the origin bit, but nothing changes with regard to the unknown bit.

[Extrems]

It's cleared after using the origin command. It's essentially a duplicate of the get origin bit in the button data.

[rapperskull]

I can confirm the problem is with Swiss in general, since the same game works when launched from the original disc, but not from SD card, nor from DVD within Swiss. Is there a way to disable some or all patches to try and debug this issue?

[Extrems]

There's no patch that could cause this issue.

[rapperskull]

Do you have any idea of what it could be?

[Extrems]

Nope.

[rapperskull]

Just discovered there are two distinct bugs: one of the two affects some games and was introduced in c622bc4c8dcfada47f2ccab6a8318249738a4f5c, cfce0ee3a79919f83d8fdb48038692bf051fdb61 or bc9a59c531db7811ef4cedd5e97ef01787eaed93, since r963 does not exibit this problem, while r966 does. Unfortunately I was not able to compile older revisions (probably because I need an older version of libogc), but this should narrow it down. Some games, however, still don't work. I tried going back even further, but with no success so far. What I can tell you for sure is that r563 still does not work with The Simpsons Hit & Run.

[Extrems]

That doesn't help in the slightest.

[rapperskull]

If you can provide me with the DOL files for r964 and r965 I can test them to further narrow down the problem.

[Extrems]

It cannot be caused by c622bc4 as it create stronger guarantees (and the code doesn't resemble the PAD library in any way). It cannot be caused by cfce0ee as it's not a functional change. bc9a59c strips out a feature out of the hypervisor, which would no longer trap DSP MMIO accesses.

[rapperskull]

Even if it seems strange, it has to be one of the three. Which one do you think is more plausible?

[Extrems]

bc9a59c, but not for the reasons you think.

[rapperskull]

This is for sure, since I have no clue whatsoever.

[rapperskull]

I recompiled r963 and it desn't work, while the release does. So I think the problem is with libogc.

[rapperskull]

I can confirm the problem is with https://github.com/emukidid/libogc/commit/e7423f4515a3072a77486f0e26c75455fdf12475. I compiled r963 against libogc at this commit and it didn't work, while the commit before (https://github.com/emukidid/libogc/commit/4fd5a44b166e6d044dde96bfd531399494ad4c44) worked fine.

[Extrems]

Sounds like these have an issue with the recalibrate command.

[Extrems]

What do these look like? Black with no logo?

[rapperskull]

Exactly. But they do them in all colors.

[CSab80]

Hi,

Here is the controller because I was opened this thread. It's black, but I've got 4 purple with the same issue.

Thanks for your investigations.

Regards,

Cyril

[rapperskull]

I commented out the code for PAD_Recalibrate and it worked. However, I think the problem is in ___paddoreset or somewhere downstream, since some games are still affected.

[Extrems]

The Simpsons: Hit & Run uses PAD spec 4, which causes PADReset to recalibrate.

[rapperskull]

After some (very crude) debugging I found out that _padorigincallback receives _SI_ERRORCOLLISION as type. What it means, I have no idea, but it prevents the program from calling _padenable.

[Extrems]

It means the device responded while the command was still being transmitted (this is a one-wire serial bus).

[rapperskull]

So maybe the device expects a shorter command? Or does not understand the command at all, replying with an error before the command ends. Is it plausible?

[Extrems]

No device report errors that way. It's either interpreting it as the origin command or the ID command.

[rapperskull]

Strangely enough, now it's receiving _SI_ERROR_NORESPONSE instead. Can't figure out what changed. Maybe this controller just doesn't support calibration and we can just avoid it?

[Extrems]

We already figured that out 6 hours ago...

[rapperskull]

Yes, but is it the behavior of the original SDK?

[Extrems]

The code you're looking at is the state of the Dolphin SDK as of its latest update (minus some minor things). No changes occurred with the Revolution SDK.

[rapperskull]

If so, how does the original game work? BTW I changed if(recal_bits) ret = SI_Transfer(__pad_resettingchan,&__pad_cmdcalibrate,3,__pad_origin[__pad_resettingchan],10,__pad_origincallback,0); to if(recal_bits && !(type&0x00004000)) ret = SI_Transfer(__pad_resettingchan,&__pad_cmdcalibrate,3,__pad_origin[__pad_resettingchan],10,__pad_origincallback,0); in ___padtypeandstatuscallback as a quick and dirty hack and Warrior Within works, but still no luck with Hit & Run. Are there other places I missed where the command is sent?

[Extrems]

You need to patch that function in the game itself.

[rapperskull]

I don't think I have the skills or knowledge to do that, but I think we have accumulated enough knowlendge to fix this issue. If you need me to test something else just ask. Thank you for your involvement.

[Extrems]

As luck would have it, the first controller I bought doesn't have this issue. Sigh.

[rapperskull]

I thought they were all the same. Mine comes from AliExpress.

[Extrems]

This controller I bought is actually kind of impressive. Both software and user-triggered recalibration work, and it understand all the analog modes. It's a shame the mechanical design wasn't so well thought out.

[rapperskull]

I took a picture of the motherboard. Apparently, mine is VER1.1B. I think the board is common between many models, since there are two unused buttons (turbo and slow).

[Extrems]

Looks quite similar to mine, but mine has 20190112 and BL-NGC114-V1.4 silkscreened.

And now I regret disassembling it. Everything is falling off so easily.

The cable connection is interestingly designated "USB".

[rapperskull]

Yes, it was a mess to reassemble: the strain relief was improvised, to say the least.

[Extrems]

The screw around the D-Pad area has to be tightened in a very specific way, or it doesn't work properly.

This is crazy.

[Extrems]

Turns out bit 1 of the status byte represent the Z trigger. Why? I don't know, but the suggested workaround is no longer acceptable.

[Extrems]

Some games, however, still don't work. I tried going back even further, but with no success so far. What I can tell you for sure is that r563 still does not work with The Simpsons Hit & Run.

Which other games? I couldn't find others with PAD spec 4.

[rapperskull]

Some games, however, still don't work. I tried going back even further, but with no success so far. What I can tell you for sure is that r563 still does not work with The Simpsons Hit & Run.

Which other games? I couldn't find others with PAD spec 4.

I think I might have confused the two bugs. I re-tested all my library with r888, and only Hit & Run exibits the exact same problem. There's, however, a different issue: Pokémon Colosseum behaves exactly like Hit & Run, with the exception that it still takes the IGR combo to reboot the console, while Hit & Run seems to completely disable the controller.

[rapperskull]

Today I tested r1047 and both games now work.