The ordinary way to save on NES homebrew is to write to 8 KiB of battery-backed SRAM mapped at $6000-$7FFF. But since the NES days, the price of flash appears to have fallen below the price of nonvolatile RAM. So it appears the target hardware for any new low-volume commercial NES game that can save is something similar to SUROM (MMC1 + CHR RAM + PRG RAM) without battery. So the machine has 10 KiB of RAM, but the 29F040 storage medium has eight 64 KiB sectors: four for the game and four for the save. Some flash has smaller sectors, such as the SST39SF series with 4 KiB sectors.
Erasing a sector erases the whole thing to $FF, but any byte that is still $FF can apparently be written to a byte at a time. This allows appending to a sector, which suggests treating several sectors as a circular buffer containing a log-structured file system. A file is considered superseded when a file with the same name follows it in the circular buffer. When all but one of the sectors fill up, all not-superseded files in the tail sector get copied to the head and then erased. To make sure we don't erase all the time and wear out the flash, we only let the user save enough files to fill half the sectors. Then when the user saves enough files to fill those, the user has to delete some files first.
Implementing such a file system becomes an engineering exercise.
An 8-character password saves up to 32 bits of game state, as seen in this demo. A fairly railroaded action RPG might split it up as follows:[1]
Categories: NES