N64brew Wiki

Joybus Protocol: Difference between revisions

Page Discussion

Joybus Protocol (view source)

Revision as of 16:37, 20 July 2023

2,353 bytes added ,  9 months ago
Add 64GB Cable commands and identifier.
VisualWikitext
(Add command details for EEPROM and RTC)
(Add 64GB Cable commands and identifier.)
 
(9 intermediate revisions by 4 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 26:
{{ProtocolTableRow| 0x04 | Read EEPROM | N64 | Cartridge | 2 | 8 }}
{{ProtocolTableRow| 0x05 | Write EEPROM | N64 | Cartridge | 10 | 1 }}
{{ProtocolTableRow| 0x06 | Read RTC{{sup|'''(1)'''}} StatusInfo | N64 | Dōbutsu no Mori (Animal Forest) Cartridge | 1 | 3 }}
{{ProtocolTableRow| 0x07 | Read RTC{{sup|'''(1)'''}} Block | N64 | Dōbutsu no Mori (Animal Forest) Cartridge | 2 | 9 }}
{{ProtocolTableRow| 0x08 | Write RTC{{sup|'''(1)'''}} Block | N64 | Dōbutsu no Mori (Animal Forest) Cartridge | 10 | 1 }}
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. TheAlways N64contains a 2-byte identifier and 1one byte of extra data. The N64 Controller is the only confirmed device to use the 3rd byte, where 0x02 is used if no pak is inserted, and 0x01 is there is. Other devices must still be investigated further.
{| class="wikitable"
! Identifier
! Console
! Device
! Third byte (if empty, no details known)
{{ProtocolIdentifierRow| 0x0500 | N64 | Controller }}▼
|-
| style="text-align:center;"| 0x0500 || style="text-align:center;"| N64 || Controller || Bitfield:<br/>0x04: checksum 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| 0x00800x0003 | N64 | 464GB KbitCable, EEPROMMBC4 GB Cartridge }}
|-
{{ProtocolIdentifierRow| 0x00C0 | N64 | 16 Kbit EEPROM }}▼
| style="text-align:center;"| 0x0080 || style="text-align:center;"| N64 || 4 Kbit EEPROM || Bitfield: 0x80=Write in progress
|-
| style="text-align:center;"| 0x00C0 || style="text-align:center;"| N64 || 16 Kbit EEPROM || Bitfield: 0x80=Write in progress
{{ProtocolIdentifierRow| 0x2004{{sup|'''(1)'''}} | N64 | Densha de Go }}
{{ProtocolIdentifierRow| 0x0004 | GBA | Game Boy Advance }}
Line 112 ⟶ 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 124 ⟶ 130:
{{ProtocolIdentifierRow| 0x00C0 | 16 Kibibits (2048 bytes) | 0-255 }}
|}
 
In a 512 byte EEPROM, the top two bits of block number are ignored: blocks 64-255 are repeats of the first 64
 
=== 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.
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. Real EEPROMs used by cartridges are rated for up to 100,000 write cycles and may only retain saved data for up to 10 years. Emulators and flashcarts provide alternative storage for EEPROM commands that do not suffer from these issues.▼
 
▲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. Real 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 alternativereliable storage for EEPROM commands that do not suffer from these issues.
 
=== 0x06 - Read Real-Time Clock StatusInfo ===▼
In order to permit using both an EEPROM and the RTC at the same time, the RTC does not respond to command 0, and has its own identify command.
 
▲=== 0x06 - Read Real-Time Clock Status ===
If RTC (Real-Time Clock) is available, this command will return a 2 byte identifier (0x0010) and a status byte. If RTC is not available, this command will respond with three bytes containing zero.
 
{| class="wikitable"
! Status Byte Bit
! Meaning
! Description
{{ProtocolIdentifierRow| 7 (0x80) | Stopped | RTCClock is readyhalted, forand blockit 2is safe to bewrite writtento block 2 }}
{{ProtocolIdentifierRow| 0x006-2 (0x7C) | RunningUnused | RTCThese isbits readyhave for block 2never tobeen beseen readset }}
{{ProtocolIdentifierRow| 1 (0x02) | Crystal failure | If this bit is set, the crystal is not working }}
{{ProtocolIdentifierRow| 0 (0x01) | Battery failure | If this bit is set, the supply voltage of the RTC became too low }}
|}
 
=== 0x07 - Read Real-Time Clock Block ===
 
The RTC read command sends 2 bytes (1 for the command, 1 for block selection) and responds with 8 bytes of block data plus a status byte that has the same meaning as the "RTC Info" command's status byte.
 
The RTC has three blocks each containing 8 bytes of data:
 
Line 149 ⟶ 166:
! Comment
{{ProtocolIdentifierRow| 0 | Control registers | Determines the current clock "mode" }}
{{ProtocolIdentifierRow| 1 | Unused | Unknown8 purpose,bytes theoreticallyof SRAMbattery-backed storageSRAM }}
{{ProtocolIdentifierRow| 2 | Date/Time Fields | The current date and time in binary-coded decimal }}
▲{{ProtocolIdentifierRow| 0x05003 | N64Empty | ControllerAlways 0 }}
|}
 
The top six bits of the block number are ignored: reading from or writing to blocks above the first 4 will wrap within the first four.
RTC Block 0 (Control Registers) use the first 16 bits to control which "mode" the clock is in. The remaining 6 bytes of the response are unused.
 
All RTC reads also include a status byte with the same meaning as the "Read RTC StatusInfo" command's status byte.▼
 
====RTC Block 0 (Control Registers)====
Byte 0:
{| class="wikitable"
! Bit number
! Value
! Mode
! Description
{{ProtocolIdentifierRow| 0x00047-2 (0xFC) | Set ClockEmpty | Clears write-protection bits, sets the stopAlways bit0 }}
{{ProtocolIdentifierRow| 0x03001 (0x02) | RunWrite ClockProtect | Sets write-protection bits,Write clearsprotects thefield stop2 bit(RTC) }}
{{ProtocolIdentifierRow| 0 (0x01) | Write Protect | Write protects field 1 (NVRAM) }}
|}
 
Byte 1:
RTC Block 1 (Unused) has no discernible purpose. It is not used by Animal Forest, and is not implemented by emulators or flashcarts.▼
{| class="wikitable"
! Bit number
! Mode
! Description
{{ProtocolIdentifierRow| 7 (0x80) | Unknown | Exists, changeable, no visible function }}
▲{{ProtocolIdentifierRow| 0x00C06-3,0 (0x79) | N64Empty | 16 KbitAlways EEPROM0 }}
{{ProtocolIdentifierRow| 2,1 (0x06) | RTC Stop | If either bit is set, stops RTC from counting }}
|}
 
Bytes 2, 3, 6, and 7 always read back as 0.
 
Bytes 4 and 5 contain 7- and 6- bit numbers respectively that can be updated but have no visible function.
 
====RTC Block 1 (SRAM)====
▲RTC Blockblock 1 (Unused) has no discernible purpose. It is not used by Animal Forest, and is not implemented by emulators or flashcarts.
 
====RTC Block 2 (Date/Time)====
RTC Blockblock 2 (Date/Time Fields) updates once per second with 8 bytes of data representing the current date and time. The fields are encoded using packed binary-coded decimals:
 
{| class="wikitable"
Line 181 ⟶ 220:
|}
 
====RTC Block 3 (Empty)====
▲All RTC reads also include a status byte with the same meaning as the "Read RTC Status" command's status byte.
RTC block 3 always reads back all zeroes.
 
=== 0x08 - Write Real-Time Clock Block ===
The RTC write command sends 10 bytes (1 for the command, 1 for block selection, and 8 for the block data) and responds with a status byte that has the same meaning as the "Read RTC StatusInfo" command's status byte. The block data to write matches the same format as the block read responses in "Read RTC Block" above.
 
The most-compatible routine for setting the time with the Joybus Real-Time Clock is:
# Send "Write RTC Block" command to Control Registers (Block 0) with "Setwrite Mode"protect disabled and clock stopped (0x0004...).
# Wait 20 milliseconds for RTC block to write.
# Send "Read RTC Status" command, check for "Stopped" (0x80) status: if stopped, proceed; otherwise abort.
# Send "Write RTC Block" command to Date/Time Fields (Block 2) with new time to set.
# Wait 20 milliseconds for RTC block to write.
# Send "Write RTC Block" command to Control Registers (Block 0) with "Runwrite Mode"protect enabled and clock running (0x0300...).
# Poll "RTC Read Status" command until "Running" (0x00) status.
# Wait 500 milliseconds before sending "RTC Read Block" command to Date/Time Fields (Block 2)
Line 206 ⟶ 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 =
LuigiBlood
1

edit

Retrieved from "https://n64brew.dev/wiki/Special:MobileDiff/4043...4804"