byuu wrote:I wonder if the PCB IDs correlate, or if they tend to swap out SRAM chips on them. That would be pretty tacky to have two identical PCBs, where one game expects 0x00 SRAM and another 0xFF SRAM.
The SRAM doesn't do anything but store data. If you're saying that game 1 might expect a location to be FFh and game 2 expects it to be 00h, this is entirely possible.
1) system powers up
2) game code diddles the save-ram looking for whatever.
3) sees something it doesn't like.
4) re-initialize the battery RAM by writing default pattern to it.
5) halts.
6) confused person power cycles and starts up game again.
7) game code diddles the save-ram looking for whatever.
8) if it sees something it doesn't like: go to step 4
9) title screen appears.
if the game is missing the code for step 4, to re-initialize the SRAM, however, there's nothing an emulator author can do, except write a hack or distribute the initialized .SRM with the game like those in this thread are saying.
This is strictly a game-code issue. The only hardware issue is mapping. If the code for step #4 writes to mirrored addresses that ultimately go to the same SRAM cells as step #2 or #7, and you're not correctly emulating that, then the game will exhibit the lock-up symptoms as well.
The tenuous point is, if step #4 is buggy, and doesn't even work on the real cartridge, would it be ethical to issue a patch and bump up the revision number?