Re: Differences between English Ruby/Sapphire v1.0 and v1.1
Posted by: SatoMew
Date: 2015-10-05 17:42:20
Glitch City Laboratories closed on 1 September 2020 (announcement). This is an archived copy of a thread from Glitch City Laboratories Forums.
You can join Glitch City Research Institute to ask questions or discuss current developments.
You may also download the archive of this forum in .tar.gz, .sql.gz, or .sqlite.gz formats.
So a single line of text mentions "RECORD CENTER" while the others consistently use "RECORD CORNER"?
Not quite what I was expecting to see, but here it is:
[img]http://imgur.com/V63NQoy.png[/img][img]http://imgur.com/cxq1lHZ.png[/img]
[img]http://imgur.com/QfLUQmz.png[/img][img]http://imgur.com/yLmZeWT.png[/img]
The glitchy text box in 1.0 is caused by the text running off the edge of the screen and overwriting the text box graphics.
As for what this thing is doing: First, the internal battery text is a red herring; this is all to do with the cartridges flash memory. The original Japanese message is きののまはみきまとはできまのままそぶとはできま, which seems to say roughly that the backup function has failed or reached its end-of-life. Chalk it up as yet another localization error.
The code that writes to the flash memory verifies each byte as its written, and retries if its not. After a few tries, if the data is still not written correctly, it gives up and flags the sector as bad. This triggers the Save failed screen.
Checking the backup memory appears to mean trying to zero out any bad sectors. If this succeeds, then it will attempt to save again. If the zeroing fails, or if the save fails three more times, then The backup memory is damaged and Gameplay cannot be continued. Returning to the title screen If the save succeeds, then it shows one of the two Save completed messages, but I dont know how its determined whether gameplay can be continued.
The bitfield of bad sectors is at $3005EA8; you can write a non-zero value to this address during a save to force the Save failed screen to appear.
It seems that no$gba isnt able to emulate the zeroing process correctly; it gets stuck on Checking the backup memory, or at least the Time required is a lot more than 1 minute. VBA-M, on the other hand, finishes in just a few seconds even if all 32 sectors are flagged.
Yes, The save file has been deleted is shown when both save files or corrupt, or one is corrupt and the other doesnt exist. (A save file exists if the value $08012025 has been written at offset $FF8 of at least one block; this prevents the error from being shown on a brand new cartridge, or one thats been erased using Up + Select + B.)
Nothing is actually deleted from the flash memory when this happens; it just removes the Continue option from the main menu. If you still have the file, it could potentially be recovered by using a tool like PSavFix to fix the checksums.
PSavFix -fix -RS "ind-pref-bak.sav"
Running in RS Mode
Loading: ind-pref-bak.sav...
Autofix: ON
Size: 890 Segment: 00 Calc: 0000 Found: 0000 Sig: 00000000 - OK
Size: 890 Segment: 00 Calc: 0000 Found: 0000 Sig: 00000000 - OK
Size: 890 Segment: 00 Calc: 0000 Found: 0000 Sig: 00000000 - OK
Size: 890 Segment: 00 Calc: 0000 Found: 0000 Sig: 00000000 - OK
Size: 890 Segment: 00 Calc: 0000 Found: 0000 Sig: 00000000 - OK
Size: 890 Segment: 00 Calc: 0000 Found: 0000 Sig: 00000000 - OK
Size: 890 Segment: 00 Calc: 0000 Found: 0000 Sig: 00000000 - OK
Size: 890 Segment: 00 Calc: 0000 Found: 0000 Sig: 00000000 - OK
Size: C40 Segment: 04 Calc: 78A7 Found: 78A7 Sig: 08012025 - OK
Size: F80 Segment: 05 Calc: 0000 Found: 0000 Sig: 08012025 - OK
Size: F80 Segment: 06 Calc: 0000 Found: 0000 Sig: 08012025 - OK
Size: F80 Segment: 07 Calc: 0000 Found: 0000 Sig: 08012025 - OK
Size: F80 Segment: 08 Calc: 0000 Found: 0000 Sig: 08012025 - OK
Size: F80 Segment: 09 Calc: 0000 Found: 0000 Sig: 08012025 - OK
Size: F80 Segment: 09 Calc: 0000 Found: 0000 Sig: 08012025 - OK
Size: F80 Segment: 0A Calc: 0000 Found: 0000 Sig: 08012025 - OK
Size: F80 Segment: 0B Calc: 0000 Found: 0000 Sig: 08012025 - OK
Size: F80 Segment: 0C Calc: 0000 Found: 0000 Sig: 08012025 - OK
Size: 7D0 Segment: 0D Calc: F131 Found: F131 Sig: 08012025 - OK
Size: 890 Segment: 00 Calc: 1639 Found: 1639 Sig: 08012025 - OK
Size: F80 Segment: 01 Calc: 1A0E Found: 1A0E Sig: 08012025 - OK
Size: F80 Segment: 02 Calc: B831 Found: B831 Sig: 08012025 - OK
Size: F80 Segment: 03 Calc: 9386 Found: 9386 Sig: 08012025 - OK
Size: C40 Segment: 04 Calc: 78A7 Found: 78A7 Sig: 08012025 - OK
Size: F80 Segment: 05 Calc: 0000 Found: 0000 Sig: 08012025 - OK
Size: F80 Segment: 06 Calc: 0000 Found: 0000 Sig: 08012025 - OK
Size: F80 Segment: 07 Calc: 0000 Found: 0000 Sig: 08012025 - OK
Size: 890 Segment: 00 Calc: 0000 Found: 0000 Sig: 00000000 - OK
Size: 890 Segment: 00 Calc: 0000 Found: 0000 Sig: 00000000 - OK
Size: 890 Segment: 00 Calc: 0000 Found: 0000 Sig: 00000000 - OK
Size: 890 Segment: 00 Calc: 0000 Found: 0000 Sig: 00000000 - OK
Size: 890 Segment: 00 Calc: 0000 Found: 0000 Sig: 00000000 - OK
No Problems found :)
I dont know how you would have done that, but it seems the first eight blocks of the first save file and the last block of the second save file (plus the Hall of Fame data, if there was any) are deleted. The missing block from the second save file is block 8, which is part of the PC box data and was probably empty anyway, so youd be able to fix that in a hex editor by writing 08 at offset $1BFF4, and copying $1AFF8$1AFFF to $1BFF8$1BFFF.