So after making my Silver collision movie, I ended up thinking of an idea I had some time ago: can the Red Any% TAS be improved with checksum collision?
Turns out, yes it can. By 4 frames.
There are some technical points I need to clarify with this though. For one, there's quite a bit of data I need to save so the game doesn't end up softlocking when the the save file is loaded. And past that, there's other data I would want to save, like the Pokedex flag (so 4 frames isn't lost due to having the Pokedex), and surprisingly, sprite data. It so happens the game will save sprite data around the end of the save routine, and one of the IDs for the sprites happens to cause around 7 frames of lag (when all are FF anyways). Once all that is accounted for, I then have to figure out how to collide the checksums. Turns out Gen 1's checksum system is even worse than Gen 2's. While Gen 2 was just the sum of all the bytes stored in 2 bytes, Gen 1 instead just uses the complement of the sum of all the bytes... stored in 1 byte. And since all of SRAM is filled with FFs and most of the data being written in there is 00s, it really just becomes a simple game of math to figure out which byte you want to reset in.
Also, I ended up using 0x64C2 instead of 0x64C1 for the TID in this TAS, as the higher byte lets me reset 1 byte/52 cycles earlier. To note, manipulating for 0x64C6 takes 740 more cycles, and it would only save on 4 bytes being written/208 cycles, so it isn't worth it to manipulate that TID.
Unrelated to collision, another minor improvement I found was that taking the 1 step down before the save/quit happens to be 55 cycles faster. Who knew?
EDIT: Ok the 1 step down was actually somewhat relevant to collision, although it happens that collision with the old 1 step down after s/q would lose an additional 64906 cycles, past the inherit cycle loss anyways.

ThunderAxe31: Judging.
ThunderAxe31: Accepting as improvement over the current publication.
Spikestuff: 🎃 Publishing.


TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 15628
Location: 127.0.0.1
Banned User
Joined: 4/1/2016
Posts: 295
Location: Cornelia Castle
A nice improvement! Yes vote. Now, just one more to go!
DJ Incendration Believe in Michael Girard and every speedrunner and TASer!
Editor, Expert player (2080)
Joined: 6/15/2005
Posts: 3284
I haven't been following Pokemon save corruption recently (totally glitched runs just aren't my thing anymore), but I have a question. Did using glitch items (at least one which I believe allows you to execute RAM) ever factor into your TAS? I managed to find one on the JP version, but I can't remember if it was the same for the US version.
Emulator Coder, Judge, Experienced player (732)
Joined: 2/26/2020
Posts: 790
Location: California
FractalFusion wrote:
I haven't been following Pokemon save corruption recently (totally glitched runs just aren't my thing anymore), but I have a question. Did using glitch items (at least one which I believe allows you to execute RAM) ever factor into your TAS? I managed to find one on the JP version, but I can't remember if it was the same for the US version.
To be clear, 99% of the TAS is still MrWint's, this submission is just adding in checksum collision into the equation so the reset can happen a few frames earlier. That aside, glitch items for the US version are heavily documented, and wouldn't be that hard to yoink the pointers out of the JPN version either (or any version for that matter). The bigger issue is just making a payload. The furthest we can go to (properly) complete the game would be in HallofFameRoomScript2. That's in bank 0x16. You won't be in that bank when you use an item, you'll be at bank 0x03. So the code would need to bankswitch, then actually jump the HoF code. There isn't some place where such a payload could be stored. And it really isn't better than what's used now: the map script pointer is changed so it points to HallofFameRoomScript2 (and the map number is changed so it'll go to bank 0x16).
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3828)
Joined: 11/30/2014
Posts: 2834
Location: US
Nice work, I'm really surprised how often checksum collision leads to a useful result. I guess it's only because the checksum value is so small, but it's still cool to see.
Active player (316)
Joined: 3/15/2018
Posts: 235
Location: United States
A 1-byte checksum? It's free real estate! I'm not sure I fully understand this, though. Was a checksum collision not necessary before to get the game to load a corrupted file?
Emulator Coder, Judge, Experienced player (732)
Joined: 2/26/2020
Posts: 790
Location: California
warmCabin wrote:
A 1-byte checksum? It's free real estate! I'm not sure I fully understand this, though. Was a checksum collision not necessary before to get the game to load a corrupted file?
It was not, due to the way the game decided to save. The game saves different chunks of data, and notably separates party data from the main data. And after saving every chunk of data, it proceeds to calculate the full checksum and write it every time... which already appears to really bad. Then it gets worse when you realize that after the main data is saved, the game proceeds to save box data (which is not checksummed) before saving party data... which leads to haha nice 4 frame window for corruption humans can trivally hit.
Player (27)
Joined: 3/2/2014
Posts: 34
Location: Canada
CasualPokePlayer wrote:
warmCabin wrote:
A 1-byte checksum? It's free real estate! I'm not sure I fully understand this, though. Was a checksum collision not necessary before to get the game to load a corrupted file?
It was not, due to the way the game decided to save. The game saves different chunks of data, and notably separates party data from the main data. And after saving every chunk of data, it proceeds to calculate the full checksum and write it every time... which already appears to really bad. Then it gets worse when you realize that after the main data is saved, the game proceeds to save box data (which is not checksummed) before saving party data... which leads to haha nice 4 frame window for corruption humans can trivally hit.
CasualPokePlayer's explanation is slightly incorrect (and only explains the general idea). The game does checksum current box data, however the issue is that current box data is copied twice during the save process. First, the game copies current box data (as well as other data, but not party data), then checksums the entire save. Then, the game copies current box data AGAIN (and checksums the entire save as well, but that part is irrelevant). Since the current box data is already in the save, the save's checksum will never change since it's copying the exact same data, which gives a reasonable window to reset during saving. A more detailed explanation can be found here.
Meerkov wrote:
The human element of the run is far more entertaining than the game itself. If it wasn't for someone lying about their record 40 years ago, I don't think we'd take a second look at this run/game. Meh vote.
Banned User
Joined: 4/1/2016
Posts: 295
Location: Cornelia Castle
That makes sense. So excited for when this (and other Pokémon TASes) are published!
DJ Incendration Believe in Michael Girard and every speedrunner and TASer!
Post subject: Movie published
TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 15628
Location: 127.0.0.1
This movie has been published. The posts before this message apply to the submission, and posts after this message apply to the published movie. ---- [4329] GB Pokémon: Red Version "save glitch" by MrWint, Alyosha & CasualPokePlayer in 01:15.62