Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alternate sector information is not processed, resulting in corruption upon save #17

Open
DeadlySystem opened this issue May 16, 2021 · 2 comments

Comments

@DeadlySystem
Copy link

Memory cards contain 20 reserved sectors ("Alternate Sectors") in the FAT block that can be used to replace broken sectors. The respective documentation can be found here under "Broken Sector List".

It seems MemcardRex does not process this information and instead assumes that all sectors are sane. This can lead to severe problems when working with corrupted cards. An example flow I've been able to verify is exporting a single save containing a corrupted sector. MemcardRex in this case exports the save with the corrupted sector, the alternate sector is ignored. When this save is later re-imported, it remains corrupt - even though the original memory card image works fine (because it contains the alternate sector). Also, when simply saving the full image again, alternate sectors seem to be cleared - resulting in MemcardRex corrupting the original save.

My suggested treatment would be to replace the broken sectors with their alternate sectors when a memory card is loaded, and clear the alternate sectors at this point. This would effectively fix the card image and prevent inconsistencies from occurring when the card is edited. However, this solution also has a few drawbacks that I can think of:

  • If the card image is written back to the physical memory card from which it was taken, the previously-broken sectors of this card are likely still broken, and therefore the saves will break unless MemcardRex detects write errors and creates new alternate sectors. It might be that the memory card adapter or the memory card itself perform these checks though - I'm not familiar with the involved protocols.
  • It is not clear from the specs if alternate sectors can also replace sectors within the FAT block - possibly even other alternate sectors, or possibly even themselves. From a pure format definition perspective, this is possible. In an extreme case, MemcardRex would need to read sectors in some to-be-determined order to ensure that data is read consistently, handle recursive replacements, and avoid loops. I personally don't believe that the PlayStation BIOS (or the memory card controller?) is smart enough to handle this - it might ignore such alternate sectors, or just crash. I suppose the easiest option here would be to prevent loading of images whose alternate sectors reference the FAT block.
  • Compatibility with FreePSXBoot might be affected. Suggested treatment would be to disable automatic substitution with the option introduced in 0952399 (Note that this specific change is unrelated to alternate sectors, it only seems to fix checksums, which is a different concern) and show a warning to users when attempting to load such an image, possibly disabling editing.
@ShendoXT
Copy link
Owner

ShendoXT commented May 19, 2021

Note that this specific change is unrelated to alternate sectors...

It's related but that can't be seen looking at the diffs, the affected code that fixes it is skipped by a return statement.

Before when MemcardRex couldn't talk to real cards I did not bother with alternate sectors because only emulators produced mc images and those were always good.

I think your first suggestion sounds reasonable.
Regarding the issue when writing to card with broken sectors, yes saves would end up corrupted but maybe I could inform the user upon reading the card that some sectors were found to be corrupted and that that card is not reliable and should be replaced...

Did you encounter the issue yourself? I personally haven't. All the cards that died on me would do so suddenly without any relocated sectors. Mind you those were all 3rd party ones, first party ones haven't yet died.

@DeadlySystem
Copy link
Author

Hi @ShendoXT thanks for your answer :) Yes, informing the user about failed writes would definitely be appropriate - assuming the hardware provides this information. You could also perform a check by reading what was written again to confirm it matches the original data you've tried to write.

I haven't encountered this problem in practice myself. I have three original Sony memory cards and they are all in healthy condition, not using any alternate sectors. My experience comes from introducing alternate sectors into a clean image manually, in order to test behavior of games in emulators and to refine my personal Java-based memory card parsing library. I have no idea how often this "feature" needs to be used in practice with real hardware.

What I did read though is that someone injected write errors into the Mednafen emulator to test how the system behaves, and their findings were that alternate sectors are then indeed being used. I don't have the original source at hand, but I came across it pretty quickly when researching alternate sectors on Google. Now of course this is not really a desired behavior, but it does exist.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants