Submission Text Full Submission Page
  • Emulator: lsnes rr2-beta23
  • Rom: Final Fantasy VI (J)
  • Aims for fastest time
  • Manipulates luck
  • Executes arbitrary code
  • Features mid-frame resets
  • Corrupts save data
  • Ends input early
Here is an improvement of 8661 frames from the previous submission, thanks to a route change. Most of the tricks and glitches leading to ACE are identical to the previous submission, so we will only describe the changes in the present text. Comments are embedded in the above video and are available here.

Route change

To reach the Phantom Forest, Sabin and Cyan are mandatory. We choose in this TAS another way for them to join the team, by doing the Kefka at Narshe section. Normally, when you leave Narshe the first time with Locke, you cannot enter Narshe again until much later after the 3 scenarios. However, if you overwrite the events flags stored in the savefile with the ones from the beginning of the game before Locke joins, you can freely enter Narshe. By heading north to the snowfield, you will be able to trigger the fight against Kefka. After that, you can form your team, which contains Sabin and Cyan. Because they did not actually join the team yet, they are replaced by their Moogle placeholder. After that, the route is pretty much the same.

Executed code

The code executed to trigger the ending was improved a bit. We were very lucky this time to encounter the Goblin*2 fight, so we only had to kill one enemy, which shortened the code.
 3A             DEC                   A = 0xFF
 9E 55 3E       STZ $3E55,x [$3EEC]   Unflag enemy death, to avoid an XP/Gold message
 0C 3A 3A       TSB $3A3A             Remove enemies from the fight
 C2 20          REP #$20              16-bit accumulator
 A9 62 13       LDA #$1362            Loads the ending sequence event address
 0C 4F 1F       TSB $1F4F             Set NPC event bit to avoid the ending softlock
 9D 4E 12       STA $124E,x [$12E5]   Set event pointer to the ending
 69 7F 02       ADC #$027F            A = 0x15E1
 1B             TCS                   Fix the stack pointer
 5C C9 18 C1    JML $C118C9           An address in the C1 bank that contains SEP #$20 then RTS
Also, the offset in the color configuration to write this code was optimized to minimize the number of color values to change. Both changes accounted for a total improvement of 7 seconds.

Suggested screenshots

Frames 62280, 95655

Fog: Judging.
Fog: This is a great run that alleviates all of the prior issues that were had with the previous publication, as well as the rejected submission. The use of the new route makes the entertainment factor of the submission much better than the previous publication, where you needed 52 game over screens, while also being faster than the previous publication. Unlike the previous publication, this movie does not start from dirty SRAM (albeit empty). However, there has been some chatter in the submission comments about how this submission seeds the RAM by adjusting the RTC. This is a feature that is built into Higan, the most accurate SNES emulator, and the core that lsnes uses. For it to be used, the TASer must turn on initialize random values in the emulator settings.
And here lies the problem with this run. The movie rules state that there are to be no randomized or unverified initial RAM states. If this run can be completed without using the randomized initial memory, then that run would be accepted. However, it's not possible to accept this run under it's current form.
Rejecting for using randomized initial memory.


TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 15527
Location: 127.0.0.1
Joined: 1/14/2016
Posts: 100
Very nice, congrats on the improvement! Let's hope a run that is 18 seconds faster with a less entertaining strat won't show up this time. I have one question, though. You say that "We have build up a save outside Narshe with Terra/Locke party and events from the beginning of Narshe", but I did not see you leaving Narshe. Shouldn't it be "inside Narshe", or am I missing something?
keylie
He/Him
Editor, Emulator Coder, Expert player (2837)
Joined: 3/17/2013
Posts: 392
By outside, I mean in front of Narshe actually.
Patashu
He/Him
Joined: 10/2/2005
Posts: 4042
One question I have that I forgot to ask the last time you submitted this TAS: "In lsnes emulator, it is possible to manipulate the initial RAM values to some extend by setting the value of the Real Time Clock that acts as a seed. The first value of the RAM is set to the lower byte of the RTC, and each consecutive value is generated using a recursive formula: value = (value >> 1) ^ ( ( (value & 1) - 1) & 0xedb88320)" Where can I read in more detail about the Real Time Clock and how it sets initial values? Is it a quirk of the real SNES console that is being faithfully reproduced? Or is it an lsnes-specific quirk and not really related to a real SNES? How hard would it be in theory to reproduce this TAS on a real SNES?
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
keylie
He/Him
Editor, Emulator Coder, Expert player (2837)
Joined: 3/17/2013
Posts: 392
I took this from reading the Higan source code. This is an emulator specific method to fill the initial RAM values. Snes9x fills 0x55 in the whole RAM, for example, and lsnes can also do that if you don't check "Initial random values". The actual console behaviour has been discussed in this forum. From what I remember, on a brand new console, RAM addresses can take multiple values, not with the same probability, and there are dependencies between different addresses. I don't know if the method to launch another game to write the desired values into RAM, and quickly change the cartridge to keep the same values, works on the SNES. If not, you would need another method to fill the correct values. Also, there are longer setups that do not rely on uninitialized RAM.
Editor, Player (69)
Joined: 1/18/2008
Posts: 663
Patashu wrote:
Is it a quirk of the real SNES console that is being faithfully reproduced? Or is it an lsnes-specific quirk and not really related to a real SNES? How hard would it be in theory to reproduce this TAS on a real SNES?
SNES uses PSRAM, so values are random (with possibly some per-console bit pattern probabilities). Runs should not rely on starting state unless they have a sufficiently high probability of success. The community hasn't defined what this probability should be, though. Cart swapping doesn't work on SNES because of CIC, and physical interlock on the original release console. Holding the console in reset doesn't work either, as the CIC will not release reset until power cycled. This is unlike NES which will renegotiate after reset.
true on twitch - lsnes windows builds 20230425 - the date this site is buried
Joined: 4/18/2006
Posts: 179
Location: East Petersburg, PA
True wrote:
Cart swapping doesn't work on SNES because of CIC, and physical interlock on the original release console. Holding the console in reset doesn't work either, as the CIC will not release reset until power cycled. This is unlike NES which will renegotiate after reset.
So, does that process work on this version of the console? And, a general question, does this community restrict specific console versions (or emulations thereof)?
"I think we can put our differences behind us... for science, you monster."
Dwedit
He/Him
Joined: 3/24/2006
Posts: 692
Location: Chicago
Given that the first warp to the southern continent relies on a specific emulator quirk (RNG seed that initializes ram to the coordinates necessary), I really don't know if this TAS is okay. It can't be console-verified in its current state. It's just like starting from a saved game. Edit: Quotes from the rules: http://tasvideos.org/MovieRules.html
Tools that manipulate ROM or RAM (e.g. Game Genie codes) are not allowed They count as hacked versions of the game if they touch ROM areas. Either convert it to a real hack or don't use it at all. No questionable emulator settings The emulator should be set to emulate the system as closely as possible while still allowing the game to be played. You should not depend on a particular emulator hack to gain speed.
Does using a particularly selected RNG seed to initialize memory violate these two clauses? In my opinion, relying on an emulator setting to initialize what is otherwise uninitialized memory is the same thing as using a game anchored from a saved game, and that usually means you need a verification movie (just walk to the correct spot on the overworld and reset?)
Zarmakuizz
He/Him
Joined: 10/12/2013
Posts: 279
Location: France
Do you mean like The Cheetahmen II?
Dwedit
He/Him
Joined: 3/24/2006
Posts: 692
Location: Chicago
Cheetahmen II had to do with the cartridge's mapper registers, not system RAM content. And that game is literally uncompletable without the initial cartridge register quirk (which is known to occur on hardware).
Joined: 9/1/2014
Posts: 58
Certainly more fun to watch than the previous one I recall of fighting world map enemies for like 20 minutes in a row to trigger the end. The final few minutes waiting for the enemy does naturally drag and I did skip forwards on that bit but having final input before that waiting time does technically make it a part of the ending cutscene so I can't fault the run for it. An enjoyable video and the text commentary helped a lot.
Enjoys speedruns but hasn't actually tried making any yet.
TASVideosGrue
They/Them
Joined: 10/1/2008
Posts: 2780
Location: The dark corners of the TASVideos server
om, nom, nom... 'twas dry
Samsara
She/They
Senior Judge, Site Admin, Expert player (2098)
Joined: 11/13/2006
Posts: 2821
Location: Northern California
So the movie was rejected for a rule that didn't exist at the time the run was submitted?
TASvideos Admin and acting Senior Judge 💙 Currently unable to dedicate a lot of time to the site, taking care of family. Now infrequently posting on Bluesky
warmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Fog
Emulator Coder, Experienced player (640)
Joined: 4/5/2014
Posts: 459
Samsara wrote:
So the movie was rejected for a rule that didn't exist at the time the run was submitted?
It existed prior to the run being submitted. http://tasvideos.org/MovieRules.html#MovieMustBeginFromConsolePowerOn Note the "Clear SRAM" portion. All that the added rule did was clarify the existing rule.
Samsara
She/They
Senior Judge, Site Admin, Expert player (2098)
Joined: 11/13/2006
Posts: 2821
Location: Northern California
You should probably cite that rule as well, then, instead of just the one that was added literally hours ago. It would make more sense and it wouldn't sound unfair.
TASvideos Admin and acting Senior Judge 💙 Currently unable to dedicate a lot of time to the site, taking care of family. Now infrequently posting on Bluesky
warmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
The rule that is clearest was cited. The rule clarifies other rules as applicable to the case at hand and existing policy. It's not unfair because we've rejected/cancelled similar runs in the past. Even if not, we're free to institute new rules as new cases demand them.
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: 4042
This TAS should be added to http://tasvideos.org/Movies/GruefoodDelight.html under 'Technical Foul'.
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
Samsara
She/They
Senior Judge, Site Admin, Expert player (2098)
Joined: 11/13/2006
Posts: 2821
Location: Northern California
Nach wrote:
The rule that is clearest was cited. The rule clarifies other rules as applicable to the case at hand and existing policy. It's not unfair because we've rejected/cancelled similar runs in the past. Even if not, we're free to institute new rules as new cases demand them.
I literally only asked for clarification on what I initially thought was a completely unfair decision. The way I saw it was that the staff literally added a rule and then rejected a run minutes later for not following it, which came off as unfair to me. Once I understood that this was not the case, I asked for that to be made clearer in the judgement message. I should have made that clearer, I guess.
TASvideos Admin and acting Senior Judge 💙 Currently unable to dedicate a lot of time to the site, taking care of family. Now infrequently posting on Bluesky
warmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
keylie
He/Him
Editor, Emulator Coder, Expert player (2837)
Joined: 3/17/2013
Posts: 392
Fog wrote:
Samsara wrote:
So the movie was rejected for a rule that didn't exist at the time the run was submitted?
It existed prior to the run being submitted. http://tasvideos.org/MovieRules.html#MovieMustBeginFromConsolePowerOn Note the "Clear SRAM" portion. All that the added rule did was clarify the existing rule.
You refer to this rule?
any check box that has "Clear SRAM" or similar must be checked
This sounds quite far from "not manipulating RAM at startup". But ok now we have a clear rule. I would also note that Final Fantasy 6 will probably never be verified anyway, because it uses uninitialized RAM for very important things such as the random battle danger value, which will determine when the first random fights will trigger. Edit: SNES core of Bizhawk uses random values for initial RAM. I cannot test if it still stands because the latest versions crash on my computer, but it is the case until version 1.11.1
Site Admin, Skilled player (1250)
Joined: 4/17/2010
Posts: 11468
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
I don't care about the rules timing, but I can remind about this one: #5266: Alyosha's NES Cybernoid: The Fighting Machine in 04:39.02 That run relied on a startup state that can be possible, but is not guaranteed to be so, it relied on an unreliable thing and got rejected. That set the precedent, and the rule was just a result, to make all the future occasions like this clear (I guess?).
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
feos wrote:
I don't care about the rules timing, but I can remind about this one: #5266: Alyosha's NES Cybernoid: The Fighting Machine in 04:39.02
That was one of the runs I was referring to when I mentioned existing policy with rejecting/cancelling runs like these.
feos wrote:
the rule was just a result, to make all the future occasions like this clear (I guess?).
Yes. Although, it is an extension of existing rules such as "Clear SRAM" or similar. Presetting RAM with a so-called random state allows players to beat a game in under a second if that's what they were aiming for, and is generally much worse than only setting the SRAM component of memory. It might as well be a save state, except some want to make believe it isn't, since you know the values were "randomly" selected. From there, it's only a matter of how much a player disguises it. With the added line to the rules, we're clarifying this. Unless the state as a whole is proven to be possible, we're not going to accept runs that tweak bytes specifically for some kind of advantage.
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: 4042
Unless the state as a whole is proven to be possible, we're not going to accept runs that tweak bytes specifically for some kind of advantage.
And just to be clear - the tools currently do not exist to do this, right?
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
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
The tools to determine what start up state for particular RAM cells is exists. No one is actually working on investigating and documenting it to my knowledge.
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.
Player (13)
Joined: 6/17/2006
Posts: 506
Please excuse my ignorance on the matter, but does a RAM state containing only zeroes must be proven possible on a given console now before submitting a run with this property? I realize that this is probably true for most computers by waiting long enough on a power off state, but I don't think it's true for the general case. If my fear is justified, it would put the validity of most published movies into question.
Site Admin, Skilled player (1250)
Joined: 4/17/2010
Posts: 11468
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
SmashManiac wrote:
Please excuse my ignorance on the matter, but does a RAM state containing only zeroes must be proven possible on a given console now before submitting a run with this property? I realize that this is probably true for most computers by waiting long enough on a power off state, but I don't think it's true for the general case. If my fear is justified, it would put the validity of most published movies into question.
The point is not that the current runs should also have that proven, but that all the runs should have reasonably equal conditions for a fair competition.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.