Line 83: |
Line 83: |
| | | |
| ===SPI flash=== | | ===SPI flash=== |
− | So far, only one savegame FLASH chip has been identified. The chip identifies as a 0xC22211. The JEDEC manufacturer ID is Macronix, and despite the chip label saying 25L1001, the JEDEC ID matches the MX25L1021E. Datasheet at: http://www.macronix.com/QuickPlace/hq/PageLibrary4825740B00298A3B.nsf/h_Index/3F21BAC2E121E17848257639003A3146/$File/MX25L1021E,%203V,%201Mb,%20v0.01.pdf. However, the MX25L1021E doesn't support the 4 bit wide transmission that the 3DS uses to talk to the SPI flash. It is thus likely that this is a custom flash chip. | + | So far, only one savegame FLASH chip has been identified. The chip identifies as a 0xC22211. The JEDEC manufacturer ID is Macronix, and despite the chip label saying 25L1001, the JEDEC ID matches the MX25L1021E. Datasheet at:<br> |
| + | http://www.macronix.com/QuickPlace/hq/PageLibrary4825740B00298A3B.nsf/$defaultview/3F21BAC2E121E17848257639003A3146/$File/MX25L1021E%2C%203V%2C%201Mb%2C%20v1.1.pdf?OpenElement <br> |
| + | http://www.beilenet.com/download/MX25L1021E,%203V,%201Mb,%20v0.01.pdf (old version mirror) <br> |
| + | However, the MX25L1021E doesn't support the 4 bit wide transmission that the 3DS uses to talk to the SPI flash. It is thus likely that this is a custom flash chip. |
| | | |
| ===Format=== | | ===Format=== |
Line 90: |
Line 93: |
| | | |
| ===Protocol=== | | ===Protocol=== |
− | The communication protocol between the 3DS system and the 3DS gamecard has changed almost completely in comparison with the DS and DSi gamecard communication protocol. | + | The communication protocol between the 3DS system and the 3DS gamecard has changed almost completely in comparison with the [http://problemkaputt.de/gbatek.htm#dscartridgeprotocol DS and DSi gamecard communication protocol]. |
| | | |
| After the sixth transfer, commands change size from 8 bytes to 16 bytes. Possibly a new encryption is used, such as AES CTR. | | After the sixth transfer, commands change size from 8 bytes to 16 bytes. Possibly a new encryption is used, such as AES CTR. |
| + | When 16-byte commands are used, the data bus maintains the value 0x00 until the card signals it is ready by clocking a single byte 0x01, followed by the actual data. After each 0x200-byte block of actual data, a 4-byte standard CRC32 of the block data (before encryption) follows. |
| | | |
| Here's a set of sample gamecard commands that a 3DS sends to a 3DS gamecard: | | Here's a set of sample gamecard commands that a 3DS sends to a 3DS gamecard: |
Line 105: |
Line 109: |
| |<tt>2000</tt> | | |<tt>2000</tt> |
| |<tt>9F00000000000000</tt> | | |<tt>9F00000000000000</tt> |
− | | | + | |? |
| |Reset | | |Reset |
| |- | | |- |
| |<tt>0000</tt> | | |<tt>0000</tt> |
| |<tt>71C93FE9BB0A3B18</tt> | | |<tt>71C93FE9BB0A3B18</tt> |
− | | | + | |? |
| |Unknown | | |Unknown |
| |- | | |- |
| |<tt>0004</tt> | | |<tt>0004</tt> |
| |<tt>9000000000000000</tt> | | |<tt>9000000000000000</tt> |
− | | | + | |? |
| |Get gamecard ID, response=9000FEC2 | | |Get gamecard ID, response=9000FEC2 |
| |- | | |- |
| |<tt>0004</tt> | | |<tt>0004</tt> |
| |<tt>9000000000000000</tt> | | |<tt>9000000000000000</tt> |
− | | | + | |? |
| | Get gamecard ID, response=9000FEC2 | | | Get gamecard ID, response=9000FEC2 |
| |- | | |- |
| |<tt>0004</tt> | | |<tt>0004</tt> |
| |<tt>A000000000000000</tt> | | |<tt>A000000000000000</tt> |
− | | | + | |? |
| | Unknown, response=00000000 | | | Unknown, response=00000000 |
| |- | | |- |
| |<tt>0000</tt> | | |<tt>0000</tt> |
| |<tt>3E00000000000000</tt> | | |<tt>3E00000000000000</tt> |
− | | | + | |? |
| | Enter 16-byte command mode. | | | Enter 16-byte command mode. |
| |- | | |- |
| |<tt>0200</tt> | | |<tt>0200</tt> |
| |<tt>82000000000000000000000000000000</tt> | | |<tt>82000000000000000000000000000000</tt> |
− | | | + | |? |
| | Get header | | | Get header |
| |- | | |- |