Memory Card: Difference between revisions
| Revision as of 02:45, 23 October 2026 RemmyLee (design-study: the lede rule no longer applies to wiki pages) | Revision as of 02:46, 23 October 2026 RemmyLee (GTE, MDEC, controllers, Memory Card, SIO and expansion port at register depth) | ||
| Line 1: | Line 1: | ||
| + | --- | ||
| + | title: Memory Card | ||
| + | type: component | ||
| + | summary: Removable 128-kilobyte save memory on the Memory Card slots. | ||
| + | category: Hardware | ||
| + | --- | ||
| + | |||
| + | ## Overview | ||
| + | |||
| + | The Memory Card is a device that keeps data after a reset or power off. The main unit has two connectors for it. A Multi tap connects more cards to one of them.[^hw15] A card may be inserted or removed while the power is on.[^ovr53] The card shares the serial lines of the controller port, and the console addresses it with the byte 81h where a controller uses 01h. The byte exchange is otherwise the same as the [controller protocol](/hardware/controller/protocol/).[^spxaddr] | ||
| + | |||
| + | Sony gives the following specifications:[^ovr53] | ||
| + | |||
| + | Table: Memory Card specifications | ||
| + | |||
| + | | Item | Specification | | ||
| + | | --- | --- | | ||
| + | | Capacity | 120 Kbytes at format (accessed in 128-byte sectors) | | ||
| + | | Communication configuration | Synchronous serial communication sharing the controller port | | ||
| + | | Access speed | No access for 20 ms after reading 1 sector; maximum continuous reading speed about 10 Kbyte/sec | | ||
| + | | Other | May be inserted and removed without turning the power off; 100,000 reads guaranteed | | ||
| + | |||
| + | The memory is 128 Kbytes in 16 blocks of 8 Kbytes, and each block is 64 sectors of 128 bytes. The first block holds the directory and the other 15 blocks hold files.[^spxsize] Those 15 blocks of 8 Kbytes are the 120 Kbytes that Sony lists as the capacity at format.[^ovr53] Sony made Memory Cards for the PlayStation only in this one size.[^spxnotes] The [Memory Card file system](/formats/memory-card-fat/) page describes the directory block and the layout of a file. | ||
| + | |||
| + | ## BIOS Access | ||
| + | |||
| + | The BIOS provides the basic card services: the connection check, the logical format test and access in sectors of 128 bytes. So that controller reading and both connectors can be served together, the BIOS accesses a card on every second vertical blank and transfers one sector per access.[^ovr54] | ||
| + | |||
| + | Table: Memory Card BIOS | ||
| + | |||
| + | | Item | Contents | | ||
| + | | --- | --- | | ||
| + | | Start timing | After a vertical blanking interrupt the controller is read, then the card connection and the hardware are checked | | ||
| + | | Data transfer | Driven by a receive interrupt for each byte | | ||
| + | | Effective speed | 30 sectors/sec = 3.75 Kbyte/sec | | ||
| + | | CPU load | 2.5% when reading continuously from 2 cards; 3.2% when writing continuously to 2 cards | | ||
| + | |||
| + | The effective speed of the BIOS is well below the 10 Kbyte/sec that the card itself allows. Every vertical sync interrupt also clears the events of the HwCARD descriptor. Functions that wait for the vertical interrupt, such as VSync() of libgpu, can therefore miss a card event.[^ovr53] [^ovr54] | ||
| + | |||
| + | ## Card Events | ||
| + | |||
| + | The Memory Card library signals its results through events of two source descriptors:[^ovr53] | ||
| + | |||
| + | Table: Events associated with the Memory Card | ||
| + | |||
| + | | Source descriptor | Event class | Meaning | | ||
| + | | --- | --- | --- | | ||
| + | | HwCARD | EvSpIOE | Processing complete | | ||
| + | | HwCARD | EvSpERROR | Card no good | | ||
| + | | HwCARD | EvSpTIMOUT | No card | | ||
| + | | SwCARD | EvSpIOE | Processing complete | | ||
| + | | SwCARD | EvSpERROR | Card no good | | ||
| + | | SwCARD | EvSpTIMOUT | No card | | ||
| + | | SwCARD | EvSpNEW | New card or uninitialized card | | ||
| + | |||
| + | ## Card Presence and Format | ||
| + | |||
| + | A card holds a bit switch called the unconfirm flag. The flag is set when the card is inserted and cleared by _card_clear(), so it reveals that a card has been replaced.[^ovr54] By default a card with the flag set cannot be read or written, and any attempt fails, so a program cannot write to the wrong card by mistake.[^ovr55] | ||
| + | |||
| + | Sony gives the following procedure for testing a card:[^ovr54] | ||
| + | |||
| + | 1. Test for the card with _card_info(). An IOE event means that a card already confirmed is still present: go to step 5. A NEWCARD event means that a card not yet confirmed is present: go to step 2. A TIMOUT event means that no card is present. A communication error is also possible, so the test is retried. | ||
| + | 2. Confirm the card with _card_clear(). A failure means that the card was removed or a communication error occurred. In that case return to step 1. | ||
| + | 3. Test the logical format with _card_load(). An IOE event means that the card is formatted: go to step 5. A NEWCARD event means that it is not formatted: go to step 4. Otherwise return to step 1. | ||
| + | 4. Format the card with format(). On success go to step 5, and otherwise return to step 1. | ||
| + | 5. Perform input and output through the file system. | ||
| + | |||
| + | Sony requires that a program always ask the player before it formats a card, and never use automatic initialization.[^ovr58] | ||
| + | |||
| + | ## File System | ||
| + | |||
| + | The kernel reaches a card through the file system as the device bu:[^ovr56] | ||
| + | |||
| + | Table: Memory Card file system | ||
| + | |||
| + | | Item | Contents | | ||
| + | | --- | --- | | ||
| + | | Device name | buX0: (X = connector number 0 or 1) | | ||
| + | | File name | ASCII characters, up to 21 characters | | ||
| + | | Directory structure | None | | ||
| + | | Control unit | Slot of 8 Kbytes (64 sectors), the file size unit | | ||
| + | | Number of slots | 15 per card (maximum 15 files) | | ||
| + | | Automatic replacement sector function | 20 replacement sectors per card | | ||
| + | |||
| + | The size of a file is given in slots when the file is created and cannot be changed afterwards. When it creates a file, the file system joins any fragmented free space left by deleted files to provide the capacity.[^ovr57] Sony's product catalog calls the slot a block.[^ovr58] | ||
| + | |||
| + | The bu device supports non-blocking access. When a file is opened with O_NOWAIT, read() and write() return as soon as the request is registered with the driver, and the end of the transfer is reported by an event.[^ovr57] | ||
| + | |||
| + | Sony fixes the first part of each file name. The product SLPS-00001 therefore gives file names that start with BISLPS-00001:[^ovr58] | ||
| + | |||
| + | Table: Memory Card file names | ||
| + | |||
| + | | Bytes | Contents | Notes | | ||
| + | | --- | --- | --- | | ||
| + | | 0 | Magic number | Always 'B' | | ||
| + | | 1 | Region | Japan 'I', North America 'A', Europe 'E' | | ||
| + | | 2 to 11 | Title | SCE product number | | ||
| + | | 12 to 20 | User/Public | ASCII, ends with 0x00 | | ||
| + | |||
| + | The PlayStation does not check the region code.[^ovr58] | ||
| + | |||
| + | ## Multi Tap | ||
| + | |||
| + | On a Multi Tap each card is addressed as port number x 16 + card number, where the card number is 0 to 3:[^ovr1315] | ||
| + | |||
| + | Table: Memory Card channels on the Multi Tap | ||
| + | |||
| + | | Slot | Port 1 | Port 2 | | ||
| + | | --- | --- | --- | | ||
| + | | A | 0x00 | 0x10 | | ||
| + | | B | 0x01 | 0x11 | | ||
| + | | C | 0x02 | 0x12 | | ||
| + | | D | 0x03 | 0x13 | | ||
| + | |||
| + | At the byte level the slot is selected by the address byte, which becomes 8nh for slot n from 1 to 4.[^spxtap] | ||
| + | |||
| + | ## Read Command | ||
| + | |||
| + | A sector is read with command 52h ("R"). The sector number is 0 to 3FFh:[^spxread] | ||
| + | |||
| + | Table: Memory Card read sequence | ||
| + | |||
| + | | Send | Reply | Content | | ||
| + | | --- | --- | --- | | ||
| + | | 81h | | Memory Card address | | ||
| + | | 52h | FLAG | Read command; receive the FLAG byte | | ||
| + | | 00h | 5Ah | Memory Card ID 1 | | ||
| + | | 00h | 5Dh | Memory Card ID 2 | | ||
| + | | MSB | (00h) | Sector number, upper byte | | ||
| + | | LSB | (pre) | Sector number, lower byte | | ||
| + | | 00h | 5Ch | Command acknowledge 1 | | ||
| + | | 00h | 5Dh | Command acknowledge 2 | | ||
| + | | 00h | MSB | Confirmed sector number, upper byte | | ||
| + | | 00h | LSB | Confirmed sector number, lower byte | | ||
| + | | 00h | ... | Data sector (128 bytes) | | ||
| + | | 00h | CHK | Checksum (MSB xor LSB xor all data bytes) | | ||
| + | | 00h | 47h | End byte ("G", good) | | ||
| + | |||
| + | (pre) means that the reply normally repeats the previous byte sent, and a reply in parentheses is not significant.[^spxnote] For an invalid sector number a Sony card returns FFFFh as the confirmed number and ends the transfer without data. Third-party cards typically use the number AND 3FFh and send that sector, and some of them send eight 5Ch bytes after the end byte.[^spxread] | ||
| + | |||
| + | ## Write Command | ||
| + | |||
| + | A sector is written with command 57h ("W"):[^spxwrite] | ||
| + | |||
| + | Table: Memory Card write sequence | ||
| + | |||
| + | | Send | Reply | Content | | ||
| + | | --- | --- | --- | | ||
| + | | 81h | | Memory Card address | | ||
| + | | 57h | FLAG | Write command; receive the FLAG byte | | ||
| + | | 00h | 5Ah | Memory Card ID 1 | | ||
| + | | 00h | 5Dh | Memory Card ID 2 | | ||
| + | | MSB | (00h) | Sector number, upper byte | | ||
| + | | LSB | (pre) | Sector number, lower byte | | ||
| + | | ... | (pre) | Data sector (128 bytes) | | ||
| + | | CHK | (pre) | Checksum (MSB xor LSB xor all data bytes) | | ||
| + | | 00h | 5Ch | Command acknowledge 1 | | ||
| + | | 00h | 5Dh | Command acknowledge 2 | | ||
| + | | 00h | 4xh | End byte: 47h good, 4Eh bad checksum, FFh bad sector | | ||
| + | |||
| + | ## Get ID Command | ||
| + | |||
| + | Command 53h ("S") is answered only by Sony cards. After the two ID and two acknowledge bytes the card returns 04h, 00h, 00h and 80h. psx-spx suggests that these may be the number of sectors (0400h) and the sector size (0080h), but their meaning is not confirmed.[^spxid] | ||
| + | |||
| + | Any other command byte ends the transfer at once, or occasionally after one more byte that reads FFh.[^spxinvalid] | ||
| + | |||
| + | ## FLAG Byte | ||
| + | |||
| + | The FLAG byte is 08h at power on and whenever a card is inserted. Bit 3 shows that the directory has not been read yet, so it reveals a change of card, but it is cleared by a write and not by a read. Games therefore usually write a dummy sector to 003Fh to clear it, which wears that sector more than the others.[^spxflag] | ||
| + | |||
| + | Bit 2 appears to be intended for write errors. However, a write seems always to finish without setting it, and the error may instead appear in the FLAG of the next command. Some third-party cards also set bit 5.[^spxflag] | ||
| + | |||
| + | ## Timing | ||
| + | |||
| + | psx-spx reports that the card raises interrupt 7 about 1500 cycles after the first bit of each byte except the last. After the 7th byte of the read command a Sony card waits an extra 31000 cycles or so before the interrupt; cards from other makers do not.[^spxtime] The write command shows no extra delay.[^spxtime] | ||
| + | |||
| + | ## References | ||
| + | |||
| + | [^hw15]: Sony Computer Entertainment Inc. PlayStation Hardware. August 1998. Page 1-5. | ||
| + | [^ovr53]: Sony Computer Entertainment Inc. Run-Time Library Overview. Run-Time Library 4.4. January 1999. Page 5-3, Table 5-1, Table 5-2. | ||
| + | [^ovr54]: Sony Computer Entertainment Inc. Run-Time Library Overview. Run-Time Library 4.4. January 1999. Page 5-4, Table 5-3. | ||
| + | [^ovr55]: Sony Computer Entertainment Inc. Run-Time Library Overview. Run-Time Library 4.4. January 1999. Page 5-5. | ||
| + | [^ovr56]: Sony Computer Entertainment Inc. Run-Time Library Overview. Run-Time Library 4.4. January 1999. Page 5-6, Table 5-4. | ||
| + | [^ovr57]: Sony Computer Entertainment Inc. Run-Time Library Overview. Run-Time Library 4.4. January 1999. Page 5-7. | ||
| + | [^ovr58]: Sony Computer Entertainment Inc. Run-Time Library Overview. Run-Time Library 4.4. January 1999. Page 5-8, Table 5-5. | ||
| + | [^ovr1315]: Sony Computer Entertainment Inc. Run-Time Library Overview. Run-Time Library 4.4. January 1999. Page 13-15, Table 13-15. | ||
| + | [^spxaddr]: psx-spx. Controllers and Memory Cards, Device addressing. https://psx-spx.consoledev.net/controllersandmemorycards/ | ||
| + | [^spxtap]: psx-spx. Controllers and Memory Cards, Multitap Memory Card Access. https://psx-spx.consoledev.net/controllersandmemorycards/ | ||
| + | [^spxread]: psx-spx. Controllers and Memory Cards, Reading Data from Memory Card. https://psx-spx.consoledev.net/controllersandmemorycards/ | ||
| + | [^spxwrite]: psx-spx. Controllers and Memory Cards, Writing Data to Memory Card. https://psx-spx.consoledev.net/controllersandmemorycards/ | ||
| + | [^spxid]: psx-spx. Controllers and Memory Cards, Get Memory Card ID Command. https://psx-spx.consoledev.net/controllersandmemorycards/ | ||
| + | [^spxinvalid]: psx-spx. Controllers and Memory Cards, Invalid Commands. https://psx-spx.consoledev.net/controllersandmemorycards/ | ||
| + | [^spxflag]: psx-spx. Controllers and Memory Cards, FLAG Byte. https://psx-spx.consoledev.net/controllersandmemorycards/ | ||
| + | [^spxtime]: psx-spx. Controllers and Memory Cards, Timings. https://psx-spx.consoledev.net/controllersandmemorycards/ | ||
| + | [^spxnote]: psx-spx. Controllers and Memory Cards, Memory Card Read/Write Commands, Notes. https://psx-spx.consoledev.net/controllersandmemorycards/ | ||
| + | [^spxsize]: psx-spx. Controllers and Memory Cards, Memory Card Data Format, Data Size. https://psx-spx.consoledev.net/controllersandmemorycards/ | ||
| + | [^spxnotes]: psx-spx. Controllers and Memory Cards, Sony PSX Memory Cards. https://psx-spx.consoledev.net/controllersandmemorycards/ | ||