Mad Catz Data Deck serial protocol information ============================================== This document was written by Mark Knibbs . My web page is at http://home.freeuk.net/markk/index.html Version History --------------- 2002-03-07 Second release. Added details of which pins are connected in the serial cable, plus some other minor changes. 2001-09-17 First release. Introduction ------------ The Data Deck product by Mad Catz has two slots for PlayStation memory cards, and connects to an RS-232 serial port. The supplied software allows you to read and write PlayStation memory cards on IBM-compatible PCs running Windows 95 or later. For more information see http://www.data-deck.com/ or http://www.madcatz.com/ The Data Deck is similar in concept to the DexDrive product marketed by InterAct (http://www.interact-acc.com/), the main functional difference being that the Data Deck has two card slots instead of one. The supplied software's native file format is a plain 131072-byte image of all data in the card. It can also save in the ".GME" format used by InterAct's Dexplorer software. The purpose of this document is to explain how to control the Data Deck, so developers can support it in their programs. Mad Catz do not seem to be willing to provide information about the serial protocol. At least, they did not reply to my emails. Please contact me if you have any information to add to this document. The first(?) third-party program to support the Data Deck is Guido Mersmann's MCControl package for Commodore Amiga computers. Contents -------- Conventions used in this document Abbreviations Hardware details General command format List of known commands Calculation of checksum byte Detecting and initialising the Data Deck Operations performed by the supplied software Conventions used in this document --------------------------------- A PlayStation memory card consists of 1024 frames, each 128 bytes long. Number the frames from 0 to 1023 inclusive. Command bytes are given in hexadecimal, and in ASCII where appropriate. Parts of commands not representable in ASCII are given in hex with a $ prefix. For example, 4D 42 48 48 48 BD = MBHHH $BD In various places there are comments after "UNKNOWN:". These are things which I would like to find out about operation of the Data Deck. Abbreviations ------------- DD Data Deck "the software" The program supplied with the Data Deck which runs on IBM PC-compatibles under Windows 95 or later. Hardware details ---------------- The Data Deck has slots for two PlayStation memory cards. It connects to an AC adapter which provides 12V DC, and via a cable to a 9-pin RS-232 serial port. There is a reset button on the underside of the unit. In addition to a red power LED, numbers 1 and 2 next to each slot light green or red when the card is being read or written to respectively. The DD communicates at 9600, 19200 or 38400 baud, 8 data bits, 1 stop bit, no parity. No handshaking is used (the serial cable only has three wires). The default baud rate is 19200, which it reverts to when powered on or reset. The software allows the baud rate to be chosen by the user. Once set, the DD uses that baud rate until switched off or reset, or the software tells it to use another rate. On my system, connecting the DD via a serial port extension cable made it unusable at 38400 baud. However, the DexDrive showed the same problem. Connecting the DD directly to the PC's serial port allowed use at 38400 baud. This may be due to the unshielded serial cables used in the DD and DexDrive. (This may also depend on the brand of memory card???) By comparison, the InterAct DexDrive works at a single rate, 38400 baud. Since the default baud rate used by the DD is 19200, that could cause a perception that the DD is slower than the DexDrive if the user doesn't select the faster rate. The Data Deck only understands commands sent at its current baud rate. Therefore it is essential to initially query the unit at each possible baud rate; it will only respond to one of the queries. Serial cable ------------ There are only three wires in the Data Deck's serial cable: Pin Function --- -------- 5 Signal ground 3 TD (transmit data) 2 RD (receive data) Pin 7 is physically present in the serial connector of my Data Deck, but appears to be unconnected. Pins 1, 4, 6, 8 and 9 are not present. The pins in the 9-pin serial connector are numbered as follows (looking at the Data Deck connector): 5 4 3 2 1 o o o o o o o o o 9 8 7 6 General command format ---------------------- Communication with the Data Deck is performed by sending six-byte commands. In hex, the bytes sent look like 4D xx yy yy yy kk where xx is an upper-case letter specifying the command yy are data bytes specific to that command kk is a check byte; it is the logical NOT of the xx command letter; adding the xx command letter and kk check byte gives $FF. ($4D is M in ASCII.) For example, the "read frame" command letter is $52, R in ASCII. To read frame 1013 from the card in slot 1, you would send the command 4D 52 03 F5 01 AD. Known commands are B $42 set Baud rate C $43 UNKNOWN, BUT APPEARS IN THE PROGRAM EXECUTABLE F $46 Format card K $4B checK for card, return map of free/used blocks if present R $52 Read frame S $53 identify, causes Data Deck to return PSXMCM W $57 Write frame See below for a description of each command except C. UNKNOWN: - Are there any commands other than these seven? What does the DD return if you send an invalid command, or a command with incorrect or invalid parameters? - What does the C command do? This appears in the program executable with the other commands. Could C be short for "change page" or maybe "copy card"? - Does the Data Deck support changing pages with multi-page cards? The supplied software doesn't, but maybe the hardware does? Recommendations --------------- Before issuing any command which reads or writes a card, issue a "check for card" command to confirm that a card is inserted. If reading or writing many frames (e.g. all 1024 frames to create an image file of a card's data), check for card presence after every few frame accesses. Then you can alert the user if the card is removed. List of known commands ---------------------- B - set baud rate ----------------- This command tells the Data Deck to use a certain baud rate. Any command will only be understood if it is sent at the Data Deck's current rate. See below for details of how the supplied software initialises communication. There are three possible arguments depending on the baud rate, in ASCII LLL, MMM or HHH for low, medium or high speed. 4D 42 4C 4C 4C BD = MBLLL $BD Set baud rate to 9600 4D 42 4D 4D 4D BD = MBMMM $BD Set baud rate to 19200 4D 42 48 48 48 BD = MBHHH $BD Set baud rate to 38400 If the Data Deck receives and understands the command, it returns four bytes which depend on the communication speed requested: 43 4F 4B 4C = COKL for 9600 baud ("communication okay, low speed") 43 4F 4B 4D = COKM for 19200 baud ("communication okay, medium speed") 43 4F 4B 48 = COKH for 38400 baud ("communication okay, high speed") The Data Deck's response is sent at the current baud rate. For example, the COKH response to a MBHHH $BD command would be sent at 9600 baud if that is the current rate. If setting a different baud rate, subsequent communication with the Data Deck takes place at the new rate. F - format card --------------- When a card is formatted, frames 0-15 are written to indicate the card is blank. Any saves on the card are no longer accessible after formatting. The format card command provides an efficient way to do this; it is not necessary to send the data for those sixteen frames individually. 4D 46 00 00 01 B9 = MF $00 $00 $01 $B9 Format card in slot 1 4D 46 00 00 00 B9 = MF $00 $00 $00 $B9 Format card in slot 2 The Data Deck returns a single byte on success, $31 = 1 in ASCII. Presumably it returns $30 = 0 for failure. Specifically, the DD writes the usual data to frame 0 ($4D $43 then 125 zero bytes, then $0E). Each of frames 1 to 15 has the following data written: A0000000 00000000 FFFF, 117 zero bytes, A0, i.e. A0000000 00000000 FFFF0000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000000A0 UNKNOWN: - What does the Data Deck returns if no card is inserted? - What does the Data Deck do if the third and fourth bytes of the command are non-zero? K - check for card, return map of free/used blocks if present ------------------------------------------------------------- This command is used to check for the presence of a card, and to determine which blocks are free and which in use. (The Data Deck hardware must automatically read frames 0-15 when it detects a card is inserted.) 4D 4B 00 00 01 B4 = MK $00 $00 $01 $B4 Check slot 1 4D 4B 00 00 00 B4 = MK $00 $00 $00 $B4 Check slot 2 If no card is present, the DD responds with a single byte, $30 = 0. If a card is present, the DD returns sixteen bytes, where each byte is $30 or $31 (0 or 1 in ASCII) depending on whether that block is in use. For any formatted card, the first byte returned will always be $31, indicating that block 0 is in use; block 0 stores directory information. Here are two examples, with the results in ASCII. If an empty, formatted card is inserted, the DD returns 1000000000000000 If blocks 2, 5-8, 12 and 14 are in use, the others free, the DD would return 1010011110001010 If frame 0 of a card contains all zero bytes, the DD returns $30 as the first byte of the sixteen, e.g. 0111111111111111 for a card which is full. (That causes the software to think no card is inserted; you must tell it to repair the card before being able to read or write to it.) UNKNOWN: What does the DD return for the "block map" if there is non-zero garbage in frame 0? R - read frame -------------- To read a single 128-byte frame, use commands of the form 4D 52 0n nn 01 AD = MR $0n $nn $01 $AD Read frame $nnn from slot 1 4D 52 0n nn 00 AD = MR $0n $nn $00 $AD Read frame $nnn from slot 2 where 0n nn is the frame number. For example, to read frame 1013 = $3F5 from the card in slot 2, you would use this command: 4D 52 03 F5 00 AD The Data Deck should return 129 bytes, the 128 bytes frame data plus a checksum byte. See below for how to calculate/validate the checksum. Sometimes (quite often, actually) the DD returns fewer than 129 bytes. It might return 127 or 128, or 0. On my system (with PortMon running to log serial accesses), this seems to happen more often at 9600 baud than at 19200 or 38400. This may happen when the DD has not finished reading that frame from the memory card yet. If this happens, issue the command again. (Obviously, incorporate some kind of limit, i.e. display an error if there is no correct-length response after issuing the read frame command 10 times, or something.) UNKNOWN: If fewer than 129 bytes are returned, can you just read the serial port again to get the remaining bytes, or must the read frame command be sent again? S - identify ------------ This command is used to identify the Data Deck. The supplied software scans each serial port in turn, at each baud rate. (S might be short for search or scan.) 4D 53 53 53 53 AC = MSSSS $AC Identify Data Deck If the Data Deck receives this command (at its current baud rate, of course) it returns six bytes: 50 53 58 4D 43 4D = PSXMCM UNKNOWN: Can the third, fourth and fifth command bytes (SSS) be something else? Try sending MSxxx $AC, where x is any upper-case letter. W - write frame --------------- To write a single 128-byte frame, use commands of the form 4D 57 0n nn 01 A8 = MW $0n $nn $01 $A8 Write frame $nnn to slot 1 4D 57 0n nn 00 A8 = MW $0n $nn $00 $A8 Write frame $nnn to slot 2 where 0n nn is the frame number. The Data Deck returns a single byte, $31 = 1 in ASCII if the command is understood. NOTE: It (often?) returns $31 even if no card is inserted. If it returns $31, you can send 129 bytes. As with the frame read command, this is 128 bytes frame data plus a checksum byte. See below for how to calculate the checksum. If the data is successfully written by the Data Deck it returns $31, else $30. If no card is inserted the DD returns $30. UNKNOWN: What is the response if the checksum is incorrect? It might be normal for the DD to return $30 from time to time (maybe if internal memory is full; this could happen more often at 38400 baud??). In this case the software tries again, starting from sending the 4D 57... write frame command. Also, examining serial logs at 38400 baud I noticed that one time the DD did not return anything after receiving a 4D 57... write command. I have a third-party memory card which seems to be incompatible with the Data Deck. With this, at a certain point the DD returns $30 after the computer sends 129 bytes of data. The software then resends the 4D 57 ... command, and the DD replies with one byte, $54 = T in ASCII. Could the "T" indicate that there was a timeout or timing problem when the DD tried writing that frame to the card? Your program needs to handle that case. Perhaps retry a few times then give up? (The software supplied with the Data Deck seems to get stuck in a loop; after receiving the $54 byte, it retries the 4D 57... command, DD returns $31, and so on. Luckily there is a Cancel button which aborts the process.) For example, to write frame 1013 = $3F5 to the card in slot 2, you would use this command: 4D 57 03 F5 00 A8 Calculation of checksum byte for receiving and sending frame data ----------------------------------------------------------------- To calculate the checksum which follows the 128 bytes of frame data, add the 128 bytes of frame data, the frame number high byte and the frame number low byte together. The checksum is the low byte of the result. Examples: - Frame 0 usually contains 4D 43 (125 zero bytes) 0E The checksum byte for that is $4D + $43 + 0 + ... + 0 + $0E + 0 + 0 = $9E. - If all bytes of frame $0283 are 0, its checksum would be $02 + $83 = $85. - If frame $0001 contains A1 00 00 00 00 60 00 00 01 00 42 45 53 4C 45 53 2D 30 30 30 31 35 47 4D 41 52 4B 20 20 20 (97 zero bytes) A5 its checksum is $5B. Detecting and initialising the Data Deck --------------------------------------- This section describes how the supplied software detects the Data Deck. This section needs to be updated and clarified. The software checks at 9600, then 19200, then 38400. This order is almost certainly irrelevant; you could e.g. check at 38400 baud first. Since the DD's default baud rate is 19200, it will be best to check at that rate first. (The software uses this routine on each COM port in turn, so it only detects one Data Deck, even if more than one is connected.) Note that after issuing a set baud rate command, the software tries to read 4 bytes, which would be the "COKx" response from the Data Deck. However, even if this response is not received the software still sends an identify command. At 9600 baud: Send 4D 42 4C 4C 4C BD = MBLLL $BD (set baud rate to 9600) Try to read 4 bytes (expecting "COKL" response). No bytes returned if DD is not present, or not working at 9600 baud. Note that even if no "COKL" response is received, the software sends an identify command. Send 4D 53 53 53 53 AC = MSSSS $AC (identify command) Try to read 6 bytes (expecting "PSXMCM"). No bytes returned if the DD is not present, or not working at 9600 baud. So Data Deck not found at 9600 baud. Close and reopen serial port at 19200 baud. Send 4D 42 4D 4D 4D BD = MBMMM $BD (set baud rate to 19200) Try to read 4 bytes (expecting "COKM"). No bytes returned if the DD is not present, or not working at 19200 baud. Send 4D 53 53 53 53 AC = MSSSS $AC Try to read 6 bytes (expecting "PSXMCM"). No bytes returned if DD is not present, or not working at 19200 baud. So Data Deck not found at 19200 baud. Close and reopen serial port at 38400 baud. Send 4D 42 48 48 48 BD = MBHHH $BD (set baud rate to 38400) Read 0 bytes (if Data Deck not currently using 38400 baud) Send six bytes, 4D 53 53 53 53 AC = MSSSS $AC Read 0 bytes (if Data Deck not currently using 38400 baud) Once a PSXMCM response is received, the software closes and reopens the serial port at the same baud rate. It sends e.g. MBMMM $BD and should receive COKM from the DD (if baud rate is 19200). This closing and reopening, and sending MBMMM $BD again is probably not necessary. (This needs to be checked.) It is probably okay to, for example, send an MBLLL $BD command at each baud rate. The DD would respond when the command is sent at its current baud rate. You would then set the computer's serial port to 9600 baud and communicate at that rate. Operations performed by the supplied software --------------------------------------------- This section describes what card accesses are performed by the supplied software. Deleting a save: - Write frames 0-15. (More things may go here in a later version.) Card-to-card copying -------------------- The software achieves this by reading all frames from one slot, then writing that data to the other slot. UNKNOWN: Could there be a command that causes the DataDeck to copy from card to card internally, rather than having to pass all data over the serial port twice? Could the unknown C command be used for this??? ---