Joybus Protocol: Difference between revisions

Add 64GB Cable commands and identifier.
(→‎0x00 - Info: known status bytes)
(Add 64GB Cable commands and identifier.)
 
(5 intermediate revisions by 3 users not shown)
Line 1:
The '''Joybus Protocol''' is a proprietary, non-standard, serial protocol by which the N64's [[Serial 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.
 
= Operation =
Line 35:
{{ProtocolTableRow| 0x11 | Reserved | | | ? | ? }}
{{ProtocolTableRow| 0x12 | Reserved | | | ? | ? }}
{{ProtocolTableRow| 0x13{{sup|'''(2)'''}} | Read Keypress | N64 | [[Randnet Keyboard]] | 2 | 7 }}
{{ProtocolTableRow| 0x14{{sup|'''(2)'''}}0x13 | Read GBAGB{{refn|name=luigiPrinter|LuigiBlood (2019). [https://luigiblood.tumblr.com/post/187348407478/reverse-enginnering-the-unreleased-gameboy-printer Reverse enginnering the unreleased GameBoy Printer COLOR].}} | GCN64, GBAGB | GBA[[64GB Cable]], MBC4 GB Cartridge | 3 | 33 }}
{{ProtocolTableRow| 0x15{{sup|'''(2)'''}}0x14 | Write GBAGB{{refn|name=luigiPrinter}} | GCN64, GBAGB | GBA[[64GB Cable]], MBC4 GB Cartridge | 35 | 1 }}
{{ProtocolTableRow| 0x14 | Read GBA | GC, GBA | GBA | 3 | 33 }}
{{ProtocolTableRow| 0x15 | Write GBA | GC, GBA | GBA | 35 | 1 }}
{{ProtocolTableRow| 0x16-0x2F | Unknown | | | ? | ? }}
{{ProtocolTableRow| 0x30 | Force Feedback | GC | Steering Wheel | ? | ? }}
Line 50 ⟶ 52:
|}
<small>'''{{sup|(1)}}''' ''Real Time Clock''</small><br />
<small>'''{{sup|(2)}}''' ''Requires verification, might be offset by one.''</small>
 
= Command Details =
Line 57 ⟶ 58:
 
=== 0x00 - Info ===
This command requests information about the device. Always contains a 2-byte identifier and may contain 1one byte of extra data.
{| class="wikitable"
! Identifier
! Console
! Device
! Third byte (unknown if absentempty, no details known)
|-
| style="text-align:center;"| 0x0500 || style="text-align:center;"| N64 || Controller || Bitfield:<br/>0x04: CRCchecksum error in previous command<br/>0x02: No Pak installed<br/>0x01: Pak installed
{{ProtocolIdentifierRow| 0x0500 | N64 | Dance Pad }}
{{ProtocolIdentifierRow| 0x0001 | N64 | VRU }}
{{ProtocolIdentifierRow| 0x0200 | N64 | Mouse }}
{{ProtocolIdentifierRow| 0x0002 | N64 | Randnet Keyboard }}
{{ProtocolIdentifierRow| 0x0003 | N64 | 64GB Cable, MBC4 GB Cartridge }}
|-
| style="text-align:center;"| 0x0080 || style="text-align:center;"| N64 || 4 Kbit EEPROM || Bitfield: 0x80=Write in progress
Line 116 ⟶ 118:
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 ignoresuses the most significant address bit, (thein correspondingcombination pinwith isthe notstandard physically connectedchip-enable, to anything)activate/disable the pak. 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.
 
=== 0x04 - Read EEPROM Block ===
Line 133 ⟶ 135:
=== 0x05 - Write EEPROM Block ===
If EEPROM is available, this command can be used to write 8 bytes of save data at a time. See "Read EEPROM Block" above for block addressing rules. The 8 bytes of data to write are included in the command immediately following the "block" byte. It may take up to 30 milliseconds for the data to be written to EEPROM.
 
The EEPROM will reply with one byte, 0x80 specifying that the EEPROM was already busy before the write was requested, and 0x00 otherwise.
 
Real EEPROM data storage has inherent unreliability that requires special consideration: EEPROM chips may become corrupted spontaneously due to uncontrollable factors such as power failure during write or memory cell fatigue causing write failures. It is recommended to use a checksum or parity bits in each EEPROM block to check that the data has not been corrupted. EEPROMs used by retail cartridges are rated for up to 100,000 write cycles and may only retain saved data for up to 10 years. Emulators and flashcarts now provide reliable storage for EEPROM commands that do not suffer from these issues.
Line 242 ⟶ 246:
# Read the new RTC time.
# If the new time is within a second of what was written: write back the original time, success; otherwise failure.
 
=== 0x13 - Read from Game Boy Pak ===
Works identically to [[#0x02 - Read Controller Accessory|0x02 - Read Controller Accessory]], down to the address and data CRC, except that it reads from the Game Boy Pak which contains a MBC4 memory controller which supports JoyBus communication through the Nintendo 64 Controller port.
 
=== 0x14 - Write to Game Boy Pak ===
Similar to the previous command, this works identically like [[#0x03 - Write Controller Accessory|0x03 - Write Controller Accessory]], except that it writes to the Game Boy Pak.
 
= Checksums =
1

edit