Aims for the goal of completing the process of reaching the THE END of a completed game which reached the state of the finished goal of winning in the game... as fast as possible!
It also uses a bunch of controllers to complete the goal of finishi-
It's also faster than the current run by 4 frames
Credit to p4plus2 for finding the mysterious thing that makes this possible
Suggested comments
How to play back the file on a normal lsnes rr2 version
For your convenience (and probably mine because I don't have the version either), I made a fancy Lua script to run which makes the run play back correctly! In fact, it's also already in the movie file itself so you can also simply extract the script.
It also only needs to run on the last frame of input (after that you can use Reset Lua VM to remove all remaining callbacks) so it doesn't make the run any longer.
What do you mean you want an explanation for the mysterious thing
Okay, okay, it's the expansion port on the SNES! (see picture below) (credit to p4plus2 for thinking of this)
Turns out the expansion port registers are found on addresses $2184-$21FF which makes them very similar to controller regsiters (adresses $4218-$421F).
The differences are quite important though.
One is pretty obvious: Instead of 8 arbitrary bytes with the controllers, we have 124 arbitrary bytes with the expansion port.
The other one is just as useful though: In practice (as in, on actual hardware), all 124 bytes can be changed at the speed of the SNES CPU. This means in theory you could set all 124 bytes to 0xA9 and start executing them. Then right after the CPU fetched the first byte you can change all 124 bytes to hold, say, 0x96. The resulting first instruction would be A9 96 (LDA #$96).
Since the value can change every fetch of the byte, p4plus2 found the easy method to emulate it by just writing a byte buffer for all the bytes returned to the CPU as soon as it requires them. This is the expansionportdata file you see inside the movie file, even though it's useless since it isn't read by the normal emulator.
In this movie a jump to the expansion port is used to write a program into memory (all in the last frame, so that it doesn't make the movie longer). This program then runs until it finally jumps to the credits.
Now a few words from an Aidful Individual who learned to write submission texts
I die jump with platform, Select is trologed. For my have to be have along the Super Mario's cut prized.
He Pokemon.
This is prevented for the battle, they. Hat have set that good scroll and a Mario quickly reason.
But TAS work.
Suggested screenshot
(whaaat !? it's not an actual screenshot from the movie !?)
Fog: Dropping this one, this run seems much more suited for Nach.
Nach: The console's controller ports are a normal way for players to enter input. Many different kinds of devices were made to use the controller ports, and Nintendo recommended third parties make their own controllers, and they did, and received Nintendo approval. All those making SNES games should be aware that controller input can be anything. Some games taking this into account issue an error message upon load if using a controller input they did not want to support. This makes using any controller input via the controller port "fair game" to use in a TAS.
The expansion port was designed to create add-on hardware for the SNES, similar to how the Sega Genesis has various CD addons and potentially other kinds of interesting things that may add additional capabilities to the SNES. Games are not expected to make use of the expansion port unless designed specifically for a particular add-on. The expansion port is not intended to be used to create controllers, nor was anything of the kind ever released for it. Using the expansion port in this way for player input is not considered a legitimate way to play Super Mario World. Rejecting, with prejudice.
Joined: 4/7/2015
Posts: 331
Location: Porto Alegre, RS, Brazil
In the suggested screenshot it's not even a Snes, it's a Switch, so unfortunately I have to vote yes.
¯\_( ՞ ᗜ ՞)_/¯
Games are basically math with a visual representation of this math, that's why I make the scripts, to re-see games as math.
My things:
YouTube, GitHub, Pastebin, Twitter
I'm surprised this is the first real use of the extension port for a TAS. Pretty cool! This should be integrated into the emulator so Lua scripts aren't required, with an option to switch between arbitrary input and the Satellaview.
Masterjun wrote:
In this movie a jump to the expansion port is used to write a program into memory (all in the last frame, so that it doesn't make the movie longer).
Isn't this true only if the last controller input is read after the last extension port input? A more precise timing method may be required here since we're dealing with sub-frame inputs.
I'm against this for the same reason I'm against using preinitialized memory: it removes the bandwidth bottleneck of giving instructions to the console. (Yes, I know I invented the DPCM glitch, but that involves tricking the console into polling the controller faster, not basically attaching an external memory card which contains your exploit.) In a sense, a speedrun is about completing the game as economically as possible. By removing the need to optimise the input, you're removing a major part of what makes speedrunning interesting. (More minor but still making things less interesting to me: it also makes the payload simpler.)
I don't outright think this is cheating, but I think it's a different category from glitched-any% or any%-ACE, and also a less interesting one; and I'd recommend rejecting it on the basis that it isn't different enough from the glitched-any% for both categories to be worth having on the site.
Moderator, Senior Ambassador, Experienced player
(908)
Joined: 9/14/2008
Posts: 1014
This was a lot of fun - I was quite surprised by the ending. I would love to be able to console verify this and I have every belief that if I had all the right hardware that it would succeed. The only reasonable case to reject this run is that it does not use pure controller input but I think this limitation is unwise in this case as the expansion port is a valid port exposed to the end user. Therefore, this gets a Yes vote from me.
I've made my case repeatedly and I will continue to state that we need to stop being afraid of having multiple branches and we need to accept this *without* obsoleting any previous run. For this scenario, because this is in a fun gray area between just a game-end glitch and an ACE and it includes unique content that makes it stand out as a work of art on its own merit I believe it should be submitted as its own branch, separate from existing runs. That is all.
Great work, Masterjun!
The only reasonable case to reject this run is that it does not use pure controller input but I think this limitation is unwise in this case as the expansion port is a valid port exposed to the end user. Therefore, this gets a Yes vote from me.
Disclaimer: I don't necessarily disagree, but I would like to play Devil's Advocate for a short period of time, because I think this is worth fleshing out.
The major difference between the two types of ports is that controllers are designed to be used by a human, whereas the expansion port is designed to be used by a piece of hardware.
From the perspective of the SNES, user input is user input, and there's very little distinction. But from the perspective of a human player, one is an input they can use, and the other requires specialized hardware.
While we are not ruled by the standards set by the speedrunning community, there is significant overlap between the communities of authors and viewers, and we do take cues back and forth. Most speed records disallow the usage of custom hardware. This rule was adopted to prevent usage of autofire and other controller features, but custom hardware to insert a ACE payload would be similar if not more egregious.
Personally, I like to think of a TAS as sort of an ideal. If I were infinitely good at a video game, and I sat down, how fast could I play it? Movies like this challenge this idea, because no matter how good I am, I don't have a method of interacting normally with the expansion port. Again, I'm fence sitting, and I don't have a strong opinion either way. But this, at least for me, brings up the questions of what a TAS is, and what a TAS should be, and I think that these questions should at least be explored.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
Devil's advocate to the devil's advocate: If we ban the expansion port because it uses custom hardware/is impossible by a human player, shouldn't we also ban L+R* and 30Hz mashing, which are also impossible by a human player without custom hardware or controller modification?
*I've seen a few speedruns that rely upon a human hitting L+R, most notably a category in Yoshi's Island. I'm not sure how this is done, but it seems to be difficult.
EDIT: Like this. https://www.youtube.com/watch?v=6uV3RGBe5vo
Or like this. https://www.youtube.com/watch?v=jj6w_CIpYSg
So then the question is, why do sites like speedrun.com ban L+R? The rationale seems to be that you need a broken or modified controller to do L+R. I don't know any further than this.
Still, even if you allow L+R to be done by a human, 30Hz done by a human is definitely impossible. (Human mashing speed can't exceed 20Hz.)
Still, even if you allow L+R to be done by a human, 30Hz done by a human is definitely impossible. (Human mashing speed can't exceed 20Hz.)
I'm pretty sure it's impossible for the hardware as well: at some point any joypad would break.
I remember I had an intense play on a PC game (can't remember which) in which I mashed the mouse left click a lot, and then it started malfunctioning. Same happened for my usb joypad after some plays on Metal Slug X in which I confronted the trains from level 5 with pistol.
Edit: think about it again, I didn't noticed any problem with GBA SP or original PSX joypad even after the most fierce plays. Then I guess it is possible on most consoles to do full plays featuring 30Hz mashing and not getting noticeable damages to the buttons.
Support Permission.
Do not support obsoletion: it is technically less impressive; having a convenient canal (Which will be there for all games!) is less interesting than finagling increasing-throughput bootloaders
I am curious what sort of extra video throughput would be possible if you were doing the AGDQ-ish thing but with the expansion port.
I'll note that the NES and N64 have expansion ports. The NES's is, however, anemic and has no memory mapping unless the cartridge provides it (lacking address lines, but having EXP lines that go to cart); as cartridge-fiddling is verboten, it's of minimal use, other than doing the same things that controller ports do in exactly the same handful of bits of read memory. I don't know how the N64's is hooked up.
Short argument: It's a Tool.
Medium argument: it does not modify the game nor video-edit the results.
Long argument:
If we're going by precedent (which this site only weakly follows)
Turbo: allowed
Hyperturbo: allowed (SMB3 ACE)
16-button controller: sort-of-allowed (JXQ's SM100%?)
L+R/U+D: allowed
Hyperextension of analog stick beyond its bracket to maximum binary output: allowed
Game Genie: Disallowed, "modifies the game"
cartridge tilting: disallowed
Basically, anything that's fed into the controller port has been allowed, and anything that disrupts connectivity between game data and console is disallowed.
And yeah, a port exposed to the user that is not intercepting and altering game data.
ETA: when did [no] L+R/U+D get rolled into "forgoes time-saving glitches" rather than its own movie-tag?
ETA2: weak yes.
The reason left+right is banned on most speedrunning sites is not that it's impossible, but that doing it tends to cause physical damage to the controller (making it break eventually). It's unfair to make someone keep buying new controllers to be able to speedrun.
Yes, the extension port was never designed for human input, but it was still designed for input. In my opinion, the only reason it would make sense to ban such input, or at least some bits of it, would be if it would disrupt normal system operations regardless of the game. As far as I know, this is not the case here.
ais523 wrote:
I don't outright think this is cheating, but I think it's a different category from glitched-any% or any%-ACE, and also a less interesting one; and I'd recommend rejecting it on the basis that it isn't different enough from the glitched-any% for both categories to be worth having on the site.
If you're willing to accept this strategy would make sense as a separate category, then it doesn't make sense to also argue about rejecting a faster submission on the basis of it being too similar to the current submission.
The reason left+right is banned on most speedrunning sites is not that it's impossible, but that doing it tends to cause physical damage to the controller (making it break eventually). It's unfair to make someone keep buying new controllers to be able to speedrun.
I never heard this reasoning before. And it's so pragmatic too!
Do you know if this reasoning is listed anywhere on, for example, a www.speedrun.com page?
