/vr/ - Retro Games

>>9965074
>Sure you do, Dunning Kruger.
The game at boot has a SegaXtreme splash screen that gets displayed. A checksum was implemented to make sure the screen's tile data wasn't altered. On the first boot it would save this to what was thought to be an unused part of SRAM, this way it could then verify in future boots if the checksum itself had been altered. If the checksum check failed, the game would reset to the CD Player, otherwise it would boot normally.

So if that process was the issue happening in that bug report, the game wouldn't get past the "Licensed by Sega" screen and would be resetting to the CD player, not crashing the system. But it was getting past that and all the way to the title screen and then crashing.

Now, the issue addressed in the later patch is related to saving the checksum in SRAM. The area that was thought to be unused was actually discovered to be used to identify bad sectors in SRAM. This was discovered by people currently decompiling the BIOS. So what writing the checksum there did was make the Saturn think certain sectors were bad, and would result in having less blocks available to save to in your total SRAM space. It wouldn't cause the game to crash, it just made the Saturn think it had less SRAM blocks than it actually had. The fix made it so that checksum no longer got written to SRAM.

If the user was having that issue, they either wouldn't have noticed unless they added up all the blocks used vs available in the Memory Manager. If it caused them to not have enough space available to save, they would have seen the screen in pic related when selecting a new game. If the issue resulted in an existing save file being marked as a bad sector, it would show up as "Save file is corrupt" in the load game screen. It would NOT have resulted in the game crashing at the title screen.

So no, it wasn't the same issue.

>That doesn't make them any more reliable.
But it also proves the cart is not the problem.