Introduction
So, there have been two Pokemon Crystal save glitch movies so far. Both of which abuse the laughable checksum system and use checksum collision to corrupt the main save data. It was thought that this technique would ultimately be just slower in Gold/Silver due to the classic save glitch ACE exploit, type 0xD0, required a third Pokemon in the party. However, I've recently discovered that this requirement is really only needed for Gold. Silver happens to have some slight differences with type 0xD0 ACE, that being a usable pointer was in the middle of box names! This eliminated the need for a third Pokemon, making save glitch far better in Silver than Crystal. Now Silver is the fastest gen 2 game!
Emulator used: Bizhawk 2.5.1
- SubGBHawk was again used due to the need of a precise subframe reset.
Categories
- Aims for fastest completion of the game
- Minor luck manipulation
- Heavy glitch abuse
- Corrupts save data
- Corrupts memory
Objectives
Save corruption
Read the previous 2 save glitch submissions for the details, but essentially we want to corrupt Cyndaquil so it has no moves, while also making sure the checksum passes.
Type 0xD0
Type 0xD0 is the type move 0x00 has on the move summary screen. This type sources itself from VRAM, which is subject to locking, so the corruption done is variable and dependent on timing. This timing can be manipulated slightly using PrintLetterDelay, just like RNG. Anyways, this corruption can overflow the tile map, and the corruption happens to reach some data regarding animations. Particularly, the animation ID can be corrupted, and this animation ID happens to use a jump table that has some interesting values past its valid entries. For 0x91, the pointer is 0xD8CD, which is in the middle of box 2. 0x91 can be corrupted in using the player's name (R is character 0x91).
Arbitrary Code Execution
This uses yet again MrWint's box code for input to opcode. There were some minor modifications done to work around character limitations.
| Bytes | Instruction | Comment |
|---|---|---|
| Box 4 | ||
| aa | xor d | d stores last joypad input: find out differences to current input |
| ea e2 f8 | ld (f8e2),a | Write difference; will be executed as opcode later in the next cycle |
| aa | xor d | Restore current joypad input value |
| f5 | push af | Copy current joypad input from a... |
| d1 | pop de | ... to d (store it as last joypad input) |
| f1 | pop af | Restore a and f from the previous cycle |
| (f8e2) | (any) | Execute opcode written earlier this cycle |
| Box 5 | ||
| f5 | push af | Save a and f for next cycle |
| b6 | or (hl) | Clears carry flag, needed for the jump |
| fa a6 ff | ld a,(ffa6) | Reads current joypad inputs into a |
| d2 d6 f8 | jp nc, f8d6 | Loop back to right before Box 4; carry will never be set |
Here is a paste of the tracelog and the values set from the input to opcode payload: https://pastebin.com/raw/B7R0Cmf1
To note, movie does something a bit differently to get to Mt. Silver. Instead of creating a warp, I just change the map connection so it goes to Mt. Silver (and in front of Red) and I move myself next to the map connection, so taking 1 step down triggers it. This also happens to make autoinput taken from 00:0000 to work, so all I need to do is enable autoinput and it'll just work.
Route
Intro
- Save data is cleared for morality reasons.
- Options are not set as text can print at the fast speed when A or B is held anyway.
- The trainer ID is not manipulated, as it's not relevant for ACE nor collision.
- The player is named "R". This is needed for type 0xD0 ACE to work.
New Bark Town
- The game is saved before obtaining Cyndaquil to setup later collision.
- Save corruption happens right before entering Route 29. Upon reloading the game, Cyndaquil now has no moves.
Route 29
- No encounters are manipulated. This is the only luck manipulation within the run.
Cherrygrove City
- Boxes 4 and 5 are named for the initial ACE payload.
- Type 0xD0 is viewed and manipulated to place the player's name at the right spot for ACE to happen.
- Auto input takes over after ACE, going down and pressing A through Red's textboxes.
ThunderAxe31: Judging.
ThunderAxe31: All right, the movie looks optimized and it correctly beats the game.
There is just one special note I need to make. After some discussion with the other judges, as well as the precedent set with this submission, we decided that using glitches that are affected by uninitialized SRAM bytes is considered fair. For this reason, it shouldn't be considered as a requirement to wipe the save data by using in-game functionalities, like this movie does. Additionally, this movie does also write a proper save file once, before performing the save glitch, so there wouldn't be much of controversial even if we wanted to see it that way. However, the time lost is not considered as suboptimal play, but rather as a personal choice from the author. Additionally, the previous publications are also making use of this in-game feature, so it's understandable that the author decided to follow the trend set by movies that have been accepted in the past, in order to make sure that the new submission would comply with the rules. Though, this isn't always the case, as rules may change and judgement precedents may not always reflect them; when in doubt, always ask directly to the judges. Anyway, please remember to avoid wiping the save data for future submissions, unless that is required for performing a faster glitch.
Since the movie contents are very similar to the published Pokémon Crystal movie, this movie is going to obsolete it. It does also pretty much reflect the same audience reaction, so it's also going to inherit the Moons tier. Accepting over [4285] GBC Pokémon: Crystal Version "save glitch" by CasualPokePlayer in 03:55.59.
Spikestuff: Publishing.