Question Teensy Micro Controller simulate Gamecube Controller

Joined
Oct 9, 2017
Messages
45
Likes
11
I was wondering if anyone had any information on the data that is output over the data line of a Gamecube controller, The packet size seems to be around 85 bytes transmitted at about 13.3 - 13.5 khz. From my testing the 'A' button seems to be the 35th bite of data transmitted out every packet. I would love to know more information about this, I can simply probe every button and count the bytes until i see which byte corresponds to each button, but if the work is already done i would love to read about it.

In the end, i'd love to have a github project where anyone could simulate a Gamecube controller with a Teensy micro controller.
 

Aurelio

ᕕ( ᐛ )ᕗ
Staff member
.
.
.
.
.
Joined
Mar 3, 2016
Messages
2,219
Likes
2,937
Portables
2
The GC controller protocol is a 250 kbps protocol. Most requests are made of 24 bits commands followed by a stop bit. The most common command (buttons polling) expects a 8 byte (64 bits + 1 stop bit) answer. If you are not willing to understand my messy asm code you can ask me any question you'd like
 
Joined
Oct 9, 2017
Messages
45
Likes
11
The GC controller protocol is a 250 kbps protocol. Most requests are made of 24 bits commands followed by a stop bit. The most common command (buttons polling) expects a 8 byte (64 bits + 1 stop bit) answer. If you are not willing to understand my messy asm code you can ask me any question you'd like
So feel free to tell me if i am way off, but from what I have read it sounds as if each of the 64 sent bytes are made of two operations. For a (1), it is 3us high, 1us low. For (0) it is 3us low, 1us high. A packet of the 24bit word from the wii is sent to poll the controller to see if it is there. Immediately if the controller is there it will send its 64bit packet of data back to the wii over that data line containing the information of all of the button states. This packet should be completely transfered in exactly 347us after this, the system will not send another button request for 6ms. dose this sound correct so far?
 

Aurelio

ᕕ( ᐛ )ᕗ
Staff member
.
.
.
.
.
Joined
Mar 3, 2016
Messages
2,219
Likes
2,937
Portables
2
So feel free to tell me if i am way off, but from what I have read it sounds as if each of the 64 sent bytes are made of two operations. For a (1), it is 3us high, 1us low. For (0) it is 3us low, 1us high. A packet of the 24bit word from the wii is sent to poll the controller to see if it is there. Immediately if the controller is there it will send its 64bit packet of data back to the wii over that data line containing the information of all of the button states. This packet should be completely transfered in exactly 347us after this, the system will not send another button request for 6ms. dose this sound correct so far?
A (1) is first 1us low and then 3us high (that is important because the signal is driven in an open drain configuration, therefore the devices can only pull down the signal, while it is pulled up by external resistors. After a polling command the reply is sent back in less than few us or the system will detect an error. A reply takes 64bit (+1 stop bit), which means 260us.
The specific software (game) running on the GC/Wii determines how often a polling command is sent. Usually it is sent every frame, therefore every 16/20ms (depending on the region).
 
Top