Joybus Protocol: Difference between revisions

Expanded checksum information
(Added data crc info)
(Expanded checksum information)
Line 97:
=== 0x03 - Write Controller Accessory ===
 
== Checksums ==
===Data Cyclic Redundancy Check (CRC)===
There are two different checksums used in some of the official commands. The first is an 8 bit CRC, and the other uses eleven different XOR values based on the position of each set bit. While the former is used for large chunks of data, the latter is used to check the 11 bit address for where that data is written to or read from. These checksums are used to ensure data integrity. The address checksum, which is 5 bits long, is always a part of the communication sent from the console to the device, just after the 11 bit address.
Controller accessory read and write data packets implement a CRC to ensure integrity. The CRC uses an 8 bit polynomial in the form <math>x^7 + x^2 + x^0</math>. This can be represented in the hex form 0x85.
 
=== AddressData CRC ===
The initial value of the CRC is 0x00.
The 8 bit CRC known to be used in the controller accessory read/write commands, and the GBA read/write commands. It uses a standard CRC8 function, with a seed (initial value) of 0x00, and 0x85 for the polynomial. A CRC polynomial is a mathematical way to say that a particular number is used as a mask, or to be applied to the working CRC byte using an XOR operation. The mathematical form can be expressed as <math>x^7 + x^2 + x^0</math>.
 
In every known case, the connected device is always the side which generates this CRC. For read commands, it reads 32 bytes of data from a particular address, calculates the CRC, and sends all 32 bytes plus the CRC byte back to the console. For write commands, it calculates the CRC from the 32 bytes sent by the console, sends the CRC byte back, and performs the write operation. The order in which it does this may differ for different devices. For write commands, the device has a window of approx 62.5 microseconds after the console stop bit, to begin sending the CRC byte.
For peripheral writes, the controller will calculate the CRC of the received packet and return the value to the console.
 
=== Address Checksum ===
For peripheral reads, the controller will calculate the CRC and append it to the end of the packet and form part of the response.
When the console wishes to read data from, or write data to, a particular address on the connected device, it will send the top 11 bits of a 16 bit address, plus a 5 bit checksum. This means these operations must be done in 32 byte chunks, as the lower 5 bits of the address are assumed to be 0, to make room for the checksum. By definition, this checksum is not a CRC, because it doesn't use a cyclic code (as in, there is no bit shifting used), and the XOR value is not constant.
 
The 5 bit checksum is calculated using the following table. The working checksum is initially set to zero. For each bit of the 11 address bits, starting at the upper-most bit, if the bit is set (is 1), then XOR the corresponding byte to the working checksum. If the bit is clear (is 0), do nothing and move onto the next bit.
=== Address CRC ===
{| class="wikitable" style="text-align: center;"
! 15 !! 14 !! 13 !! 12 !! 11 !! 10 !! 9 !! 8 !! 7 !! 6 !! 5
|-
| 0x01 || 0x1A || 0x0D || 0x1C || 0x0E || 0x07 || 0x19 || 0x16 || 0x0B || 0x1F || 0x15
|}
If the resulting checksum matches the one provided by the console, the address is valid.
 
==References==