Glitch City Laboratories Archives

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.

Pokémon Discussion

Differences between English Ruby/Sapphire v1.0 and v1.1 - Page 2

Re: Differences between English Ruby/Sapphire v1.0 and v1.1

Posted by: SatoMew
Date: 2015-10-05 17:42:20
So a single line of text mentions "RECORD CENTER" while the others consistently use "RECORD CORNER"?

Re: Differences between English Ruby/Sapphire v1.0 and v1.1

Posted by: Háčky
Date: 2015-10-07 12:30:08

So a single line of text mentions "RECORD CENTER" while the others consistently use "RECORD CORNER"?

Right.

Re: Differences between English Ruby/Sapphire v1.0 and v1.1

Posted by: SatoMew
Date: 2015-10-15 12:21:18

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.


While making the video to show this bug, I noticed that I already had an English Ruby v1.2 save file. When I loaded it in VBA-M, the game said the file had been deleted and then sent me to the main menu. Is this supposed to happen when there is no backup save file and the current data is invalid? I don't even remember having this file so it got me intrigued.

Re: Differences between English Ruby/Sapphire v1.0 and v1.1

Posted by: Háčky
Date: 2015-10-15 21:32:14
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.

Re: Differences between English Ruby/Sapphire v1.0 and v1.1

Posted by: SatoMew
Date: 2015-10-16 11:33:25

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.


Oh, neat. Is PSavFix available independently? A-Save includes it but I can't seem to find separate pre-compiled binaries available for download, except in one place that just provides a copy of A-Save anyway.

EDIT: I ran the bundled PSavFix.exe from A-Save 1.27 and it didn't detect any issues so the file was not modified. The game returns the deleted save error nonetheless.

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 :)

Re: Differences between English Ruby/Sapphire v1.0 and v1.1

Posted by: Háčky
Date: 2015-10-16 17:23:50
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.

Re: Differences between English Ruby/Sapphire v1.0 and v1.1

Posted by: SatoMew
Date: 2015-10-16 18:19:51

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.


Hmm, could it be that the save file was always blank but that random data got written somehow? Emulators do tend to create save files just from booting ROMs. This could be the case, especially when I might have unwittingly loaded the file between different builds of VBA-M.