GC Controller Protocol, DOL-003 and DOL-004 (DOL-005)

[RDC]

This is more or less a proof of concept in reading the Data from the controller's than a full blown breakdown of the controller's protocol.

The GameCube controllers, much like their N64 predecessor, use a 1 wire type of communication.

Looking at the plug on the controller, with the flat side on top.

DOL-003

-----------
| 5  3  1 |
| 6  4  2 |
\         /
 \_______/

1- 5v (only for Rumble)
2- Ground
3- Data
4- Not Used
5- Ground
6- 3.3v (3.43v)


DOL-005, Wavebird Receiver

-----------
| 5  3  1 |
| 6  4  2 |
\         /
 \_______/

1- Not Used
2- Not Used
3- Data
4- Not Used
5- Ground
6- 3.3v (3.43v)


The GC polls for the controller roughly every 16.6ms with an 8 bit Command, plus a Stop bit, so 00000000-1. A 0 is Lo for roughly 4us, then Hi for 1us. A 1 is Lo for roughly 1us and Hi for 4us. This timing is different when the controller is returning Data, and is also different between the DOL-003 and DOL-004 controllers as well.

So the 8 bit Polling Command and Stop bit, 00000000-1, that is looking for a controller, on the Logic Analyzer, looks like this. 8 Lo bits followed by the 1 Hi Stop bit.

When a controller is first connected, there is some 'back and forth' between the controller and GC before it starts requesting the Data from the controller over and over. For just reading the button/stick values from the controller all of the 'back and forth' can be skipped and the 24 bit Command can just be be sent to request the Data.

On the DOL-003, after it's all connected up, the GC requests Data twice every 15ms with a 600us pause between each request, so it goes request/Data, 600us pause, request/Data, 15ms pause, repeat it all again. This is only the observation while on the menu screen (no game in the console) so it may be different during actual game play.

The DOL-005 (Receiver) is the same, but has a 16ms pause instead of a 15ms one.

Once everything is connected up, the Command changes from the 8 bit Polling Command to a 24 bit Command to request Data, turn the Rumble on/off and probably a slew of other things as that's more than enough bits to do more than a few things.

The 24 Bit Command to request the controller Data is 01000000-00000011-0000000(0)-1

The last bit (0) before the Stop bit, turns the Rumble on/off. A 1 there turns the Rumble on, while a 0 turns it off.

This makes for a 90 bit long string of Data, the 24 bit Command plus Stop bit sent to the controller, then 64 bits of Data plus a Stop bit is returned from the controller.

The Data is returned MSB first.

Bit		7	6	5	4	3	2	1	0

BYTE0*		0	0	1	ST	Y	X	B	A
BYTE1**		1	L	R	Z	DU	DD	DR	DL
BYTE2	LSX Value	
BYTE3	LSY Value
BYTE4	CSX Value
BYTE5	CSY Value
BYTE6	LTR Value
BYTE7	RTR Value

* The first 3 bits of Byte0, so far anyway, I've always seen as 001 on both the DOL-003 controller and 005 Receiver.

** For bit 7 of Byte1, this is always a 1 on the DOL-003, but is a 0 on the DOL-005, everything else remains the same except for the timing.

The DOL-003 returns Data with a 4us timing. A 0 is 3us Lo and 1us Hi, then a 1 is 1us Lo and 3us Hi.

The DOL-005 returns Data with a closer to 4.45us timing (4.4167 / 4.4583) with a 0 being 3.3750 / 3.3333 Lo and 1.0833us Hi, then a 1 being 1.1us Lo and 3.33us Hi.


Test rig for reading the controller's Data is a PIC16F1516. The connector on the right is going to the PIC, while the one on the left is just a pass thru that goes to the GC for seeing what was going on there. The GC is not turned on for any of this, it's all powered from the PicKit 3 and done with the PIC.

I've only shown the first 2 Bytes of Data being read here from both the DOL-003 and DOL-004 controllers, which are all of the Digital buttons, ST, Y, X, B, A, L, R, Z and the D-pad.

http://s50.beta.photobucket.com/user/RD ... 6.mp4.html

 

[public-pervert]

yes yes yes!!

Are you thinking on emulate the GC controller aswell?

 

[grossaffe]

I'm sure this'll come in handy. I've been looking to make a GCN->PC adapter with a microcontroller eventually when I build a PC.

 

[RDC]

@ public-pervert - I've no plans too as of right now. This one wire communication the thing uses I don't really care for at all, and the timing is such that it has to be done spot on or with a really fast clock, plus I'd have to get into all of the 'back and forth' yak that goes on when a controller is connected to the GC and respond to it correctly each time, which means far, far more testing, debugging and trying out this and that as any number of game could.

It may be something I attempt at some point just to see if I can do it, but for right now I've no desire to go any farther than just reading the controllers like I've done here. I don't see a GC controller emulator being of much use when the wired controllers are fairly cheap and can be cut down to a pretty small size anyway.


@ grossaffe - The Skillz Cube Connection USB did that years ago, and there are quite a few other homebrew jobs as well. Any microcontroller that has USB capability could do it as well, as you only need 1 wire for the GC controller Data line. It was also done years ago in a little different manner here http://www.int03.co.uk/crema/hardware/g ... ontrol.htm

 

[grossaffe]

@ grossaffe - The Skillz Cube Connection USB did that years ago, and there are quite a few other homebrew jobs as well. Any microcontroller that has USB capability could do it as well, as you only need 1 wire for the GC controller Data line. It was also done years ago in a little different manner here http://www.int03.co.uk/crema/hardware/g ... ontrol.htm

Oh, I'm sure it's been done before, but what's the fun in that? The experience could be helpful in future projects as well.

 

[public-pervert]

Of course, I see no reason to emulate a GC controller since they are cheap ancan be cutted really small.

But would be awesome if we could emulate the Wavebird's RX, since controllers missing RX are cheap on Ebay. Then people could buy a cheap controller and make your own RX.

 

[Prog]

Do you plan on looking at other controllers as well? I have a funny feeling that the "unused" pin is used on the Gameboy adapter...
Man, if I could get my hands on a *Can'tSayThisOnTV*ing oscilloscope... maybe my school has one...

 

[RDC]

@ public-pervert - The controller protocol doesn't really have too much to do with the Receiver, it's really 95% or so just a Transmitter/Receiver. There is some GC specific things to it, like when it's connected it lets the GC know what it is, and when it's not receiving anything from the Wavebird it outputs a default button/stick value, so the controller can be turned off or when it's not being used it doesn't sit there doing weirdo things.

There are also 2 versions of the Receiver, a 900MHz one and a 2.4GHz one, so the controller would have to be taken apart to tell which one you needed, and then you'd need to match that exact Frequency as well as deal with whatever protocol they used to communicate with each other on top of the GC portion of it.

The Receivers would require some right expensive tools and take some time to reverse, plus whatever it would cost then time and money wise to build your own after actually figuring it out, which not everyone would be able to do. It really makes the $25 or so they cost a pretty good price when comparing it to all that.



@ ProgMetalMan - I have no plans to look at any other of the GC peripherals right now, the DOL-003 and 004 controllers are all I have here, but if any of them happen across my path I will.

You don't need an O-scope for a preliminary check, which is to look into the end of the adapter plug and see if it has that contact for the 'unused' pin, as Nintendo seems too, at least on their official controllers anyway, only installed the pins that are actually used. A third party adapter might have them all, but it's possible the official one only has the pins it needs to work.