TASVideos

Tool-assisted game movies
When human skills are just not enough

Submission #6905: CasualPokePlayer's GBC Pokémon: Silver Version "save glitch" in 03:31.22

Console: Game Boy Color
Game name: Pokémon: Silver Version
Game version: USA/Europe
ROM filename: pokesilver.gbc
Branch: save glitch
Emulator: Bizhawk 2.5.1
Movie length: 03:31.22
FrameCount: 12618
Re-record count: 7933
Author's real name: Wesley B.
Author's nickname: CasualPokePlayer
Submitter: CasualPokePlayer
Submitted at: 2020-10-09 13:18:00
Text last edited at: 2020-10-14 20:05:52
Text last edited by: CasualPokePlayer
Download: Download (4473 bytes)
Status: judging underway
Submission instructions
Discuss this submission (also rating / voting)
List all submissions by this submitter
List pages on this site that refer to this submission
View submission text history
Back to the submission list
Author's comments and explanations:

(Link to video)

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.


Similar submissions (by title and categories where applicable):