Memory card alternate sectors?

BIOS, Controllers, Memory Cards, Serial I/O, Parallel I/O, etc.
Post Reply
ohverywell
What is PSXDEV?
What is PSXDEV?
Posts: 4
Joined: Mar 27, 2019

Memory card alternate sectors?

Post by ohverywell » March 27th, 2019, 5:22 pm

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!

danhans42
BANNED
BANNED
Posts: 329
Joined: Nov 28, 2012

Post by danhans42 » March 27th, 2019, 9:43 pm

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.

ohverywell
What is PSXDEV?
What is PSXDEV?
Posts: 4
Joined: Mar 27, 2019

Post by ohverywell » March 28th, 2019, 4:29 am

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).

ohverywell
What is PSXDEV?
What is PSXDEV?
Posts: 4
Joined: Mar 27, 2019

Post by ohverywell » March 28th, 2019, 7:56 am

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:

Code: Select all

# Write to sector 0xc0 (data block 0x03 @ offset 0x0000)
[MCR] Command received: W
[MCR] Write command: 0x00c0
[MCR] Command W at 0xc0, forcing response 0x04

# Write to sector 0xc1 (data block 0x03 @ offset 0x0080)
[MCR] Command received: W
[MCR] Write command: 0x00c1

# Write to sector 0x2a (FAT block 0x00 @ offset 0x1500 -- alt-sector data)
[MCR] Command received: W
[MCR] Write command: 0x002a

# Write to sector 0x16 (FAT block 0x00 @ offset 0x0b00 -- alt-sector info)
[MCR] Command received: W
[MCR] Write command: 0x0016

# Write to sector 0xc2 (data block 0x03 @ offset 0x0100)
[MCR] Command received: W
[MCR] Write command: 0x00c2

# Write to sector 0xc3 (data block 0x03 @ offset 0x0180)
[MCR] Command received: W
[MCR] Write command: 0x00c3

# Write to remaining sectors in data block 0x03
...
(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.

User avatar
Shadow
Admin / PSXDEV
Admin / PSXDEV
Posts: 2670
Joined: Dec 31, 2012
PlayStation Model: H2000/5502
Discord: Shadow^PSXDEV

Post by Shadow » April 1st, 2019, 1:49 pm

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.
Development Console: SCPH-5502 with 8MB RAM, MM3 Modchip, PAL 60 Colour Modification (for NTSC), PSIO Switch Board, DB-9 breakout headers for both RGB and Serial output and an Xplorer with CAETLA 0.34.

PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.

ohverywell
What is PSXDEV?
What is PSXDEV?
Posts: 4
Joined: Mar 27, 2019

Post by ohverywell » April 1st, 2019, 6:07 pm

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.

Post Reply

Who is online

Users browsing this forum: No registered users and 4 guests