-
Notifications
You must be signed in to change notification settings - Fork 34
3) The 64Drive
This page describes how the UNFLoader tool and USB library handles the 64Drive flash cart.
The 64Drive is a flashcart developed by marshallh and sold on his retroactive website. It features a very fast 8MB/s USB FTDI chip, and very extensive documentation (Denoted hereafter as "hardware specification" or "hardware spec"). The 64Drive's USB protocol only works if the cart is running firmware versions 2.05 and above. The 64Drive is available in two different hardware revisions, Hardware 1 and Hardware 2 (Denoted hereafter as "HW1" and "HW2" respectively)
On the 64Drive, reads from cartridge space are mapped to SDRAM, meaning that you can use the usb_io_read and usb_io_write functions to address the different cartridge interface devices.
UNFLoader implemented 64Drive communication using the D2XX FTDI library.
HW1 runs in Asynchronous mode while HW2 runs in Synchronous mode. For USB communication, in theory HW2 features a mode called "Extended Address", which allows the 64Drive to support ROMs up to 256MB in size. This functionality does not actually work on the 64Drive, it was presumably going to be added in the next firmware update (which never happened).
After probing the connected devices, it is a matter of comparing the Description and ID values to see if they match up with any of the following:
| Description (String) | ID (DWORD) | |
|---|---|---|
| HW1 | 64drive USB device A | 0x4036010 |
| HW2 | 64drive USB device | 0x4036014 |
Simply call usb_io_read, reading from the Hardware Magic value described in the Registers table on page 2 of the hardware spec. The connected device is a 64Drive if the returned value is equivalent to 0x55444556.
Open the deivce and set its timeouts to a large enough value (by default, 5000 milliseconds is used). If the HW2 is being detected, synchronous mode is set by setting the FT_BITMODE_RESET and FT_BITMODE_SYNC_FIFO bit modes with mask value of 0xFF. Finally, it is recommended to purge the receive and transmission buffers before continuing any further.
As explained in the hardware spec, the 64Drive uses a command based protocol for communication. Everything you need to know about the available commands are already explained there on pages 15 to 21.
To upload a ROM, the N64 must be turned off and the USB must be connected. The 64Drive does not set the CIC and save types by default, and therefore these must be sent with the 0x72 and 0x70 commands respectively (setting the CIC is not required for HW1, but it is for HW2). The 0x20 command is then used to upload the ROM itself, providing the ROM chunk size and the offset in SDRAM to store it in. After every command, the 64Drive will reply with 3 bytes containing CMP and the last byte with the command (so if you sent 0x20, you will receive CMP + 0x20).
The 64Drive has the 0x80 command, which gets the version of the firmware. Mask the received result with 0x0000FFFF. If the result is smaller than 205, then the device will not support debug mode.
In order to send data to the connected PC, follow the instructions outlined in page 14 of the hardware specification document. For the Block Type value mentioned in Param1/Result1, simply use one of the DATATYPE values described in the previous chapter. The data sent by the 64Drive will be automatically formatted in the communication protocol used by UNFLoader (IE the 64Drive will send DMA@ followed by the data header for you, meaning you will not need to append this data manually into what you send through USB).
On the PC side, simply read the 4 bytes DMA header, 4 bytes with the data header, N bytes for the data, and then the CMPH signal.
On page 13 of the hardware spec, the process for arming the USB FIFO to receive data from the PC is explained, and in page 14 it is shown how to disarm the USB FIFO. However the arming process described in the document is slightly wrong. The order in step 2 of the arming process is to arm the buffer and then write P0 and P1. You must first write P0 and P1, then arm the buffer, as when its armed it will instantly read those two registers (this was confirmed by checking 64Drive Verilog).
The hardware spec also claims that you can arm the buffer with any size you want, so long as you repeatedly rearm the USB to service the rest of the incoming data. However, in practice, the 64Drive will lock up if the size of the data is larger than the armed buffer.
One annoying bug regarding the arming process is that any data that is larger than 512 bytes (which is the internal USB buffer's size) has a high chance to get mangled (bytes can go missing, swap places, etc...). This is because the 4 byte alignment is misleading. As soon as the data is larger than 512 bytes, you must align it to 512 bytes. Also, if the data is larger than 512 bytes, due to a 64Drive bug you must append an extra 512 bytes as a safety buffer, as the 64Drive will consistently miss the first 8 bytes it attempts to read from the last 512 byte chuck.
Another interesting point, but the arming size must be larger than zero, otherwise the 64Drive will hang.
Something which isn't explained in the hardware specification (possibly due to a firmware bug) is that leaving the 64Drive armed could cause problems (for one, the game will take longer to boot and the USB CUI could be left in an impossible state). For UNFLoader's USB library, I decided to arm the 64Drive, check if data was received, and then disarm it right after. There is a big problem with this, however. Disarming the USB when there is data waiting to be read will put the 64Drive in an impossible state which can only be corrected by replugging the USB. And the reason that this can happen is because the value 0x2 is being used by two completely different states in the 64Drive (data must be read vs data was just read), most likely as an oversight from marshallh. In order to clear out this 0x2 state, you need to arm the USB and check the state again (because, as stated, disarming could lock up the 64Drive if you do so when data needs to be read). If, after arming, the state continuously reads 0x1 after a while, no more data is incoming and you can safetly disarm the USB. If, after arming, the state goes back to 0x2, that means that the 64Drive just placed data in the address you armed, and so you must read this data or risk losing it.