Difference between revisions of "Talk:Wiimote"

From WiiBrew
Jump to navigation Jump to search
m (Robot: Cosmetic changes)
Line 333: Line 333:
  
 
I'm really happy it's understood. Is it documented anywhere? [[User:Violet|Violet]] 02:11, 23 July 2008 (CEST)
 
I'm really happy it's understood. Is it documented anywhere? [[User:Violet|Violet]] 02:11, 23 July 2008 (CEST)
 +
 +
 +
== led hard mod ==
 +
 +
any info on the led models.
 +
 +
I'm planning on changing them to each be of a different color.
 +
(blue, red, green, white or yellow)
 +
 +
I know nothing about hardware, so I will probably just by the leds and ask a friend to solder them.

Revision as of 20:49, 17 October 2009

I'll second 84.144.102.151's suggestion that this page be locked from anonymous edits. -- inio 01:09, 21 December 2006 (CST)

After undoing 2 spam-edits I second the suggestion too. FrozenCow

This idea gives me the creeps. If the english wiki would lock every page for a simple spam/vandalism like that one, everything would be blocked in a few days. I believe this is definetly too drastic: there's been only a few edits in total. Please consider unlocking.
MaxDZ8 06:14, 8 August 2007 (PDT)

Clarification on calculating the syncning pin?

could someone make some c-code like function how to calculate the pin?

like xxXXxxXXxxXX <- dongle mac revert it XXxxXXxxXXxx, now turn every pair into bin separately and then add or what??

Could it be that they perhaps used IMA/DVI ADPCM to compress 16-bit wave files to 4-bit for the wii-mote. The source to the implementation can be found here [1] and here [2] I hope someone can check into this as have too little knowledge but it popped to mind reading about the 4-bit soundformat.Galantir 9 sept 2008


Incoming Report
Report ID: 0020:
Data: 00 00 02 00 00 95 FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00
Outgoing Report
Report ID: 0012:
Data: 00 32 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Outgoing Report
Report ID: 0016:
Data: 04 A4 00 40 03 3F 3F 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Incoming Report
Report ID: 0032:
Data: 00 00 FF FF FF FF FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00
Outgoing Report
Report ID: 0011:
Data: 00 00 03 47 00 9C 79 41 00 90 FD 12 00 15 00 00 00 00 00 00 00
Incoming Report
Report ID: 0022:
Data: 00 00 16 00 FF FF FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00
Incoming Report
Report ID: 0032:
Data: 00 00 5D DE 6F 0B FF FF FE 97 00 00 00 00 00 00 00 00 00 00 00
Outgoing Report
Report ID: 0011:
Data: 00 00 03 47 00 9C 79 41 00 90 FD 12 00 15 00 00 00 00 00 00 00
Incoming Report
Report ID: 0032:
Data: 00 00 5D DE 6F 0B FF FE FE 97 00 00 00 00 00 00 00 00 00 00 00
Outgoing Report
Report ID: 0011:
Data: 00 00 03 47 00 9C 79 41 00 90 FD 12 00 15 00 00 00 00 00 00 00
Incoming Report
Report ID: 0032:
Data: 00 00 5D DE 6F 0B FF FF FE 97 00 00 00 00 00 00 00 00 00 00 00
Outgoing Report
Report ID: 0011:
Data: 00 00 03 47 00 9C 79 41 00 90 FD 12 00 15 00 00 00 00 00 00 00
Incoming Report
Report ID: 0032:
Data: 00 00 5D DE 6F 0B BF FF FE 97 00 00 00 00 00 00 00 00 00 00 00
Outgoing Report
Report ID: 0011:
Data: 00 00 03 47 00 9C 79 41 00 90 FD 12 00 15 00 00 00 00 00 00 00
Incoming Report
Report ID: 0032:
Data: 00 00 5D DE 6F 0B FF FF FE 97 00 00 00 00 00 00 00 00 00 00 00
Outgoing Report
Report ID: 0011:
Data: 00 00 03 47 00 9C 79 41 00 90 FD 12 00 15 00 00 00 00 00 00 00
Incoming Report
Report ID: 0032:
Data: 00 00 5D DE 6F 0B FF FD FE 97 00 00 00 00 00 00 00 00 00 00 00
Outgoing Report
Report ID: 0011:
Data: 00 00 03 47 00 9C 79 41 00 90 FD 12 00 15 00 00 00 00 00 00 00
Incoming Report
Report ID: 0032:
Data: 00 00 5D DE 6F 0B FF FF FE 97 00 00 00 00 00 00 00 00 00 00 00
Outgoing Report
Report ID: 0011:
Data: 00 00 03 47 00 9C 79 41 00 90 FD 12 00 15 00 00 00 00 00 00 00
Incoming Report
Report ID: 0032:
Data: 00 00 5D DE 6F 0B 7F FF FE 97 00 00 00 00 00 00 00 00 00 00 00
Outgoing Report
Report ID: 0011:
Data: 00 00 03 47 00 9C 79 41 00 90 FD 12 00 15 00 00 00 00 00 00 00
Incoming Report
Report ID: 0032:
Data: 00 00 5D DE 6F 0B FF FF FE 97 00 00 00 00 00 00 00 00 00 00 00
Outgoing Report
Report ID: 0011:
Data: 00 00 03 47 00 9C 79 41 00 90 FD 12 00 15 00 00 00 00 00 00 00

List of things not yet complete

How we activate Guitar Hero World Tour devices and wireless nunchuks CarlKenner 07:42, 5 January 2009 (UTC)

Purpose of Output report: 0x10

Good question. CarlKenner 07:42, 5 January 2009 (UTC)

Section Reading and writing: Some kind of acknowledgement is received on Input Report 0x22. This has not been investigated yet.

I have documented this report. It has nothing to do with reading and writing. It acknowledges any output report. It is 22 BB BB RR TT, where RR is the output report number, and TT is either 00 or 03 (we don't know what TT's value means). CarlKenner 07:42, 5 January 2009 (UTC)

Use of bit 7 of the first byte of button information.

I have observed this bit occasionally being set, but I can't work out why. CarlKenner 07:42, 5 January 2009 (UTC)

How power button works

We know how the power button works now when held down to turn the Wii off, except we still don't know how it works for turning the Wii on. CarlKenner 07:42, 5 January 2009 (UTC)

How accelerometer LSB's are encoded into button information.

We know this already. CarlKenner 07:42, 5 January 2009 (UTC)

The IR camera configuration data is definitely not fully understood.

Indeed. 07:42, 5 January 2009 (UTC)

More information on the peripheral encryption could be interesting.

Note: This is very likely not intended to be an encryption, but more likely a means of reducing bit transitions over busses to conserve power. Bus Encodng for Low Power

Meaning of first bit of status report flags.

Apparently it indicates a flat battery. CarlKenner 07:42, 5 January 2009 (UTC)

A few comments: The placement of the LSB's in the button information implies that the accelerometers have 9-bit output. That seems a bit strange. Why nine bits rather than 8 bits or 10 bits?

Two of them are 9 bits, one is 10 bits CarlKenner 07:42, 5 January 2009 (UTC)

What is with the two enable bits for the IR Camera? That seems odd.

Why is the peripheral data encrypted but the main data not?

Wiimote on XP thuru WM_INPUT message

I played a bit with a Wiimote using WM_INPUT messages and I want to post the results so other people don't waste their time on this.
The Wiimote is correctly enumerated as a source of WM_INPUT messages and can be registered as a WM_INPUT producer. Vendor and product id are enumerated correctly (0x57e and 0x306 respectively). For simple applications, this may be enough. The wiimote reports 22 bytes foreach packet, which looks like an extended 0x33 mode but I'm not sure.
0] 33 1] 0 2] 20 3] 81 4] 68 5] 82 6] ff 7] ff
8] ff 9] ff 10] ff 11] ff 12] ff 13] ff 14] ff 15] ff
16] ff 17] ff 18] 0 19] 0 20] 0 21] 0

Byte0 is always 0x33 (uncluckly, this doesn't seem to be mode 0x33)
Byte1,2 are the core buttons exactly like described in the wiki.
Byte3,4,5 are accelerometer data matching the wiki.
Byte6,7,8,9 and byte10,11,12,13 have been tested to be IR objects. I haven't checked out the layout but I predict to match the wiki as well.
Byte14,15,16,17 and byte 18,19,20,21 seems to be the other 2 IR object but I can't say for sure. (assuming my observations are correct this makes for 16 IR bytes so it can't be mode 0x33 - win32 is mangling this data in some way)
.

As said, it seems rather nice for simple applications. Unluckly, once the nunchuk is connected the remote will stop reporting continuously. It will only report when a wiimote button is pressed and only partially. Even disconnecting and re-handshaking with the BT stack won't work.

Unluckly, this is a fatal issue so don't waste your time on WM_INPUT!
MaxDZ8 06:46, 8 August 2007 (PDT)

Extension controller identification

"Checking one byte might suffice, as currently they just seem to be mirrors of one another. However, future attachments might use both, so it is advisable to check both."

This is apparently not true, since the Guitar Hero ID is 0x0103, but the article is locked for some reason so I can't fix it. 142.59.172.116 10:57, 27 February 2008 (PST)

The article is only locked from anonymous edits. Log in and you can edit it inio 12:25, 28 February 2008 (PST)

Auto-Syncronization

Is anyone currently working the wiimote libraries to remove the sync on start up requirement? It will get old having to sync wiimotes everytime you go into homebrew that uses one (or more) wiimotes. Seems like if you saved sync information to a sys file you could just have all homebrew auto-sync wiimotes using that same file. (Assuming the same wiimote library is used across homebrew). Also, it would make sense to have the sync button on the wii (Or some other combo of buttons) put the wiimote back into sync mode incase it needs to be resynced for any reason (regenerating the sync sys file). beardface 15:56, 3 May 2008 (CST)

Firmware/hardware reverse-engineering

Here is the information about firmware/hardware reverse-engineering of the Wiimote.

All addresses in hexadecimal.

Link map

EEPROM         8051            Description
0000-006f                      ?
0070-176f                      Host data (MII data, calibration)
16f1-16ff                      The last 15 bytes of report 0x22 FrozenCow
1770-3fff      7f35-a7c4       8051 code/data

I believe the link map is much more complex. Also perhaps some 8051 code is not stored in the EEPROM. For example, there are ljmp to address e0f7, e0ee, etc at location 8407.

Bluetooth HID descriptor block is at EEPROM address 18f7 (more or less).

Memory map

The following are variables, 34xx-35xx should be mapped to RAM.

3445   ?
3446   ?
344c   ?
344d   ?
344e   ?
3452   1 if speaker is enabled, 0 if disabled
347a   request status info flag (1=request pending, 0=none)
347c   request data read flag (1=request pending, 0=none)
34b9   ?
34ac   ?
34fa   (...) Bluetooth input report message buffer
353a   LED state
  bit 3  1=LED on, 0=LED off
  bit 2  1=LED on, 0=LED off
  bit 1  1=LED on, 0=LED off
  bit 0  1=LED on, 0=LED off

Area 7xxx - system calls?

741c   ?
7175   Routine uses registers r3-r7 (5 registers)
7f3f   Bluetooth class ID (0x002504)
8714   Jump table, 32 entries
8774   Call routine indexed by r7 (0-31) of jump table at 8714
8781   Jump table, 32 entries (Bluetooth input report handlers)
87e1   Call routine indexed by r5 (0-31) of jump table at 8781
87ee   Jump table, 11 entries (Bluetooth output report handlers)
880f   Call routine indexed by r5 (0-10) of jump table at 880f
8e94   Enable/disable LEDs (bits 0-3 of r7)
8eb0   Store register a at address pointed by dptr, calls 8eb1
8eb1   Load address pointed by dptr to register r7, calls 8eb5
8eb5   Enable rumble motor (r7=1), disable (r7=0)
8f2e   Enable speaker
8f4c   Disable speaker
8f25   Mute speaker (r7=0), unmute (r7=8)
9421   Initialize variables (notably request flags)
9980   Bluetooth input report handler (ID 0x20)
       Status information message formatting
       Very interesting, contains a lot of hints on the usage of variables
       in the 34xx-35xx area
9a40   Bluetooth input report handler (ID 0x21)
9c68   Bluetooth output report handler (ID 0x10)
9c87   Bluetooth output report handler (ID 0x11)
9ca7   Bluetooth output report handler (ID 0x12)
9d05   Bluetooth output report handler (ID 0x13)
9d2a   Bluetooth output report handler (ID 0x14)
9d4f   Bluetooth output report handler (ID 0x15)
9dc8   Bluetooth output report handler (ID 0x16)
9e2a   Bluetooth output report handler (ID 0x17)
9ea5   Bluetooth output report handler (ID 0x18)
9ed8   Bluetooth output report handler (ID 0x19)
9efe   Bluetooth output report handler (ID 0x1A)

(helper routines)

a4c7   dptr = r6:r7, a = r5^3
a567   r7 = @dptr, a = (@dptr>>2) & 0x3f
Bluetooth command handlers

Bluetooth input report handlers parameters

Input
 r5     ?
 r6:r7  Bluetooth report data
  offset 0      ?
  offset 1      report number
  offset 2      first byte of data
Return value
 r7=0, ok
 r7=3, error

Special function registers

7f00    ?
7f01    ?
7f03    ?
7f04    ?
 1:0    10 when speaker enabled
        00 when speaker disabled
7f05    ?
7f07    ?
7f0a    GPIO port
 bit 5  enable/disable LED
 bit 4  enable/disable LED
 bit 3  enable/disable LED
 bit 2  enable/disable LED
 bit 1  1=enable rumble motor, 0=disable rumble motor
7f0b    ?
7f0d    ?
7f0f    ?
7f5d    ?
 bit 7  1 when speaker enabled, 0 when speaker disabled

On-board EEPROM hardware

EEPROM is TSSOP8 chip ST M24128 or equivalent type (128Kbit).

This is an I2C memory with a Write Control input (WC#) that allows protecting the entire contents of the memory against unwanted writes. When WC#=1, memory cannot be written (read-only), when WC#=0, memory can be read or written.

The WC# pin is pulled up by a 0402 10K resistor (R38) located nearby. WC# must also be connected to the Broadcom chip because the contents of the EEPROM are modified by some Bluetooth commands. Anyway the pin tied to WC# on the Broadcom chip is an open-collector output, which means that WC# can safely be forced to ground externally (through the test point) to enable temporary EEPROM memory writes.

Location of test points:

SCL     Test point TP102
SDA     Test point TP101
WC#     Test point TP01

Questions

  • Is there a CRC in the EEPROM firmware?
  • Where is the entry point of the firmware? Is there one actually?
  • How does 8051 core communicate with the Bluetooth stack?

Beeloot 12:42, 27 May 2008 (PDT)

Single-press reconnection?

Connection to the Wiimote using the 1+2 sync sequence works sometimes, and single-press reconnection is understood.

I'm really happy it's understood. Is it documented anywhere? Violet 02:11, 23 July 2008 (CEST)


led hard mod

any info on the led models.

I'm planning on changing them to each be of a different color. (blue, red, green, white or yellow)

I know nothing about hardware, so I will probably just by the leds and ask a friend to solder them.