3gengames wrote:
tepples wrote:
One might solve [the possibility of save corruption] by ... switching to the bank with the saves only when loading or saving
if you're that terrible of a programmer you shouldn't be programming anything.
We're all terrible programmers. "All have sinned and fall short of the glory of God," as Paul wrote in Romans 3:23. You and I both know this: as you pointed out to me later, you too have released imperfect software. And it's a lot harder to patch a cartridge after release than to patch, say, a downloadable Android game. On some platforms, even a downloadable game can run into problems, as Microsoft charges tens of thousands of dollars for certification of a patch to an Xbox Live Arcade game. (See the
recent Slashdot story about Fez.)
So the right thing is to do one's best not to be terrible, but also to take reasonable steps to mitigate the effects of being unintentionally terrible. That's why I suggested using the extra banks in the RAM chip that one's already using to build in extra memory protection mechanisms as a layered defense. There are a lot of ways to do this, including some that involve no additional cost:
lidnariq wrote:
Renesas now (still?) sells a 5V 128kB SRAM at $942/1000.
If you have 16 banks available (128 KiB SRAM divided by 8 KiB visible to the PPU at once), and your game uses one or two, then why not store the saves in a bank that nothing else uses?
Another mitigation is to have both password and battery save within the same game. For example, after completing a chapter, a game could give the player a password to restart the game from that chapter in case a freak glitch wipes out the player's saves, although with a somewhat underpowered party. It wouldn't be much different from the "
bronze password" in Golden Sun for Game Boy Advance that summarizes the stats of a completed game at a reduced level of detail so that the character could be imported to the sequel.
tokumaru wrote:
If there's a bug with your VRAM routines, fix them.
I agree that one should learn from one's mistakes. Jonah at first shied away from preaching in Nineveh but ended up learning from his sins and delivering a very powerful prophecy. Likewise, after having denied three times in one morning that he knew Jesus, Simon Peter became a strong advocate for the faith.
But one still can't fix what's already shipped. Case in point: The original Super NES console, revision 1/1/1, has a defect that freezes the CPU if a DMA copy finishes too close to an HDMA. Nintendo fixed this for the more common 2/1/3, but games still had to work around the bug in 1/1/1 by not using DMA copy at the same time as HDMA. Likewise, after 3gengames reported Concentration Room's VRAM corruption bug to me, I isolated the problem and prepared a patch to fix the defect within the hour. But it still took years to discover this problem, as it had eluded me until long after I had already shipped Concentration Room 0.02 as part of the MGC 2011 multicart. Had I planned on battery-backed CHR RAM from the start of a project, I'd probably catch such an obviously reproducible bug quickly, but a similar bug that's
harder to trigger might slip past the testers and end up in the shipped product. Furthermore, defensive programming techniques that allow programs to run correctly even in unanticipated environments are especially helpful when developing for a PC or an Android device.
Besides, how would one test a game that uses this method? The only iNES mapper I know of that supports battery-backed CHR RAM (without NES 2.0 hackery that I don't believe anything really supports yet) is 168, used only for RacerMate Challenge, and that's marked "planned" on retrousb.com. That too uses two CHR RAM chips, only one of them battery-backed. Do any emulators support adding battery-backed CHR RAM to a more common board through the NES 2.0 header?
(You may have seen my avatar change a few times in the past couple weeks. If you want, I can post an explanation of my avatar images elsewhere.)
EDIT:
Explanation