PlayStation Development Network

Hello,

I'm not a regular here, so sorry if i've missed it, but i couldn't find anything in my searches:

Does anyone have any information about the alternate-sector area in the FAT block on the memory-card file system?

Sony's documentation (File Format 47.pdf) suggests to me that this must be some kind of spare area used to route around sectors that are no longer writeable. (Presumably it was implemented in the file system rather than in hardware like on modern flash devices for cost reasons?) But i've dumped several well-used cards of various sorts and i've yet to find any that touched this area. Furthermore, none of the third-party software i can find on the Internet (like MemcardRex) seems to account for it.

Some specific questions i have:

1. Is my understanding of this feature's basic purpose correct?

2. Is this something that ultimately went unused? Or is it just rare to encounter it in the wild?

3. If it *did* get used, how was it implemented? Did Sony's library functions handle all of it transparently, or did developers have to write their own code for it?

4. Are there any known limitations or edge cases surrounding this feature? For example: Could you map other sectors in the FAT block to the alternate-sector area, or just data blocks? Could you even map *other alternate sectors* to it? What happens when all of the alternate sectors are spoken for?

Eventually i think i might try to manually write some alternate-sector data to a card, read and write to it on the console, and then dump its contents again to see what it did. But i wanted to ask about it here in the mean time. Thanks!

Could it be part of the flash interface of the memory card? That would explain why you would never see it as the interface MCU on the memory card handles it so the console doesnt need to worry about it.

Maybe. The documentation seems to suggest that it's handled at the file-system level, but there's room for interpretation i'm sure.

If it *were* a hardware function, emulators would have to implement it, and none of the ones i've looked at do AFAICT.

So i think i should be able to test the theory by constructing a memory-card image with alternate-sector data and seeing if an emulated BIOS/game respects it when reading from and writing to the card. If it does, that would at least prove that it's not *purely* a hardware function (though it doesn't confirm that there's *no* hardware co-operation involved).

Testing in an emulator with hand-edited memory-card images, i was able to answer a few questions:

1. The alternate-sector feature *is* used, or at least it can be.

2. It *does* work essentially as the documentation describes (put a sector number in the first field of 'alternate information sector 1', and the game will read/write the corresponding 'alternate sector 1' instead of the original sector).

3. It's *not* (purely) a hardware function, unless Mednafen has some special code for it that i couldn't find.

4. It does *not* seem possible to remap other sectors in the FAT block -- at least, when i tried to remap a 'block information' (directory) sector, it didn't respect it.

The last one is kind of interesting. It seems like a significant limitation. On the other hand, once a save file is created, the FAT entry for it is probably never written to again until you delete it (whereas the data-block sectors are touched every time you save the game). So it sees less wear, i suppose.

Edit:

Just wanted to add that i was able to see this in action. I recompiled Mednafen to enable debug logging and to introduce an error in response to a write command at a particular sector on the memory card. The debug log confirms that the game (or probably Sony's library, rather) detects the error and routes around the sector -- it happens across normal channels, *not* in the card hardware:
(0xc0 is the sector beginning block 3. 0x2a is 'alternate sector 6' in the Sony documentation. 0x16 is 'alternate information sector 6' in the Sony documentation. 0x04 is what the Nocash documentation calls the 'FLAG byte' with bit 2 set to 1.)

I think with this i've answered most of my own questions, and i can experiment further to see exactly what happens in certain edge cases.

If anyone else stumbles across this and wants to play with it themselves: You will want to introduce the error at the next card access *after* the 'erroneous' write command has occurred. In other words, after a write attempt, on the next 0x81 byte, respond with 0x04. In my Mednafen source this is in memcard.cpp around line 275.

Didn't they use this sector for the 'un-delete' function? If not, you're right and they used it for flagging bad sectors and using the spares as fail-safes.

AFAIK, deleting a save involves simply flipping the 'block list information' (allocation state) value on the save's directory entry/ies, and undeletion can be achieved by reversing that, assuming nothing else has written over any of the deleted blocks in the mean time. There is no-where near enough alternate-sector space available to store a full block, so it couldn't practically be used as a back-up area for that purpose, either.