I'm sorry if this has been discussed and explained before, but due to the recent discussion in the CT submission thread, I started wondering:
How well do emulators really emulate what happens when you reset while the game is saving? Is it a 1-to-1 accurate simulation of what would happen in the real hardware?
Glitches which are purely caused by the emulator itself and don't happen in the real console are forbidden, and for a good reason: Abusing them is completely equivalent to hacking the ROM or using cheats.
Also glitches which work differently in the emulator than in the real console are, at the very least, very dubious. After all, TASing is all about what would theoretically happen in the real console if a perfect godlike being was playing. It's not about what would happen in an emulator.
So how do we know that the glitches caused by resetting during saving work in the same way in the emulator as they would work in the real console?
I see two scenarios here:
1) The emulators emulate the hardware perfectly, and this is easy to corroborate (by knowing how the hardware works, and by studying the source code of the emulators). If this is the case, then there isn't any kind of problem.
2) The glitches caused by this are emulator-specific and do not necessarily correspond to how the real console would behave. If that's the case, then this puts into question the runs which abuse the save glitching (because, as said, it's more or less equivalent to emulator cheating). At the very least this would cause these runs to have to be demoted to "demo" status.
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
I'm sceptical about a lot of the bugs that cause the rewriting of a large amount of memory values in general.
Does anyone remember the Sketch bug in Final Fantasy 6? It's conceivable that the results of that bug are accurate, as there are videos of it being done on a real console that confirm the effect's validity (or so I heard, I haven't actually searched for these myself).
However, there is another, related bug which involves attacking while an item is equipped as weapon. In Snes9x, the results of this bug are arbitrary in the sense that if you save a state right before the bug occurs and then load it after the bug occurred, the results may be different. I've even had the emulator crash. Granted, this was all quite some time ago, so it may have been fixed since then, but it points to either the emulator being inaccurate or the save states being incomplete.
Since I'm not a console hacker I really have no idea of what I'm talking about, but it seems to me that glitches that overwrite large amounts of data might need to be examined a little closer because of how drastic they are and how much of a difference minor emulation inaccuracies might cause.
I'm not so worried about game bugs which randomly trash the RAM of the console, because that's rather obviously easy to emulate correctly in an emulator, and I assume all emulators do this perfectly. After all, the behavior of a program trashing memory is completely deterministic (because it's completely ruled by the CPU opcodes being run at precise ticks of the clock).
What I am worried about is when the trashing goes outside the boundaries of the console CPU, in this case the hardware which performs the saving of the data in the cartridge. I don't know how this happens in the real console, but I assume that it's not synced with the CPU (as most hardware I/O isn't). If two pieces of hardware are not perfectly synced to each other with the same clock signal, their mutual behavior becomes nondeterministic.
That's why I'm asking how well emulators really emulate this saving process: Is it a perfect 1-to-1 emulation of what happens in the real hardware, or is it just a "as long as it works, it's enough", without regard of whether the timings are 100% accurate?
Even if the emulation is not 100% accurate, how much does it really deviate?
It seems to me that with something like saving, it's not the timing that matters; it's the order, and that should be preserved by any accurate emulator. My reasoning for that is that saving is asynchronous; it isn't locked to frames.
When inichi says that it takes two frames to save in CT, what he means is that control is returned to the player after two frames have passed (or something similar). The actual saving process presumably takes somewhere between 1 and 2 frames to complete, and a player on a console with superb timing could reset the game at any point in that period, with potentially different results depending on how much of the saving process had completed. In contrast, emulators can only accept input on frame boundaries, which means that we only have one point at which we could hit the reset button.
So as long as things are saved in the correct order (and I see no reason why they wouldn't be), there's theoretically an instant in which, by hitting the reset button, a console player could get the same memory corruption as the emulated player. Depending on the game and exactly how it writes to SRAM, though, that process may have more or fewer "breakpoints" -- the more breakpoints there are, the more varieties of glitches you can get by resetting, and the harder it becomes to get exactly the one glitch that the emulator can get because of its restricted timing.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
What I am worried about is when the trashing goes outside the boundaries of the console CPU, in this case the hardware which performs the saving of the data in the cartridge. I don't know how this happens in the real console, but I assume that it's not synced with the CPU (as most hardware I/O isn't). If two pieces of hardware are not perfectly synced to each other with the same clock signal, their mutual behavior becomes nondeterministic.
As far as I know, on the SNES the saving actually is synced with the CPU. SRAM is nearly identical in usage as RAM while the power is on. I'm not a hardware expert though, I'm only guessing this based on what I know from how the software and address mapping work.
If anything, resetting on the console should allow far more interesting results than resetting in emulator. You should be able to reset in the middle of a particular bit of code while the game is saving to save certain values but not others, or reset mid-instruction to get a completely different value.
Since the SNES is based on the NES, I'd assume it's the same with that too, and possibly all older systems. It's pretty simple so I don't see any problems emulation might run into; essentially, everything that happens in emulation should be a subset of what can happen on console (since on console strange things like electrical quirks with accessing memory the same time power is lost or resetting in a particular section of code can give different results within a single frame). Until we get to newer systems that *do* have more advanced memory management.
kwinse wrote:
Kejardon wrote:
Kriole wrote:
Samus is damaged by a Rinka in the opening.
That's a script action; no damage.
... it just dawned on me I know way too much about SM.
I brought this question up before, and it was quickly attacked / ignored. I think you asked it better than I did, though.
Derakon's explanation is understandable. The emulator is performing the same operations in the same order as would happen on a console, with a reset happening on a frame boundary rather than infinitely at any point. What I do not know is if on the real console there is a deterministic amount of data written on each frame (and, if so, if there is much / any idle cycles before the next frame), or if data is written as fast as possible with varying data rates based on SRAM speed or CPU clock speed. Emulating a faster CPU could quickly determine this, as well as debugging the save code. I don't know much when it comes to debugging emulator games, so it's probably the job for someone else. :)
As far as the chip actually saving the data, the write is usually very quick (although I don't know for EEPROMs of this era). You are far more likely to have corruption from the code for saving not being completed than having corruption from the SRAM not being completely written to.
I personally don't like to see these SRAM corruption bugs in TASes much either, but they do make for some very fun looking runs, such as the recent CT run by inichi you mentioned. I would certainly still like to see some of the other glitches inichi can perform in a non-save-glitch run... :)
Joined: 11/17/2005
Posts: 278
Location: Massachusetts, USA
Memory corruption bugs are my favorite! :) What a dorky thing to say. I'm not an expert on SNES hardware but I do know about the specific examples you presented.
Omega wrote:
Does anyone remember the Sketch bug in Final Fantasy 6? It's conceivable that the results of that bug are accurate, as there are videos of it being done on a real console that confirm the effect's validity (or so I heard, I haven't actually searched for these myself).
This glitch is definitely emulated correctly. I even used a guide to doing it on a console while I made my glitched run. The reason this exploit works the same in an emulator is because it predictably writes over (mostly temporary) variables with a payload coming from the ROM itself. You can't manipulate the payload and the same addresses are poked with the same values each time. And none of the affected memory addresses contain code, pointers to code, or any type of script. And interestingly it's the complexity of FF6 that causes the glitch to be predictable. Because so many temporary variables are created for each battle, the ultimate result is always either a hard crash or an arbitrary inventory modification.
Exceptions:
- The only other thing besides your inventory that you can break, is the camera. I've tried really hard to exploit breaking the camera, but it was no use.
- If you cause a hard crash then the result of the hard crash might not be accurately emulated. Read the next section. And by the way, for snes9x 1.43, I think I've had the Sketch glitch overwrite memory that belongs to the emulator itself; which leads to lol roflcopter wtf headdesk and hours of wasted effort. (You load a new save state, and the game is still dead somehow, or stops emulating or syncing correctly.)
Omega wrote:
However, there is another, related bug which involves attacking while an item is equipped as weapon. In Snes9x, the results of this bug are arbitrary in the sense that if you save a state right before the bug occurs and then load it after the bug occurred, the results may be different. I've even had the emulator crash. Granted, this was all quite some time ago, so it may have been fixed since then, but it points to either the emulator being inaccurate or the save states being incomplete.
And this is an unpredictable bug. The difference here is that random garbage that is not an animation script is being interpreted as if it were an animation script. This causes graphics corruption as the rendering code runs crazy. The bad script may also cause arbitrary code to run, which may cause illegal instructions, which can lead to emulator inaccuracies. SNES9x handles all of the documented features of the SNES perfectly*. But when it comes to the undocumented features and illegal instructions, who knows? A real console may not even crash or behave weird. So the emulator just does its own thing there.
I think the policy of this site is to reject glitches that are emulator-only. Super Metroid has the Murder Beam glitch which isn't used here because it executes a bad animation script which behaves differently on a console than it does in snes9x. Kirby Superstar has some nonsense way to summon the final boss, but that's banned too because it also relies on the emulator's handling of certain bad code.
Basically, the line is drawn at modifying data versus running bad code. If your game executes what would be considered a seg fault or an illegal instruction in Microsoft Windows, then your TAS is invalid. Unless you can prove that a console has exactly the same undefined output. As if, because if you get that far, then you've almost certainly also crashed the program.
I mentioned the reset button thing in inichi's Chrono Trigger thread. If he had precise control over how much of the save file was written before it was interrupted then he could surely do a lot more with it.
I apologize for bumping this thread again, but a thread in the submissions forum raised this question again, and this issue honestly bothers me a bit. I would like to hear your opinions.
What bothers me about SRAM corruption is that it's not bug/glitch abuse. In fact, it's not really related to the game itself at all. It's related to the console hardware. In other words, resetting during a save emulates what happens to the console hardware in such a situation, rather than what happens to the game. The subsequent game data corruption is only a side-effect of abusing the hardware.
Somehow that feels so detached from the game itself that it just doesn't feel right. You could as well try to emulate what happens to the game if you smash the console with a sledgehammer (or if you want a more realistic example, you could try to emulate what happens if a RAM chip in the console suddenly breaks). What happens might be interesting, but is it really TASing? Or is it just emulating hardware abuse?
Or if I go more to the point: You could as well "emulate" what happens if you had a gamegenie connected to the console and entered some codes.
I don't really see a lot of difference here. Both techniques would be emulating hardware abuse, and how that abuse affects the game. If the game starts behaving in strange ways it's not because of any bug or oversight in the game itself. It's because you abused the console hardware (emulated, but still).
For this reason I strongly oppose the idea that SRAM corruption runs would obsolete any of the more "legit" runs of the same game. In fact, it wouldn't bother me at all if the technique was banned altogether (but I suppose it's too popular for that). At the very least, it should be kept as its own separate category which doesn't obsolete nor override more normal categories.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
byuu fully researched how reset affects the SNES memory and registers. He and I have fully emulated this in ZSNES and bsnes.
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.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
Warp wrote:
You could as well try to emulate what happens to the game if you smash the console with a sledgehammer. What happens might be interesting, but is it really TASing?
There's a big difference here between SRAM corruption and smashing the console with a sledgehammer or "emulating" the game being plugged into the system through a Game Genie.
With SRAM corruption, there's no permanent damage. The game and the system stay intact to be used later. To complete a legitimate speedrun, the viewer must be able to see the end-of-game sequence. In the case of modifying a chip, you can make the system show the end-of-game sequence, but the system is modified and can't be used to play games normally any more. In the case of smashing the console with a sledgehammer, the console and game can't be used any more, AND the speedrun is not completable due to never being able to see the end-of-game sequence.
In the case of playing the game through a Game Genie, the original setup is not intact. The Game Genie is interfering with the direct connection from the game to the console required for the speedrun.
The fact that SRAM corruption is done only by pressing buttons on the console and not by modifying the game setup (by having the game go through a Game Genie or similar) or console using a screwdriver or similar external tools makes it a legitimate technique in tool-assisted speed running, in my opinion.
On SDA, one of the rules written on their rules page is this:
Speed Demos Archive wrote:
System modification: You are not allowed to modify your system or use extra hardware such as GameSharks and Game Genies. These devices let you alter game parameters and can give you an unfair advantage. The only allowed extra hardware are modchips and boot disks used for playing imports, and official add-ons. For example, the PS2 HDD is allowed, while the HD Loader is not.
Using external hardware or modifying the system is very different from merely making the game change the values in the SRAM already present in the system, which it does while playing normally anyway (via saving).
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Lex wrote:
With SRAM corruption, there's no permanent damage. The game and the system stay intact to be used later.
Oh, I wouldn't say that. Not at all.
Certain games were poorly programmed that they rely on having "valid" states in the SRAM for the game to work properly. If you modify the SRAM contents to values other than the initial one it ships with, or those normally set by the game, the game will no longer work correctly.
It's annoying for us emulator authors, as we need to figure out to set an initial SRAM image for certain games.
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.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
Nach wrote:
Lex wrote:
With SRAM corruption, there's no permanent damage. The game and the system stay intact to be used later.
Oh, I wouldn't say that. Not at all.
Certain games were poorly programmed that they rely on having "valid" states in the SRAM for the game to work properly. If you modify the SRAM contents to values other than the initial one it ships with, or those normally set by the game, the game will no longer work correctly.
It's annoying for us emulator authors, as we need to figure out to set an initial SRAM image for certain games.
Hmmm. If that's the case, then maybe it is a more permanent modification after all, and possibly therefore not legitimate. Warp may have a point here.
Edit: Actually, now that I think about it, if you consider the fact that the game boots and loads the corrupt SRAM again, then that proves the damage isn't permanent, in cases where TASers used SRAM corruption for their TAS. If the same game with the same SRAM wouldn't boot on a real console, though, the run isn't legit.
Using external hardware or modifying the system is very different from merely making the game change the values in the SRAM already present in the system, which it does while playing normally anyway (via saving).
That may be so, but I just can't help feeling that it's a technique not related to the game, but abusing the hardware. After all, it's not the game which handles the reset button (AFAIK).
Or if I put that in another way: The "reset" button is not an input to the game. It's an input to the console itself (emulated in this case, but doesn't make much of a difference in principle). Thus it's a trick related to the hardware and not to the game. That's why I compared it to a game genie: You are affecting the game by abusing the hardware. That's not gameplay.
Lex wrote:
The fact that SRAM corruption is done only by pressing buttons on the console
It just bothers me that the reset button is the only button which does not supply input to the game, and thus bypasses the software and goes directly to the hardware. Again, a bit like a gamegenie device, in a way. I just can't shake this feeling that it's a bit like "cheating" (in the bad sense from TASing point of view).
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
Interestingly-enough, the SDA rule after the rule I posted above (which I totally missed), could very-well rule out SRAM corruption in SDA unassisted runs where the runner could have gotten ridiculously lucky and turned off his Game Boy right at the point he would have suddenly had 152 Pokémon. The rule doesn't mention resetting the system specifically, but it touches upon similar ideas:
Speed Demos Archive wrote:
Game modification: Removing or altering a game disc/cartridge/files while the game is running is forbidden. Examples of this are the crooked cartridge trick in The Legend of Zelda: Ocarina of Time and the CD streaming trick in The Legend of Zelda: Twilight Princess. If you're not sure what this rule means, think about it this way: don't mess with your system while playing the game, and don't modify the game itself at any time.
I'm not saying that a run that wouldn't be accepted on SDA shouldn't be accepted on TASvideos. This is tool-assisted speedrunning, after all. I'm just saying in principle, it's probably best to rule some things in the same way.
All that being said, the Pokémon Yellow SRAM corruption glitch run is extremely entertaining and totally possible on a real Game Boy with the right ridiculous luck (and I'm all about luck manipulation!), which makes me really want to keep SRAM corruption around as legitimate here.
All that being said, the Pokémon Yellow SRAM corruption glitch run is extremely entertaining and totally possible on a real Game Boy with the right ridiculous luck (and I'm all about luck manipulation!), which makes me really want to keep SRAM corruption around as legitimate here.
I fully agree with that, but I feel that if anything should go to the (yet to be fully realized) concept demos section of the site (as was the thing which originally inspired me to bump this thread), it should be those SRAM corruption runs, IMO. (If they are considered "legit" TASes to be published alongside everything else, then at least keep them as a separate and independent category.)
Using external hardware or modifying the system is very different from merely making the game change the values in the SRAM already present in the system, which it does while playing normally anyway (via saving).
That may be so, but I just can't help feeling that it's a technique not related to the game, but abusing the hardware. After all, it's not the game which handles the reset button (AFAIK).
Or if I put that in another way: The "reset" button is not an input to the game. It's an input to the console itself (emulated in this case, but doesn't make much of a difference in principle). Thus it's a trick related to the hardware and not to the game. That's why I compared it to a game genie: You are affecting the game by abusing the hardware. That's not gameplay.
Lex wrote:
The fact that SRAM corruption is done only by pressing buttons on the console
It just bothers me that the reset button is the only button which does not supply input to the game, and thus bypasses the software and goes directly to the hardware. Again, a bit like a gamegenie device, in a way. I just can't shake this feeling that it's a bit like "cheating" (in the bad sense from TASing point of view).
Good point. I now agree on that abusing power-cycle/reset (including some controller button press combinations for some consoles?) is abusing the hardware, but aren't detaching controllers, switching disk sides, opening CD-ROM drives, inserting coins and so on (ab)using the hardware as well?
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
but aren't detaching controllers, switching disk sides, opening CD-ROM drives, inserting coins and so on (ab)using the hardware as well?
I'd say that if abusing the hardware modifies the behavior of the game in a glitchy way, it goes to the gray area of whether it's "pure" and "legit" TASing or whether it's "cheating" (in the TAS sense). After all, we already forbid abusing emulator bugs, modifying the game's code by using the emulator RAM poking or by emulating a gamegenie or similar device, as well as using any kind of modified ROMs.
The reset button is recorded on the tas movies, so as long as it is an input on an accepted emulator then the possible code execution paths the movies can have include this button.
The programmers did a program for a specific hardware, and this abuses the hardware PLUS the programmers' logic. On the pokemon case, they didn't protect their game from turning off their target hardware while saving, newer pokemon games do have that protection.
SDA allows sram corruption now, or at least that's what I was told by their judge long ago.
That's not really a valid argument. If I added support for changing ROM and RAM addresses to a movie file format, would that make it automatically acceptable? Of course not. The movie file format supporting something doesn't tell anything about its validity.
As a case in point: Many movie recording file formats support storing savestates (afaik). That doesn't make starting a game from a savestate any more acceptable.
TASes should be about supplying input to the game (regardless of how it's done). Allowing the movie file to affect the console itself (eg. resetting it) is stepping a bit out of this boundary. That's not playing the game itself anymore.
so as long as it is an input on an accepted emulator then the possible code execution paths the movies can have include this button.
Resetting the console does not cause a new code execution path to be performed. Not in the game itself. It causes the (emulated) console to reset and start from scratch.
The programmers did a program for a specific hardware, and this abuses the hardware PLUS the programmers' logic. On the pokemon case, they didn't protect their game from turning off their target hardware while saving, newer pokemon games do have that protection.
You could use that same argument to allow gamegenie codes.
As stated, theoretically on a real console you could interrupt the saving cycle between any single instruction. There would be one more or less instruction executed every chip cycle (on the order of microseconds). As it is the emulator gives LESS precision than the console does, but surely the instructions are at least executed in the correct order.
I think it's safe to say that SRAM corruption runs would only be more ridiculous if the emulator (in an attempt to better emulate the console) allowed a reset in between every cycle. This can be seen in inichi's demo run. On gocha's debugger he was able to reset between any cycle. This changed the run from something like 20 minutes to something like 5 minutes.
I really don't think an SRAM corruption glitch run should typically obsolete a legitimate basic category for the run, and I don't think there is any need to be concerned about that happening.
Chrono Trigger is a notable exception because the old run was so outdated. I still think inichi's test run should have been published alongside the glitched run, but that was his decision upon not submitting it. Essentially a 2 and a half hour legitimate, well-played run exists, so why keep the 4 hour run on the site.
If it gets to the point where 1 in 3 games has an SRAM corruption run, the rules may need to change, but for now I don't see any problems with publishing them alongside current runs.
As it stands, Pokemon Yellow glitched is still one of my favorite runs on the site right now.
@Warp
* If the tasvideos staff was stupid enough to allow that version and not update their rules I guess. Reading I got the following idea: SRAM corruption is wrong because using inputs other than the standard controllers is wrong, in that case you don't ban SRAM corruption but all those other inputs, that's stupid, there are games that use those.
* It does, on the next power on :P If they detected it it follows the error correction path, if they didn't it follows an unexpected one.
* No, the programmers didn't create their game for the Game Genie, they did for the Super Nintendo, the game genie is an external device and I don't know of games that advertised support for it. They hopefully knew the Super Nintendo had these big three "buttons" on the console that were there to be pushed at whatever time the kids wanted.
TASes should be about supplying input to the game (regardless of how it's done). Allowing the movie file to affect the console itself (eg. resetting it) is stepping a bit out of this boundary. That's not playing the game itself anymore.
As I see it, the console and game are joined during play. You can't have one without the other or you can't play the game, so the developers should have taken the standard console inputs into account. And what about games that require you to push Reset, or change controller ports, or close the DS lid in order to finish? Do you want those to be unTASable?
put yourself in my rocketpack if that poochie is one outrageous dude
I think the point that this topic is trying to make (save-corruption may be not emulated correctly) is great. But the whole argument about recording resets doesn't equal to recording yourself playing the game is highly subjective. The reset button isn't on the controllers because the console needs only one in total. Pressing it does not equal to modifying the hardware or anything.
SRAM corruption is one thing, but SRAM corruption while saving and doing a Hard Reset is another thing. I don't really like the corrupted save file while saving.
Can we be sure that the reset button is how it is emulated ?
Anyway I would prefer having this kind of runs in their own category.
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
Interesting topic, I hadn't seen it before.
I share most of Warp's concerns regarding this matter. When you fiddle with hardware, you may be modifying the game.
The "the videogame and the game must be played together, therefore the videogame's features are valid" point doesn't feel valid to me. What about crooked cartridge tricks? How do they affect the game ROM in a console? If that could be perfectly emulated and manipulated, could you by astronomical chance tap a sonic cartridge while the genesis is on and end up playing streets of rage? or is that not possible?
The thing about this discussion is that it puts in perspective the concept of TASing. How far is manipulation acceptable. And I feel that manipulating the hardware is too much. Ok, you need to manipulate a gamepad to play the game, and that is hardware, but the game is prepared for that. Reset usually does not play a part in playing the game, as is the case with tapping the cartridge while the console is turned on.
There must be other ways to affect the hardware temporarily, like overclocking the cpu, I dunno, extreme temperatures, wrong voltage...
Also, I think that pressing left+right must go in the same cathegory as messing with the hardware. It's not a programming overlook because the console isn't physically supposed to allow for that button combination, so it's a bit of a "cheat". Maybe that's it, TASing is a battle of wits betweens the tasers and the game devs. There's a goal in the game, made by code, so manipulating hardware features other than the "intended ones" seem like cheating. What are those hardware features that the game devs intended to be part of the game is the central point, and I think it doesn't go farther than using the gamepad (except for some games?). Ok I'm going in circles :)
