Add Pokémon Colosseum,XD support

[mizuyoukanao]

Hello, thanks for the great library.
I found a problem where data could not be sent only when running Pokémon Colosseum/XD.
When running Pokémon Colosseum/XD, the GameCube seems to return different data than the other games.
However, i solved the problem by copying line 114 and below of Gamecube.c and changing
else if (receivedBytes == 3 && command[0] == 0x40 && command[1] == 0x03)
to
else if (receivedBytes == 3 && command[0] == 0x40 && command[1] == 0x00)
If you are comfortable with this change, I would appreciate it if you could merge the code.
Thank you.

[NicoHood]

That should be a different data format:

0x00 First 4 bytes: buttons0+1 + X + Y, C-Stick, L+R minimum of both, 0x00 fixed

So in this case we'd need to modify the data to work correct. Now the question is, does Pokemon XD actually use the left/right buttons? Or do they use the dynamic depth feature?

The code could be something like (not tested):

else if (receivedBytes == 3 && command[0] == 0x40 && (command[1] == 0x03 || command[1] == 0x00))
{
  // Minimum of left + right trigger
  if (command[1] == 0x00) {
    if (report->left > report->right) {
      report->left = report->right;
    }
    report->right = 0x00;
  }
  gc_n64_send(report->raw8, sizeof(Gamecube_Report_t), modePort, outPort, bitMask);

[...]

[mizuyoukanao]

Thank you for your quick reply.
Pokémon XD/Colosseum does not use the left/right buttons, dynamic depth feature.
And I've tested the code you attached and it seems to work fine!
I look forward to updates that incorporate this code.

[NicoHood]

I am checking the dolphin code:
https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/Core/HW/SI/SI_DeviceGCController.cpp#L167

And this PR:
#25

It turns out, that my annotations are possibly incorrect. I currently aint got time or a setup to test this. I do not even know what analog A and B would be. There is no such thing on a normal controller. Do you know any custom controller with such buttons?

[NicoHood]

Please try this:
#34

[NicoHood]

Now the question is, if we can simplify this by adding a return on mode 3 into the convert function and always send the dif. Like:

Gamecube_Different_Report_t dif;
gc_report_convert(report, &dif, command[1]);
gc_n64_send(dif.raw8, sizeof(Gamecube_Different_Report_t), modePort, outPort, bitMask);
ret = 3;

And this in the convert function:

    else if (mode == 3)
    {
        return;
    }

The downside is, that for normal reading mode an additional memcpy call is made. I am not sure if that additional time will cause issues, but I guess it will work, if it also works for the other modes that do additional move operations. Could you please compare the flash size?

[NicoHood]

Did you check the flash size difference? Was it a good change?

[mizuyoukanao]

I'm not very good at English, and I'm not sure I fully read your intent... (This text is also written in translation.)
What do you mean by flash?
Which structure are you referring to? (mode0~4? Gamecube_Different_Report_t?)

[NicoHood]

Oh sorry, I was not aware of that.

By flash I mean the flash memory. You can check it like that:

My question is, if the flash memory size increased? Was it a good or bad change?

[mizuyoukanao]

I understood.
"mode3=return" in the conversion function seems to reduce the size of the flash on the contrary.
I tried it with mode0 going through the function, but it didn't cause any noticeable delay.

[NicoHood]

The last commit is not what I wanted. Let me do the cleanup real quick...

[NicoHood]

Closing in favor of: #42