The exact point when MissingNo. corrupts the save file
156More specifically, the exact point when MissingNo. corrupts the Hall of Fame data, and even more specifically, addresses from 0x498 to 0x857. It's very well known that MissingNo. (as well as many other Glitch Pokemon with corrupted sprites) causes the game to write to the save file and overwrite the area that corresponds to the Hall of Fame with garbage. I didn't know what triggered this effect so I decided to investigate a bit.
This is indeed caused during the decompression of MissingNo.'s (front)sprite. It seems that the decompression routines can't handle it, and keep writing data when and where it shouldn't. During the decompression of a sprite, data is written into the addresses pointed to by D0AD-D0AE (called SpriteOutputPtr by the dissasembly of Pokemon Red) every time. This pointer should normally point to addresses that are around ~0xA200 (SRAM), but during the decompression of MissingNo.'s sprite, there's a point when it starts taking values ranging from 0xA498 to 0xA857 deliberately, causing save file corruption between addresses 0x498 and 0x857 (Hall of Fame data starts at 0x598).
Unfortunately, this is as detailed as I can get about this. As much as the decompression routines can't handle the complexity of MissingNo.'s sprite, I can't myself handle the complexity of those routines.
I didn't go step for step since it would take forever. In the end I just kept track of when the address 0xA498 to 0xA49F -which translate to 0x498 to 0x49F in the save file- were being written (that's why you can see lots of bytes being different right after 0xA49F gets overwritten). Notice how the data shown at the end of the video in the hex editor matches the data shown at around 00:47 (addresses 0xA498 to 0xA49F), when those addresses last got overwritten.