In 2008, inichi demonstrated the full extent of subframe reset abuse in Chrono Trigger.
When Ersnes Rerecod Van Daaz Octava Deltius graced the land with his presence on the tenth of May, men fell to their knees as calamity brewed in the north.
Divine wrath descended upon a distant tundra. Thunder raged for several hours and the ground was carved anew. Soon the gods' message had reached even the farthest of lands:

"- Mid-frame reset support"

primary10bit444

  • Heavy glitch abuse
  • Uses sub-frame resets
  • Corrups save data
  • Demonstrates the glory of lsnes
Chrono Trigger (U) [!].sfc
md5sum:    a2bc447961e52fd2227baed164f729dc                                  Chrono Trigger (U) [!].sfc
sha1sum:   de5822f4f2f7a55acb8926d4c0eaa63d5d989312                          Chrono Trigger (U) [!].sfc
sha256sum: 06d1c2b06b716052c5596aaa0c2e5632a027fee1a9a28439e509f813c30829a9  Chrono Trigger (U) [!].sfc

Tricks and glitches

Loading corrupted save data

The game writes hash checksums upon saving; if the checksums don't match, the save(s) will be unloadable and displayed as empty.
Howewer, due to an oversight, it is possible to bypass this check and load corrupted save data by pressing Up+A on the save load screen.

Detailed commentary

Millennia Fair

Marle is picked up. If the Imp's house is entered without her in the party, the game will crash.

Zenan Bridge R1

The game is saved twice to set up save corruption at a later time.

Guardia Continent, Eastern Nebula

The position value 1F3E is partially overwritten with the party's current position, 4A50, resulting in the position 4A3E being stored in SRAM.

Guardia Continent, Imp's House

If Marle isn't in the party when entering this area, the game will crash.

The End of Time

The game is saved on a save point, resulting in the corresponding flag being set in SRAM. The subframe reset here is just for show - allowing the save to complete would yield equivalent results.

Zenan Bridge R2

The Zenan Bridge save is loaded. The game is then saved over the End of Time save and interrupted after the location values are written but before the save point flag is removed. This allows us to save anywhere.

Zenan Bridge R3

The game is saved on Zenan Bridge, resulting in a save file with a location value of 2000. We then exit the area and reset while the location value F001 is being written to the save file, resulting in SRAM containing the location F000.

Nu Ending

The location value F000 corresponds to the Nu ending, so the run ends when the save is loaded. Since triggering the ending in this manner wasn't intended, glitched graphics are briefly shown.

Special thanks to

  • inichi: for demonstrating the concept and making the extremely fabulous published runs.
  • Ilari: for making lsnes and helping with emulator usage and Lua scripting.

About obsoletions

The published any% and NG+ movies both abuse save corruption. This run is faster than both; obsoleting both of them seems to make the most sense.

Suggested screenshots

TBA

Nach: Reje... er... Judging.

turska: Replaced movie file. The new movie file is 46 frames faster.

turska: Replaced movie file once more. The new movie file is 12 frames faster.

Nach: I had a lot to consider in judging this run, the acceptability, the entertainment, the star issue, single or double obsoletion, and so on.
This run is clearly faster, made with a better emulator, and more real than the last run. Under these conditions, this run should be accepted to obsolete the current normal run. However this run is nowhere near as entertaining, so should it still obsolete it or not?
I watched the previous run a few times, my first reaction upon seeing it was that it was amazing and very entertaining, the second time was quite interesting too. On a third watch however, I found that the novelty wore off and the run wasn't all that entertaining. Since both these runs are about abusing SRAM, I'm accepting this run to obsolete the previous run, however, since there is very little entertainment in this run compared to the previous, it should be published without a star, a moon would be fine though.
Regarding the New Game+ obsoletion, I've mulled over it for a few days. It is loaded with a very pre-abused SRAM file. Technically, this current run here can also be loaded with a pre-abused file and cut the time down to mere few seconds. I find that pre-abusing a file sort of misses out on the point, and really is not deserving of a record. Since the main point of NG+ is to either show off new things in the game that can't be accessed otherwise, or beat the game significantly faster thanks to higher stats at the start, and the current NG+ run doesn't do the former, and it loses for the latter, I'm accepting this run to obsolete the NG+ as well.
Despite this double obsoletion for an abusing SRAM category, I think this site deserves a non abused version of CT and CT NG+, and I hope TASers will try to fill in these categories.


adelikat
He/Him
Emulator Coder, Site Developer, Site Owner, Expert player (3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Alaktorn, you are misinterpreting the Rule change about region. The U version is preferred first of all. Second of all, the region differences are NOT a factor in comparing times. There is no "time saved" by using the J ROM as far as the site is concerned. And runs will NOT be rejected by failing to use the faster J ROM. I expect any good judge would disregard a no vote based on this reason.
It's hard to look this good. My TAS projects
Skilled player (1741)
Joined: 9/17/2009
Posts: 4981
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
adelikat wrote:
If you are talking about the currently published 20 minute movie, this will have to obsolete it. It is the same glitch done better. More importantly the currently published movie has been proven invalid! It relied on the fact that saving takes 2 frames, and so reset can happen after one frame and corrupt memory. But it only takes 2 frames because snes9x is inaccurate in its emulation, it should only take 1, thus sub-frame reset would be required to corrupt ram.
Really? I never knew! Thanks for telling me this! This is just another reason why older emulators should be immediately banned slowly obsoleted like famtasia. Edit: Yes Vote, btw
Amaraticando
It/Its
Editor, Player (159)
Joined: 1/10/2012
Posts: 673
Location: Brazil
Wow, you totally break the already broken game. However, it uses a non-standard ending and doesn't face the last boss. I think it should not compete with the other submissions. Easy YES vote, despite the lack of entertaining factor...
ALAKTORN
He/Him
Former player
Joined: 10/19/2009
Posts: 2527
Location: Italy
adelikat wrote:
Alaktorn, you are misinterpreting the Rule change about region. The U version is preferred first of all. Second of all, the region differences are NOT a factor in comparing times. There is no "time saved" by using the J ROM as far as the site is concerned. And runs will NOT be rejected by failing to use the faster J ROM. I expect any good judge would disregard a no vote based on this reason.
I had misunderstood the rule change, but US text didn’t seem to hold any importance in this movie for me, so I might vote no either way; feel free to ignore it
Joined: 7/2/2007
Posts: 3960
Canar wrote:
This save corruption abuse thing is getting kind of ridiculous. While I agree that this should obsolete previous runs, I'd love to see proof that this actually works on a SNES. Of course, how the hell could you ever get the sort of precise timing needed to pull this off? I have no answers.
Timing for this kind of thing is even trickier than replicating a standard TAS on real hardware, because you have to send the reset command at a very specific time between instructions. The SNES's CPU runs at about 21MHz; if we assume it takes 16 clock cycles to run one instruction (almost certainly a gross exaggeration), and that the reset command can arrive at any point during a specific command to result in the desired corruption (probably not true) then that means that the reset command would have to arrive in a window of time only 16 / 21000000 = 761 nanoseconds in size. In short, don't expect to see this run verified on the console. Regarding the run itself, I have to say this didn't look very different at all from the run inichi made back then. I think it's entirely reasonable to list him as a coauthor; he deserves credit for figuring out the strategy even if none of his input survives in the finished version. Also, 233k rerecords? What took so much experimentation? Finding the exact time to trigger the resets?
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
NitroGenesis
He/Him
Editor, Experienced player (556)
Joined: 12/24/2009
Posts: 1873
Good improvement, but I like inichi's run more. This run is totally boring. Voting no. If this run is published as an obsoletion to the 20 minute run, I vote for removing the star.
YoungJ1997lol wrote:
Normally i would say Yes, but thennI thought "its not the same hack" so ill stick with meh.
ALAKTORN
He/Him
Former player
Joined: 10/19/2009
Posts: 2527
Location: Italy
Derakon wrote:
I think it's entirely reasonable to list him as a coauthor; he deserves credit for figuring out the strategy even if none of his input survives in the finished version.
that’s a good point, I’ve always thought that if I ever actually finished an AWDS TAS I’d list as a co-author my partner; he does no TASing, but almost everything related to RNG manipulation and general game knowledge, also (probably) strategy inputs come from him and the above has made me wonder about another point: what happens if you list an author that’s not a registered nickname on TASV?
Skilled player (1741)
Joined: 9/17/2009
Posts: 4981
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
ALAKTORN wrote:
and the above has made me wonder about another point: what happens if you list an author that’s not a registered nickname on TASV?
I listed an author who isn't registered in the site for the Telefang TAS, so I'm sure it's ok. But you should ask an admin or site coder for more details. Also, if this gets rejected, what will happen to the other run? Since the other run can't actually be done, will a glitchless run obsolete it?
BigBoct
He/Him
Editor, Former player
Joined: 8/9/2007
Posts: 1692
Location: Tiffin/Republic, OH
Is there a way to modify a Super Nintendo console so that a controllerbot could trip the Reset function instead of needing to hit the button yourself?
Previous Name: boct1584
Joined: 2/7/2006
Posts: 55
I've been mulling this over in my head. I don't want to come to TASvideos some day a few years from now and have pages of only 2 minute save corruption runs demonstrating nothing from the game. Unlike some people I think entertainment is secondary to speed (thus my easy yes vote here), but the aforementioned scenario sounds depressing. I think a "uses save corruption" category could be very useful in alleviating that future and should maybe be considered. I am also very curious if this mid-frame reset could ever be accomplished on a real console, even just once. We wouldn't support an emulator only construct would we?
adelikat wrote:
More importantly the currently published movie has been proven invalid! It relied on the fact that saving takes 2 frames, and so reset can happen after one frame and corrupt memory. But it only takes 2 frames because snes9x is inaccurate in its emulation, it should only take 1, thus sub-frame reset would be required to corrupt ram.
Reeaaaallly, thanks for pointing that out. Very interesting.
Derakon wrote:
Timing for this kind of thing is even trickier than replicating a standard TAS on real hardware, because you have to send the reset command at a very specific time between instructions. The SNES's CPU runs at about 21MHz; if we assume it takes 16 clock cycles to run one instruction (almost certainly a gross exaggeration), and that the reset command can arrive at any point during a specific command to result in the desired corruption (probably not true) then that means that the reset command would have to arrive in a window of time only 16 / 21000000 = 761 nanoseconds in size. In short, don't expect to see this run verified on the console.
Thanks for the explanation. Aside from verifying the run, can the very concept of mid-frame resets be verified?
Derakon wrote:
Regarding the run itself, I have to say this didn't look very different at all from the run inichi made back then. I think it's entirely reasonable to list him as a coauthor; he deserves credit for figuring out the strategy even if none of his input survives in the finished version.
+1. If this very concept and exact route is from someone else, I think that person is fairly a coauthor.
BigBoct
He/Him
Editor, Former player
Joined: 8/9/2007
Posts: 1692
Location: Tiffin/Republic, OH
Thanks for the explanation. Aside from verifying the run, can the very concept of mid-frame resets be verified?
Think of it like this. A second in real life doesn't take 60 arbitrary frames, it takes a second. Frames are just an arbitrary subdivision of seconds, which are themselves an arbitrary measurement of time. I think the real question is, "If a controllerbot was built that could handle the Reset button, would it have the finesse necessary to perform the sub-frame resets?"
Previous Name: boct1584
Player (210)
Joined: 7/7/2006
Posts: 798
Location: US
turska wrote:
Without inichi's demo run, this run would never have been made, but since he had no direct involvement in making this run, I can't list him as a coauthor in good faith.
I very much disagree with this. Who pressed the buttons has nothing to do with it, it's about who "constructed" the run. If anything I'd rather see inichi listed as author and not list you at all, but since you did construct the input file, I suppose you're rightfully a coauthor.
Derakon wrote:
Regarding the run itself, I have to say this didn't look very different at all from the run inichi made back then. I think it's entirely reasonable to list him as a coauthor; he deserves credit for figuring out the strategy even if none of his input survives in the finished version.
Agreed. Except instead of "entirely reasonable" I'd probably say "practically required". Based on my limited reading, it seems you took his planning and execution and (for the most part) copied it into another emulator. I would see it as opportunistic to call it your own run. Regarding the run itself: Once the author situation has been agreed upon, I think this run should be published and obsolete the 20 minute run. I think a category is available for a run with no SRAM corruption. That run sort of exists as inichi's test run from some years back which you can find buried in the forums. He never submitted it mostly because it was a test run. The 20 minute run could plausibly be replaced by a glitchy playaround in the future, but we should not reject a faster run using the same glitches. My vote stands at no (unofficially) unless one of the people who constructed this run gets credit or states that he does not wish to have credit. EDIT: Or I guess if the site takes a stance on the issue I will go along with it. It is a bit grey, but I really think inichi deserves credit on this one.
Joined: 7/2/2007
Posts: 3960
cwilliams wrote:
Thanks for the explanation. Aside from verifying the run, can the very concept of mid-frame resets be verified?
As I understand it, resetting the console is an inherently analog process -- you're disrupting power to the device. Of course the device needs power to operate, so when you press the button, it has no choice but to stop what it's doing. I suppose a reset button could also set an interrupt, in which case the CPU would be obligated to go down a different path than it normally would. I'm fairly sure this isn't how it actually works, but even if it did I don't know if it would make a difference in how the reset is perceived. Possibly the CPU would be allowed to finish its current instruction, but it certainly wouldn't be able to finish the entire frame. In short, mid-frame resets are not a controversial concept. If you mash reset while saving your game in Chronotrigger, you're going to corrupt your savefile due to interrupted instructions, even though saving only takes a single frame.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Guga
He/Him
Joined: 1/17/2012
Posts: 838
Location: Chile
Obviously, this is a faster run and a great improvement. But something is missing in this run. Entertainment. I, personally, prefer a longer, but entertaining run, than a faster, but boring as fuck one. Voting No.
Experienced player (764)
Joined: 6/17/2008
Posts: 146
All the information regarding this submission is out in the open - the decision about whether or not inichi is a coauthor in the context of a TASVideos submission is not mine to make. The rules don't have an exact precedent regarding something like this; if someone with sufficient authority makes a decision about this, I will follow it. Even if inichi is not semantically a coauthor, he would be credited in the publication text with some blurb like "inichi demonstrated the strategy used in TAS back in 200X. Only recently did tools become advanced enough for it to be possible".
inichi wrote:
Also, for the above reason, there is no way to confirm the validity of the movie, but I don't care. The reason is this is just a demo movie to show the further possibility of Chrono Trigger TAS. Hopefully this movie will work as a good reference when a new re-recording Snes9x that enables the reset between a frame comes out in the future.
Edit: also, I'll clarify the seemingly conflicting opinions I posted. The quip on IRC about not being against having inichi be a coauthor referred to a hypothetical scenario in which someone with sufficient authority deemed that to be preferable. The part in this thread where I say that I couldn't list him as a coauthor is based on my interpretation of the rules at the time of submitting.
Joined: 5/2/2006
Posts: 1020
Location: Boulder, CO
Derakon wrote:
In short, mid-frame resets are not a controversial concept. If you mash reset while saving your game in Chronotrigger, you're going to corrupt your savefile due to interrupted instructions, even though saving only takes a single frame.
My question is at what point does disrupting power to the console become a physical modification to the hardware? would it be valid if we had some way of emulating a power surge, or a voltage drop that disrupts the processor without turning it off entirely? I would be all for disallowing resets and power switch use except when the timing of it need not be frame precise. (like in cases when resetting is done to return to the game's initial spawn point). This would make sure that any resets would work in a way we can be sure are valid.
Has never colored a dinosaur.
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
Derakon wrote:
As I understand it, resetting the console is an inherently analog process -- you're disrupting power to the device. Of course the device needs power to operate, so when you press the button, it has no choice but to stop what it's doing.
No, the reset button sends a signal to the subsystems (CPU, PPU and audio CPU). This resets their status back to the default settings. A power cycle is really random (RAM values decay quickly).
Derakon wrote:
I suppose a reset button could also set an interrupt, in which case the CPU would be obligated to go down a different path than it normally would. I'm fairly sure this isn't how it actually works, but even if it did I don't know if it would make a difference in how the reset is perceived. Possibly the CPU would be allowed to finish its current instruction, but it certainly wouldn't be able to finish the entire frame.
The CPU needs several clock cycles per instruction (opcode), and as far as I know the reset signal blocks the next part of the current instruction, and doesn't let the instruction execute completely. Btw. there are 357,954.54(54...) clock cycles in a frame, and an instruction needs 6, 8 or 12 cycles, so there could be a variation of up to ±30,000 instructions, depending on where the emulator issues the reset signal.
Joined: 7/2/2007
Posts: 3960
Thanks for the information, creaothceann. So it actually does work by setting an interrupt that causes the systems to reset themselves. Good to know. Also my conservative guess, earlier in the thread, at 16 cycles per instruction wasn't actually that conservative! Ha!
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
Technically speaking this run is well done and demonstrates a very quick way to jump to the end of the game in a similar manner as how, for example, the run of King's Bounty. However, unlike King's Bounty, which does this via pure gameplay, this jumps to the end by abusing save data corruption, which is a technique I have always detested because I do not consider it gameplay. I consider it hardware abuse. Going by the letter of the rules, I would have to vote yes (because, as said, this is well executed and a good demonstration of a technique). However, since I find the used technique personally questionable, I would like to vote no. On the other hand, I would be an enormous hypocrite if I did that because I have complained many times about people abusing the voting system to protest site policies, hence I will not do that. "Meh" doesn't cut it either because it's not how I feel. Hence my only option left is to abstain from voting. No offense intended to the author.
Senior Moderator
Joined: 8/4/2005
Posts: 5777
Location: Away
cwilliams wrote:
Thanks for the explanation. Aside from verifying the run, can the very concept of mid-frame resets be verified?
That's simple: any keypress, reset or otherwise, happens mid-frame on the actual console. Emulators just decrease input resolution to screen refresh resolution for convenience. On a real console, you can push a button so fast the console won't register it—that wouldn't happen on the emulator.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Editor
Joined: 3/10/2010
Posts: 899
Location: Sweden
I think we can safely assume that we can't sync this one on hardware. But not due to limits in the playback tools. The real issue is that an emulator is an ideal simulation. All the timings are perfect and have the same values. Reality isn't like that. Components have tolerance ranges that affect the timing enough to cause syncing issues. We would need ludicrously accurate clocks in the hardware and perfectly manufactured components. Neither of those are realistic, or even achievable with lots of resources.
Player (89)
Joined: 11/14/2005
Posts: 1058
Location: United States
Comparing this to the test run originally provided by inichi, this seems to be a frame by frame copy of it. I vote yes, but clearly his name should be added to the authorship of this run. Now it would really be nice to see a non-glitched run produced using all current techniques and strategies.
They're off to find the hero of the day...
Senior Moderator
Joined: 8/4/2005
Posts: 5777
Location: Away
henke37 wrote:
We would need ludicrously accurate clocks in the hardware and perfectly manufactured components. Neither of those are realistic, or even achievable with lots of resources.
Rather, we need a lot of time for restarts. One of them will eventually sync.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Joined: 6/24/2007
Posts: 119
I think this is a good run. Yes vote. Since CT has multiple endings, every ending can be reached this way?
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
moozooh wrote:
any keypress, reset or otherwise, happens mid-frame on the actual console. Emulators just decrease input resolution to screen refresh resolution for convenience. On a real console, you can push a button so fast the console won't register it—that wouldn't happen on the emulator.
Reset isn't a joypad keypress, it has its own pin on the CPU (and the other components it's wired to). Most emulators accept keypresses frame-by-frame because (iirc) most games use the automatic joypad polling function which operates like that. If they do it directly then differences might be possible. bsnes logs and replays input by access and not by frame btw; no idea how lsnes handles the reset button. It could (and possibly should) be based on the master clock.