Renesas now (still?) sells a 5V 128kB SRAM at $942/1000.tepples wrote:
One might solve [the possibility of save corruption] by ... switching to the bank with the saves only when loading or saving3gengames wrote:
if you're that terrible of a programmer you shouldn't be programming anything.
Only terrible programmers recognize that despite testing, the occasional undiscovered program defect may slip into the shipping version. So only terrible programmers use the extra banks in the chips they already have to build in extra memory protection mechanisms as a layered defense. 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, only terrible programmers store the saves in a bank that nothing else uses.
tokumaru wrote:If there's a bug with your VRAM routines, fix them.
I agree, but one 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 it. 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 what makes me a terrible programmer is how long it took me 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. If I were to use 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. And unlike on the PC, the HD consoles, and smartphones, you can't patch an NES game without a CopyNES.
Besides, how would one test? The only mapper I know of that supports battery-backed CHR RAM (without NES 2.0 hackery that nothing 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, because its programmers were terrible. Or am I also a terrible electrical engineer because I don't feel inclined to put together my own cartridge board and hack my NES apart to accept an EPROM emulator, and a doubly terrible programmer because I don't feel inclined to learn emulator development and add support for battery-backed CHR RAM to Nintendulator or FCEUX for Windows?