Add Gamecube Host support

[NicoHood]

It would be interesting to modify the data that is sent to the gamecube or build your own controllers. I also can think of merging the input of two controllers for semi multiplayer of a singleplayer game.

The code is ready and will be published soon. N64 adaption should be similar, but I cannot test it.

[trevor403]

It would be incredibly interesting.

[NicoHood]

I am currently cleaning up the code. It runns extremely smooth and relyable. And I also covert a new bit of the gamecube status report.

The only problem I currently have is that it disables interrupts for a very long time: To ensure that it catches the next Gamecube signal it waits for 70ms (1-66ms max every gamecube signal). For this long time interrupts are disabled. That might be too long for some other programs.

But if you keep this in mind, you can wait for the gamecube, do other stuff and then wait for it again. The loop should be still executed very fast and not much other functions should be used.

The idea would be to use a dedicated MCU for gamecube management. But since you disable interrupts for such a long time inside the reading, you cannot receive serial data from another mcu (for the gamecube controller data for example).

But there are two ways to solve this:

• Build a sketch that can handle this minor disadvantage
• Fill the nop operations of the assembly with manual USART receiving functions. But that'd me very custom and more for an attiny assembly only solution and not for an Arduino solution.

---

Beside this I cleaned up and improved the Gamecube Controller reading. Over the time I learned c++ some better and tried to seperate the basic c reading function with a c++ api. This way you can also use it with a pure c makefile. I kept the pointers for the pins, as this does not need duplicated read/write functions and the timings work pretty well like this. The code is really solid.

I also documented more. I decided to keep the "docs" inside the code, so it explains better why i coded it at a specific section.

I will prepare a PR this day or tomorrow. The Write API and the examples should be updated as well before I push anything.

[NicoHood]

Files are uploaded on the dev2 branch, I will add some minor tweaks. N64 support was not tested, not even compiled anymore. I do not own an n64, I borrowed one a year ago but dont have it anymore. I could fix the code though to make it compile. But I honestly do not want to do that.

[NicoHood]

I noticed that the current example does not work with mario football. The problem is that it polls the gamecube way to fast. You do not have enough time to answer the console, read the controller and respond again. So in the end it is just a workaround which works in some games and the menus. Inside the game itself polling is too fast.

So a dedicated MCU for just answering the gamecube might help. But you'd have to code everything in assembly, with hardcoded pins. You have to receive the data somehow from another mcu via serial or something (or maybe even parallel?) while reading the gamecube poll. I am not sure yet which would be the best idea.

[trevor403]

I have a library of 100 games, I'll test them out tonight.

[NicoHood]

I found the cause of the error. Update incoming.

[NicoHood]

https://github.com/NicoHood/Nintendo/commit/22dbc0092812a03b9518bd6dc81208ffade61cf2

And here is a very nice example: https://github.com/NicoHood/Nintendo/commit/ca939e96fe5d958e55cec29c70c526228f3c1744

It would be nice if you could try this out. I did not test 2 Gamecube Controller ports, as this is mostly not required and can be done with a 2nd mcu. With the fix above you can emulate a controller properly and read another one or multiple in time.