Changes

revert it XXxxXXxxXXxx, now turn every pair into bin separately and then add or what??

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 [http://sox.sourceforge.net/] and here [ftp://ftp.cwi.nl/pub/audio/adpcm.shar.] I hope someone can check into this as have too little knowledge but it popped to mind reading about the 4-bit soundformat.[[User:Galantir|Galantir]] 9 sept 2008

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 [http://sox.sourceforge.net/] and here [ftp://ftp.cwi.nl/pub/audio/adpcm.shar.] I hope someone can check into this as have too little knowledge but it popped to mind reading about the 4-bit soundformat.[[User:Galantir|Galantir]] 9 sept 2008

----

----

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.<br />

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.<br />

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).

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.<br />

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.<br />

<tt>

<tt>

0] 33   1] 0     2] 20   3] 81   4] 68   5] 82   6] ff   7] ff<br />

0] 33 1] 0 2] 20 3] 81 4] 68 5] 82 6] ff 7] ff<br />

8] ff   9] ff   10] ff 11] ff 12] ff 13] ff 14] ff 15] ff<br />

8] ff 9] ff 10] ff 11] ff 12] ff 13] ff 14] ff 15] ff<br />

16] ff 17] ff 18] 0   19] 0   20] 0   21] 0

16] ff 17] ff 18] 0 19] 0 20] 0 21] 0

</tt>

</tt>

Byte3,4,5 are accelerometer data matching the wiki. <br />

Byte3,4,5 are accelerometer data matching the wiki. <br />

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. <br />

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. <br />

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)<br />.

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)<br />.

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.

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.

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. [[User:142.59.172.116|142.59.172.116]] 10:57, 27 February 2008 (PST)

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. [[User:142.59.172.116|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 [[User:Inio|inio]] 12:25, 28 February 2008 (PST)

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

== Auto-Syncronization ==

== 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). [[User:beardface|beardface]] 15:56, 3 May 2008 (CST)

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). [[User:beardface|beardface]] 15:56, 3 May 2008 (CST)

== Firmware/hardware reverse-engineering ==

== Firmware/hardware reverse-engineering ==