Wiimote/Extension Controllers/Guitar

From WiiLi

The Guitar Hero III controller for the Wii is an expansion for the Wii Remote for use with the Guitar Hero series. The Guitar pretends to be a Classic Controller.

1 Communication
2 Guitar reports
3 Translation from guitar buttons to classic controller buttons
4 See Also:
5 External Links

[edit] Communication

Communication uses the same form as the Classic Controller but uses different button mapping.

Data is sent to/received from the classic controller by writing to/reading from address space 0x04A400xx on the Wiimote. Trying to read from/write to that address space without the classic controller being attached will return errorcode 7.

Before the data from the controller can be read, it is necessary to send an initialization command. This is done by writing value 0x00 to address 0x04A40040 (in the beginning it was thought that value 0x01 must be written, but this actually only makes things more complicated):

(52) 16 04 A4 00 40 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

It is now possible to read the controller data. It seems that Bits 8-15 (= Byte 3) of the address don't care when reading the data, so for example reading address 0x04A40000 will return the same data as reading 0x04A4FF00.

This is a hexdump of that address region from a sample classic controller:

04a40000:  FF FF FF FF FF FF FF FF 9F 1E EF 3A FF FF FE FE
04a40010:  FE FE FE FE FE FF FF FF FF FF FF FF FF FF FF DC
04a40020:  DC 11 71 DF 13 7B DA 14 7C DC E8 70 14 1A 7C D7
04a40030:  DC 11 71 DF 13 7B DA 14 7C DC E8 70 14 1A 7C D7
04a40040:  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
04a40050:  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
04a40060:  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
04a40070:  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
04a40080:  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
04a40090:  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
04a400a0:  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
04a400b0:  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
04a400c0:  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
04a400d0:  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
04a400e0:  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
04a400f0:  84 FE FE FE FE FE FE FE FE FE FE FE 9A 1E FD FD

The data is encrypted, but can be decrypted by applying a simple transformation to every byte:

<Decrypted byte> = (<Encrypted byte> XOR 0x17) + 0x17

It is not yet clear why this transformation is necessary. Maybe this isn't necessary if a different command is used for initialization, but for now this works.

After applying this transformation to the hexdump above, the data looks like this:

04a40000:  FF FF FF FF FF FF FF FF 9F 21 0F 44 FF FF 00 00
04a40010:  00 00 00 00 00 FF FF FF FF FF FF FF FF FF FF E2
04a40020:  E2 1D 7D DF 1B 83 E4 1A 82 E2 16 7E 1A 24 82 D7
04a40030:  E2 1D 7D DF 1B 83 E4 1A 82 E2 16 7E 1A 24 82 D7
04a40040:  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
04a40050:  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
04a40060:  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
04a40070:  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
04a40080:  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
04a40090:  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
04a400a0:  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
04a400b0:  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
04a400c0:  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
04a400d0:  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
04a400e0:  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
04a400f0:  AA 00 00 00 00 00 00 00 00 00 00 00 A4 20 01 01

This data has the following meaning:

04a40000:  FF FF FF FF FF FF FF FF 9F 21 0F 44 FF FF 00 00
                                   -----------------
                             Current controller status (see below)

04a40020:  E2 1D 7D DF 1B 83 E4 1A 82 E2 16 7E 1A 24 82 D7
           -----------------------------------------------
           Probably calibration and other (not yet understood) data
                   Data is repeated at 0x04a40030

04a400f0:  AA 00 00 00 00 00 00 00 00 00 00 00 A4 20 01 01
          -----------------------------------------------
           Meaning not yet understood, but seems to be the
           same on all classic controllers. A Nunchuk has
            similar, yet slightly different data at this
         address, so it might be some kind of device type ID

[edit] Meaning of the guitar data

Six bytes define the current state of the classic controller. In the example above, they are

9F 21 0F 44 FF FF

and they have the following meaning:

Value in example	Description	Bit description
0x9F	X-axis value of left/right analogue stick	0-5: X-axis of left analogue stick / 6-7: Bits 3-4 of X-axis of right analogue stick
0x21	X-axis value of right analogue stick /	0-5: Y-axis of left analogue stick / 6-7: Bits 1-2 of X-axis of right analogue stick
0x0F	Y-axis value of right analogue stick / Left shoulder button	0-4: Y-axis of right analogue stick / 5-6: Bits 3-4 of left shoulder button / 7: Bit 0 of X-axis of right analogue stick
0x44	Left/Right shoulder button	0-4: Right shoulder button / 5-7: Bits 0-2 of left shoulder button
0xFF	Button state bitmask 1 (0 = pressed / 1 = released)	0: Unused? / 1: "R" fully pressed / 2: "+" / 3: Home / 4: "-" / 5: "L" fully pressed / 6: Down / 7: Right
0xFF	Button state bitmask 2 (0 = pressed / 1 = released)	0: Up / 1: Left / 2: "ZR" / 3: "x" / 4: "a" / 5: "y" / 6: "b" / 7: "ZL"

[edit] Calibration data

The 16 bytes at 0x04a40020 appear to contain calibration data. An example dump after decoding:

E3 1A 7B E8 20 85 E8 1C 7D E3 17 7B 1D 1A 87 DC

Here is a guess to what these values mean that is consistent with the output from my controller:

The first three bytes appear to describe the left analog stick X axis. These values are the maximum, minimum, and center positions as if the analog stick was reporting a full 8-bit value. Divide by 4 to get useful data for the 6-bit value found in the reports.
Bytes 3-5 appear to describe the left analog stick Y axis. Divide by 4 to convert to the report values.
Bytes 6-8 appear to describe the right analog stick X axis, again as if there was a full 8 bits of output. Since the right analog stick only outputs 5 bits in the reports, these values must be divided by 8.
Bytes 9-11 appear to describe the right analog stick Y axis.
The remaining bytes may somehow describe the shoulder button values. Not sure about this.

We will need hexdumps from more classic controllers to get a clearer view of the meaning of this data.

[edit] Ways of retrieving the classic controller data

There are two different ways to get the current state of the classic controller: By polling and by getting reports. Both ways require that the classic controller has been initialized first.

[edit] Reports

This is probably the preferred way, as the data is automatically sent by the Wiimote, and Wiimote and classic controller data are both contained in one single message sent by the Wiimote.

Once the classic controller is initialized, reports 0x32, 0x34, 0x35, 0x36, 0x37 and 0x3D will contain the six bytes of data (the actual offset depends on the report ID).

Before the data can be used, it needs to be decrypted using the simple transformation algorithm mentioned above.

[edit] Polling

The data can also be retrieved by reading 0x10 bytes starting at address 0x04A40000. In the 0x10 bytes received, the actual data will be at offset 0x8-0xD, but it seems to be impossible to start reading at address 0x04A40008 instead, as different data is returned then.

[edit] Still unknown

What the data at 0x04A40020 means
- Can some more people post a hexdump of that data? By comparing different hexdumps it might be possible to see which bytes are different etc. Cadex
What the data starting at 0x04A400F0 means

[edit] Guitar reports

[edit] Buttons

They come over 6 bytes

The Buttons are encoded over two bytes, b5 and b6 of the report

Initial position of the bytes, with all buttons at neutral:
  b5: 5E
  b6: FF

H  b5 -08
+  b5 -0C
Rt b5 -0E
Lt b5 -20
-  b5 -30
D  b5 -40
R  b5 -80

U  b6 +01
X  b6 -08
Zr b6 -0C
L  b6 -0E
Y  b6 -20
A  b6 -30
B  b6 -40
Zl b6 +80

[edit] Joysticks


  LJ Left Joystick encoded using bytes 1 and 2
  RJ Right Joystick encoded using bytes 1 2 and 3

LJ and RJ at 0:
  5F 01011111 DE 11011110 6F 01101111

LJ at W:
  39 00111001 DE 11011110
LJ at E:
  77 01110111 DE 11011110
LJ at N:
  5F 01011111 F5 11110101
LJ at S:
  5F 01011111 B8 10111000

LJ at NW:
  22 00100010 CB 11001011
LJ at NE:
  4D 01001101 CB 11001011
LJ at SW:
  22 00100010 A1 10100001
LJ at SE:
  4D 01001101 A0 10100000

There are jarring transitions in value at certain points..

LJ from SE towards SEE:
  from  4A 01001010 A8 10101000
  to    4A 01001010 D6 11010110

LJ from E towards NE:
  from  77 01110111 DC 11011100
  to    48 01001000 DC 11011100

LJ from NNE towards N:
  from  46 01000110 C8 11001000
  to    58 01011000 F7 11110111

LG from N towards NNW:
  from  57 01010111 F7 11110111
  thru  29 00101001 F7 11110111
  to    2A 00101010 C8 11001000


LJ at Neutral, RJ moving clockwise:
N      9F 10011111 1E 00011110 13 00010011
NE     DF 11011111 1E 00011110 96 10010110
E      DF 11011111 9D 10011101 60 01100000
SE     DF 11011111 1D 00011101 79 01111001
S      9F 10011111 1D 00011101 FC 11111100
SW     1F 00011111 DD 11011101 F8 11111000
W      1F 00011111 5D 01011101 6F 01101111
NW     1F 00011111 DE 11011110 96 10010110


LJ moving counterclockwise, RJ moving clockwise
LJ/RJ
N/N    9F 10011111 34 00110100 13 00010011
NW/NE  A2 10100010 0B 00001011 96 10010110
W/E    B9 10111001 9E 10011110 60 01100000
SW/SE  A1 10100001 E2 11100010 79 01111001
S/S    9F 10011111 F8 11111000 FC 11111100
SE/SW  0D 00001101 A0 10100000 F8 11111000
E/W    37 00110111 5E 01011110 6F 01101111
NE/NW  0D 00001101 CC 11001100 B6 10110110

Right, this data is damn near useless when I have no values between the middle and the edge. What I want is this:

LJ going slowly from west to east
RJ going slowly from west to east

LJ going slowly from north to south
RJ going slowly from north to south

[edit] Analog Triggers


Analog triggers L and R are encoded with bytes 3 and 4
byte 3 overlaps with RJ

Gradually pressing down L:
6F 01101111 FB 11111011 
6F 01101111 7B 01111011 
8F 10001111 FB 11111011 
8F 10001111 7B 01111011 
AF 10101111 FB 11111011 
AF 10101111 3B 00111011 
AF 10101111 7B 01111011 

Gradually pressing down R:
6F 01101111 DB 11011011 
6F 01101111 DB 11011011 
6F 01101111 C6 11000110 
6F 01101111 C2 11000010 
6F 01101111 C0 11000000 
6F 01101111 CE 11001110 
6F 01101111 CA 11001010 
6F 01101111 C8 11001000 
6F 01101111 34 00110100 
6F 01101111 31 00110001 

Now gradually releasing R:
6F 01101111 34 00110100 
6F 01101111 36 00110110 
6F 01101111 C8 11001000 
6F 01101111 C4 11000100 
6F 01101111 D8 11011000 

And now pressing L+R gradually:
8F 10001111 E0 11100000 
8F 10001111 CE 11001110 
AF 10101111 4A 01001010 
AF 10101111 76 01110110 
CF 11001111 71 01110001 
CF 11001111 10 00010000

Can you please go over the L data again, it seems to be missing way too many values for me to make any sense of it, we had 20 values for R before, and you've given me SEVEN for L.