After this article I’ve started binge watching this whole channel. Extreme in depth analysis and code walking of NES games in assembly is so interesting. Really makes you appreciate how small and simple the platform was. “Optimizing” a game really feels like a noticeable difference. I also learned how Gameshark codes work, they’re just editing addresses and OP codes directly.
The coolest GameShark was the N64 GS, where you could make your own codes. Like, it allowed you to go into a game, take a snapshot of the code, shoot a bullet, then analyze the addresses that changed between your snapshot and when you’ve shot the bullet. Then, you can edit the changed value, and boom! Infinite ammo!
Zsnes had/has some tools similar to that. Can’t remember if there was a diff (I might not have realized the usefulness of that at the time and skipped over it), but I do remember using a search function to see if I could find values from the UI.
Oh yeah!
I just found it wild to be able to do it on the fly, on a console, in the 90s! What a time!
Not quite the same, but if you’re into this stuff, I highly recommend the channels pannenkoek2012 and Retro Game Mechanics Explained. Both very in depth channels about Nintendo jank,
pannenkoek2012, the legendary half an A press guy! I watch a fair bit of retro game speedrunners so he’s practically required viewing in that space.
I appreciate that there are people who get really into thoroughly beating a video game.
However at the level that they’re beating the game during a play session to fill out the high scores table such that they can exploit bugs to patch code using data in said high scores entries to fix the bugs in the game that prevent further progress, I feel that maybe it’s time to just declare that you have, in fact, thoroughly beat Tetris and try a new game.
It could even just be a newer entry in the Tetris family.
nah fuck that, this is way cooler.
This is the best summary I could come up with:
But a recent video from Displaced Gamers takes the idea from private theory to public execution, going into painstaking detail on how to get NES Tetris to start reading the game’s high score tables as machine code instructions.
But players can manipulate this jump thanks to a little-known vagary in how Tetris handles potential inputs when running on the Japanese version of the console, the Famicom.
As it happens, the area of RAM that Tetris uses to process this extra controller input is also used for the memory location of that jump routine we discussed earlier.
That means only a small portion of the NES’s available opcode instructions can be “coded” into the high score table using the available attack surface.
Of course, the lack of a battery-backed save system means hackers need to achieve these high scores manually (and enter these complicated names) every time they power up Tetris on a stock NES.
With that kind of full control, a top-level player could theoretically recode NES Tetris to patch out the crash bugs altogether.
The original article contains 771 words, the summary contains 175 words. Saved 77%. I’m a bot and I’m open source!
Holy shit, stop the presses
I’m glad DisplacedGamers is finally getting the recognition he deserves. I personally prefer his older content from before he started the behind the code series, but this latest one on reprogramming Tetris was great.
