(Link to video)
Submission Text Full Submission Page

Behold!

It is time to unleash the ultimate destruction of this piece of interactive game software called Super Mario World!

Game objectives are comfy and easy to wear

  • Emulator used: lsnes rr2
  • Win the game
  • (very fast)
  • details

Saving... do not turn off th-

Overwriting the bytes in a savegame is not an instant process. Resetting halfway through can result in a corrupted savegame. To try and avoid loading faulty data, most games use a checksum, so does SMW. The checksum is 16 bits and thus can only hold 2^16 = 65536 different values. This means a working corrupted savegame can be created with a well-timed reset.

Super SRAM World

Loading corrupted savegame data itself does not crash the game or lead to any dangerous codepaths.
However, a corrupted submap value will make the game load graphic bytes from various locations (and one of those locations can be SRAM itself). Having corrupted graphics doesn't crash the game, but important here is how the game first decompresses the data into a buffer in memory ($7E:AD00). There are no checks for the bounds (only 0xC00 = 3072 bytes are allocated), so we can buffer overflow bytes all the way to $7F:8000 where SMW stores its OAM clearing routine, which runs every frame when there are sprites on the screen.
Of course, we're not only able to overwrite the data with random values, we can actually overwrite the bytes with arbitrary code.

Arbitrary Code Execution?

Arbitrary Code Execution.

There are like a few dozen frames, which one is the best?

There are at least 3 interesting ones (check the credits), but to avoid spoilers I'll just give you this one.

So there's "dirty" SRAM? Tell me, what is "clean" SRAM?

The current published run relies on a SRAM byte to have a specific value for it to work. It just so happens that our accepted SNES emulators fill the SRAM with the required byte.
If the current run is allowed to be on this site, then this new run, which relies on SRAM intialization as well, has to be accepted.
Is filling the memory with a single byte "cleaner" than filling it with somewhat random data? This particular run goes the extra mile and also includes a payload, but remove the payload and you will get a crash which can in theory lead to controller registers, and to the credits all over again, extending this run by a few frames.
If this run is rejected, is the current run faulty as well?

Nach: This run is in violation of the various rules. Rejecting.

Skilled player (1707)
Joined: 9/17/2009
Posts: 4952
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
Now I'm legit curious is there a way to set the SRAM byte to whatever allows ACE possible in game fast enough to obsolete the current TAS.
Editor, Player (44)
Joined: 7/11/2010
Posts: 1022
electricslide wrote:
Ais, your point about 'adjusting the time' to match what the net expected number of resets requires makes no sense to me from a TAS context. Luck manipulation is a big part, making unlikely things happen on command is huge.
The whole point is that you can't manipulate it by control input. The only ways to manipulate it would be unauthorised changes to the cartridge or console. Seeing TASes manipulate luck is fun, but only because they do it to the laws of the game, rather than cheating.
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
MESHUGGAH wrote:
Okay... so... If the lsnes SRAM is valid, what other set of bytes can be valid? Or other words, if lsnes SRAM is known to be invalid, what should be valid?
Battery backed up SRAM from the factory is initialized to something. It can differ from each manufacturing of a particular game. There would be no way to know without having a database of known initial SRAM states for each game. If you removed the battery and then provided power to truly allow it to be uninitialized except by the console itself, then what it would contain would be some kind of pattern based on the circuitry in question.
jlun2 wrote:
Now I'm legit curious is there a way to set the SRAM byte to whatever allows ACE possible in game fast enough to obsolete the current TAS.
Questions regarding a single byte are always invalid as I wrote about many times on the topic.
MESHUGGAH wrote:
I was waiting for an elaborated rejection regarding SRAM + uninit RAM rules territory. Also if Masterjun could make an ACE without relying on uninit RAM and SRAM modification, changing these two while making a verification movie, should he submit this movie again but without rejection? This also sounds.... educational.
Already answered in the rejection you didn't read closely enough.
TASVideoAgent wrote:
This run is in violation of the various rules. Rejecting.
Specifically the first link. As it says that SRAM verification movie is for unlocking game modes like New Game+, not for putting prework into something and magically beating the game in moments. To add insult to injury, here is Masterjun himself: <Masterjun> I'm surprised people want verification movies, since when can you simply count off the time it takes to set up a glitch
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
MESHUGGAH
Other
Skilled player (1890)
Joined: 11/14/2009
Posts: 1349
Location: 𝔐𝔞𝔤𝑦𝔞𝔯
Okay, let's take it serious. If someone makes a TAS of SNES Donkey Kong Country 2 pulling of the save glitch (Masterjun used it to make a christmas present TAS AFAIK), can I use that particular SRAM which resulted by that TAS? If yes, am I allowed to just simply edit those bytes to those values? There are many SNES games where SRAM corruption happens so this is completely a working in real life glitch.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
I don't know why this isn't clear already. 1) Verification movies are not allowed for anything other than unlocking built-in game modes. 2) You cannot edit SRAM values individually.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Since the subject is not well understood by our members, I wrote a page on the topic: http://tasvideos.org/Nach/MemoryInit.html Hopefully this should clarify any questions or doubts you've had.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Patashu
He/Him
Joined: 10/2/2005
Posts: 4017
Nach wrote:
Since the subject is not well understood by our members, I wrote a page on the topic: http://tasvideos.org/Nach/MemoryInit.html Hopefully this should clarify any questions or doubts you've had.
For the section ‘How memory initialization affects games’, you can use this list to give examples of games that depend on uninitialised RAM: http://wiki.nesdev.com/w/index.php?title=Game_bugs&redirect=no#Reliance_on_RAM_values
My Chiptune music, made in Famitracker: http://soundcloud.com/patashu My twitch. I stream mostly shmups & rhythm games http://twitch.tv/patashu My youtube, again shmups and rhythm games and misc stuff: http://youtube.com/user/patashu