Joybus Protocol: Difference between revisions
Added information on the train controller, and 0x02/0x03 commands
(Added EEPROM identifiers for 0x00 Info command) |
(Added information on the train controller, and 0x02/0x03 commands) |
||
Line 1:
The '''Joybus Protocol''' is a proprietary, non-standard, serial protocol by which the N64's [[Peripheral Interface]] (as well as the GameCube and Game Boy Advance) communicates with controllers, controller accessories ([[Controller Pak]], [[Rumble Pak]], etc.), [[Randnet Keyboard|keyboards]], [[Nintendo 64 Mouse|mice]], [[Game Pak|game cartridges]], and other devices plugged into the console.
[[File:Joybus_Bits.svg|thumb|270px]]
The protocol utilizes four types of bits: Zero, One, the Console Stop Bit, and the Controller Stop Bit. Zero, One, and the Controller Stop Bits are 4μs long, while the Console Stop Bit is 3μs. Communication is always initiated by the console, by sending an 8 bit (one byte) command to the device plugged in (not necessarily always a standard controller). A Console Stop Bit will usually follow after this command byte unless there is more data.
Line 9:
The default state of the data pin is HIGH. If the connected device isn't in the process of sending a signal, it should not default to sending a HIGH signal (either set to LOW for reading, high-impedance, or disconnect). Wrongly setting the pin HIGH may disrupt the console and will prevent intermediate devices from reading any console signals.
Because all commands are exactly 8 bits long, there can be a total of 256 commands. However, only about 16 are known for the N64, and a few more for GameCube and Game Boy Advance. Games also have the ability to define custom commands with or without extra data, but official controllers or devices will not understand them.
Line 21:
{{ProtocolTableRow| 0xFF | Reset & Info | N64, GC, GBA | All | 1 | 3 }}
{{ProtocolTableRow| 0x00 | Info | N64, GC, GBA | All | 1 | 3 }}
{{ProtocolTableRow| 0x01 | Controller State | N64 | [[Controller]], Mouse, Densha de Go, Dance Pad, Fishing Rod | 1 | 4 }}
{{ProtocolTableRow| 0x02 | Read Controller Accessory | N64 | [[Transfer Pak|Transfer]], Controller, [[Bio Sensor]], and Rumble Paks | 3 | 33 }}
{{ProtocolTableRow| 0x03 | Write Controller Accessory | N64 | Transfer, Controller, Bio Sensor, and Rumble Paks | 35 | 1 }}
Line 29:
{{ProtocolTableRow| 0x07 | Read RTC{{sup|'''(1)'''}} Block | N64 | 64DD, Animal Forest | ? | ? }}
{{ProtocolTableRow| 0x08 | Write RTC{{sup|'''(1)'''}} Block | N64 | 64DD, Animal Forest | ? | ? }}
{{ProtocolTableRow| 0x09-0x0D | Unknown | N64 | [[Voice Recognition Unit
{{ProtocolTableRow| 0x0E | Reserved | | | ? | ? }}
{{ProtocolTableRow| 0x0F | Unknown | | | ? | ? }}
Line 52:
<small>'''{{sup|(2)}}''' ''Requires verification, might be offset by one.''</small>
=== 0xFF - Reset / Info ===
While identical to 0x00 in what data is returned to the console, if a device has an intended reset function, it should be performed when this command is sent. The N64 controller for example will reset the internal position of its analog stick to (0, 0), essentially recalibrating it. Other devices may have similar functionality, or none at all, but either way they should still send back the same data as if the 0x00 command was sent.
Line 63:
! Device
{{ProtocolIdentifierRow| 0x0500 | N64 | Controller }}
{{ProtocolIdentifierRow| 0x0500 | N64 |
{{ProtocolIdentifierRow| 0x0001 | N64 | VRU }}
{{ProtocolIdentifierRow| 0x0200 | N64 | Mouse }}
Line 94:
==== Densha de Go ====
[[File:Train-controller-diagram.jpg|thumb|Input diagram of Densha de Go! train controller.|200px]]
==== Dancepad ====▼
The game Densha de Go! used an exclusive train controller instead of the standard tri-wing controller. It had five buttons, and two multi-position levers. Refer to the right image for corresponding positions and values for each lever.
[[File:Train-controller-response.svg|980px]]
<small>''(<code>Acc</code> refers to the accelerator lever)''</small>
While more devices exist that use this command, specific response information is not known at this time.
=== 0x02 - Read Controller Accessory ===
Reading data from Paks connected to the bottom of a controller, is performed by the console sending this command plus two bytes. These bytes contain an 11 bit address, and a 5 bit checksum which is explained [[#Address Checksum|in the next section]]. The address used is still 16 bits long, however the lower 5 bits will be zeros, meaning addresses can only point to blocks of 32 bytes.
The controller will attempt to read 32 bytes from the Pak starting at the provided address. Upon returning the data bytes, a CRC byte is also returned ([[#Data CRC|also explained below]]). It must begin responding with data within about 62.5 microseconds.
=== 0x03 - Write Controller Accessory ===
Similar to reading from a Pak, the write command is followed by two bytes for the address and checksum. But 32 bytes are also provided for writing to the Pak. The controller is still required to respond with a CRC byte for the received data, and it must begin responding within about 62.5 microseconds.
How the Pak interprets the address and data is up to the Pak in question. The Controller Pak ignores the most significant address bit (the corresponding pin is not physically connected to anything). The Rumble Pak appears to use some kind of flip-flop/toggling logic on certain pins to control it. The Transfer Pak is a gameboy cartridge interface with bank switching. Other homebrew Paks could be utilized in many other ways too.
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.
| |||