Joybus Protocol: Difference between revisions

Jump to navigation Jump to search
Content added Content deleted
(Add my RTC research)
Line 26: Line 26:
{{ProtocolTableRow| 0x04 | Read EEPROM | N64 | Cartridge | 2 | 8 }}
{{ProtocolTableRow| 0x04 | Read EEPROM | N64 | Cartridge | 2 | 8 }}
{{ProtocolTableRow| 0x05 | Write EEPROM | N64 | Cartridge | 10 | 1 }}
{{ProtocolTableRow| 0x05 | Write EEPROM | N64 | Cartridge | 10 | 1 }}
{{ProtocolTableRow| 0x06 | Read RTC{{sup|'''(1)'''}} Status | N64 | Dōbutsu no Mori (Animal Forest) Cartridge | 1 | 3 }}
{{ProtocolTableRow| 0x06 | RTC{{sup|'''(1)'''}} Info | 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| 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 }}
{{ProtocolTableRow| 0x08 | Write RTC{{sup|'''(1)'''}} Block | N64 | Dōbutsu no Mori (Animal Forest) Cartridge | 10 | 1 }}
Line 124: Line 124:
{{ProtocolIdentifierRow| 0x00C0 | 16 Kibibits (2048 bytes) | 0-255 }}
{{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 ===
=== 0x05 - Write EEPROM Block ===
Line 130: Line 132:
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.
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.


=== 0x06 - Read Real-Time Clock Status ===
=== 0x06 - Real-Time Clock Info ===
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.

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.
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"
{| class="wikitable"
! Status Byte
! Status Byte Bit
! Meaning
! Meaning
! Description
! Description
{{ProtocolIdentifierRow| 0x80 | Stopped | RTC is ready for block 2 to be written }}
{{ProtocolIdentifierRow| 7 (0x80) | Stopped | Clock is halted, and it is safe to write to block 2 }}
{{ProtocolIdentifierRow| 0x00 | Running | RTC is ready for block 2 to be read }}
{{ProtocolIdentifierRow| 6-2 (0x7C) | Unused | These bits have never been seen set }}
{{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 ===
=== 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 "Read RTC Status" command's status byte.
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:
The RTC has three blocks each containing 8 bytes of data:
Line 152: Line 158:
! Comment
! Comment
{{ProtocolIdentifierRow| 0 | Control registers | Determines the current clock "mode" }}
{{ProtocolIdentifierRow| 0 | Control registers | Determines the current clock "mode" }}
{{ProtocolIdentifierRow| 1 | Unused | Unknown purpose, theoretically SRAM-backed storage }}
{{ProtocolIdentifierRow| 1 | Unused | 8 bytes of battery-backed SRAM }}
{{ProtocolIdentifierRow| 2 | Date/Time Fields | The current date and time in binary-coded decimal }}
{{ProtocolIdentifierRow| 2 | Date/Time Fields | The current date and time in binary-coded decimal }}
{{ProtocolIdentifierRow| 3 | Empty | Always 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 "RTC Info" command's status byte.

====RTC Block 0 (Control Registers)====
Byte 0:
{| class="wikitable"
{| class="wikitable"
! Bit number
! Value
! Mode
! Mode
! Description
! Description
{{ProtocolIdentifierRow| 0x0004 | Set Clock | Clears write-protection bits, sets the stop bit }}
{{ProtocolIdentifierRow| 7-2 (0xFC) | Empty | Always 0 }}
{{ProtocolIdentifierRow| 0x0300 | Run Clock | Sets write-protection bits, clears the stop bit }}
{{ProtocolIdentifierRow| 1 (0x02) | Write Protect | Write protects field 2 (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| 6-3,0 (0x79) | Empty | Always 0 }}
{{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 block 1 is not used by Animal Forest, and is not implemented by emulators or flashcarts.


====RTC Block 2 (Date/Time)====
RTC Block 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:
RTC block 2 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"
{| class="wikitable"
Line 184: Line 212:
|}
|}


====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 ===
=== 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 Status" command's status byte. The block data to write matches the same format as the block read responses in "Read RTC Block" above.
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 "RTC Info" 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:
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 "Set Mode" (0x0004).
# Send "Write RTC Block" command to Control Registers (Block 0) with write protect disabled and clock stopped (0x0004...).
# Wait 20 milliseconds for RTC block to write.
# Wait 20 milliseconds for RTC block to write.
# Send "Read RTC Status" command, check for "Stopped" (0x80) status: if stopped, proceed; otherwise abort.
# 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.
# Send "Write RTC Block" command to Date/Time Fields (Block 2) with new time to set.
# Wait 20 milliseconds for RTC block to write.
# Wait 20 milliseconds for RTC block to write.
# Send "Write RTC Block" command to Control Registers (Block 0) with "Run Mode" (0x0300).
# Send "Write RTC Block" command to Control Registers (Block 0) with write protect enabled and clock running (0x0300...).
# Poll "RTC Read Status" command until "Running" (0x00) status.
# Poll "RTC Read Status" command until "Running" (0x00) status.
# Wait 500 milliseconds before sending "RTC Read Block" command to Date/Time Fields (Block 2)
# Wait 500 milliseconds before sending "RTC Read Block" command to Date/Time Fields (Block 2)