(Link to video)

Game objectives

  • Emulator used: lsnes rr2-beta7 (works with rr1)
  • Aims for fastest time
  • Uses game-breaking glitches
  • Heavy luck manipulation
  • Achieves credits early

Comments

More than one year after the discovery of the credits glitch in yi2 this is finished. And here it is, finally, the new glitched Super Mario World TAS. This movie is different from the original run by antaasas in many ways. The only similarities are that we use the same game-breaking glitch and that we both jump to controller data so that we can execute from there.
A big difference between this run and the one by antaasas is that this one works on console, while his run was an emulator bug.
This run uses two multitaps in port 1 and port 2 which allows for 8 controllers (1-1, 1-2 ,1-3, 1-4, 2-1, 2-2, 2-3, 2-4) of which 4 are used (1-1, 1-2, 2-1, 2-2) for the last input.

The new version of the credits glitch

When stunning a flying ? block, it can spawn a sprite with the ID 0xFA. This ID is not an actual sprite and it is never used in SMW but since it spawned, the game has to run a code for that sprite. The game indexes the code location wrong and the code jumps to $0322. This is a place in the OAM table (OAM is a chunk of memory that stores the data about the sprite tiles to draw onto screen). That means that we can change values of the code being executed by changing the position of sprites.

OAM

This picture shows the OAM starting from $0320
The place we are accessing ($0322) is at the start of OAM for the sprites. The first 4 bytes are for sprite #A, the next 4 byte are for sprite #B and then every sprite from #0 - #9 has 5 * 4 bytes. Every block of 4 bytes has a format like this: x positon, y position, tile, property. The tile and properties of a sprite are almost impossible to manipulate so we have the x and y position left to use.

Problem #1 - Y Positions

Every frame, all y positions are reset to 0xF0 and they update from the top to the bottom, which means #9, #8, #7...#1, #0, #B, #A. That means when handling sprite #5, you already have the y position of #6 but not of #4.
"So then why not spawn the 0xFA sprite in slot #0 to have many positions already updated?" Because to spawn that sprite we need a shell which goes into slot #0 when taken to the underground in yi2.
"Then use slot #1!" This is what we do.

The glorious P-Switch

We want to manipulate the values to show the credits, right? So how do we do that? We could manipulate 11 bytes to be perfect, but that is very hard and might not even be possible. So let's just jump to the controller input data and execute from there. The input is at $4218 so we need a JMP $4218 which is 4C 18 42. Only x and y position aren't enough so we need a sprite which uses tile 0x42... P-SWITCH!
So let's just go to the end of the level and get the P-Switch and, oh wait...

Problem #2 - Slots

Every new sprite that spawns will use the highest slot that is free (#A and #B are reserved slots for special sprites like sprites from boxes). Since we want to be as close as possible to our start position ($0322), we have to get a small slot for the p-switch. So we need to fill the higher slots to get a small slot for our P-Switch.
Most sprites despawn when they go offscreen so we need better sprites. When you cancel-eat a berry it will turn into a sprite which won't despawn when going offscreen so that is what we do.
Now that we have the P-Switch in the right spot we just stun a flying ? block, but how do we that actually?

Stunning

To stun a sprite you have to have a sprite that Yoshi won't swallow (like a shell), another sprite which Yoshi can lick and a place to get hit (like a koopa). You also have to get a powerup to do the double-tongue glitch with Yoshi. Grab the first sprite with the first tongue, then lick the second tongue and quickly get hit by the third sprite, so that Yoshi cancel-eats the second sprite.

Problem #3 - We need sprites!

How do we get these sprites into the underground? Ok, we can use a throwblock as the second sprite, but how do we get the other two? We can bring a green shell into the underground when doublegrabbing the P-Switch and the shell while sitting on Yoshi (yes, this is possible). With the green shell we can spawn a naked koopa (stomping on the green shell and licking it at the same time, then quickly spitting it out), which then is our third sprite.
Now we need a powerup. We can use the midpoint to be big but we still need a mushroom for the reserve box. When you eat 10 red berries with Yoshi, he will give you a mushroom. Thanks Yoshi!
We can spawn an 1up by duplicating the vine block to the left. We use that to manipulate the x position and the tile so that we jump a bit forward in the code (to $034F, which is in the middle of #1 OAM, so we are almost at our P-Switch in #2). The code unfortunately jumps away just before we reach the P-Switch bytes, so we have to change the last few bytes of the slot #1 bytes.

Problem #4 - Bigger sprites!

Since most sprites (like the shells) are only 16x16 pixels big they only use one block of 4 bytes for their slot. Koopas are 16x32 pixels big, they use two blocks of 4 bytes, that is still not enough to reach the last blocks. So what are big sprites... Chucks! They use all 5 blocks.
There are not enough berries at the start to spawn the first chuck in slot #1 so it would be better to use the one later in the level, right?

Problem #5 - Pipes change slots

When you go into a pipe with an item, it will turn into slot #0. If you go into a pipe while doublegrabbing an item, the item with the lower slot will go into slot #0 and the higher one keeps its slot. Since we wanted the P-Switch in slot #2 we have to get the green shell into slot #1 or #0. The green shell appears early in the level so it would lose time to run forward filling sprite slots, then run back to get the shell and run forward again to get to the pipe. So we need another way to fill sprites early.
Yoshis won't despawn when they go offscreen so we create 5 Yoshis to fill slots #9 - #5, then we spawn the chuck in slot #1 to get better values, and then we spawn the green shell in slot #1.
Is everything working now? Not yet.

Problem #6 - Too many Yoshis

When there are multiple Yoshis on the screen, the egg with the mushroom will spawn at the Yoshi with the highest slot, which still is way back on the Yoshi block, so we have to... sacrifice 4 Yoshis to give Mario the mushroom he needs. When Mario gets hit while he sits on multiple Yoshis, he will only get off of one of them, so the next one will be moved under him.

Are we done?

Yes, we are done... with the setup:
spawn 5 Yoshis, spawn chuck in slot #1, spawn green shell in slot #1, get midpoint, change values with 1up, spawn pswitch in slot #2, sacrifice Yoshis, get mushroom, go into pipe with Yoshi, P-Switch and shell, stun flying ? block, fill slots so sprite 0xFA will spawn in slot #1 while having the pswitch in x position 0x4C and y position 0x18 (or 0x19).
We got the jump to the controller data, the rest is easy... in Snes9x!

Problem #7 - Too slow

We have 8 bytes controller data. To get to the credits we have to set the game mode($0100) to 0x18 and $13C6 to 0x08 and then return. That would be A9 18 8D 00 01 A9 08 8D C6 13 6B, that are 11 bytes, so we somehow have to make the game wait for the next input. There is this instruction WAI which WAits for an Interrupt. That interrupt will happen at the start of the next frame. The only problem is that this interrupt returns too fast, the SNES has not enough time to update the register for the buttons (in Snes9x there isn't this problem, that makes everything very easy), so when trying to execute them they have partially the values from the previous frame and a few from the current frame shifted wrong.
I managed to somewhat bring a routine into that garbage shifting. I have 3 bytes at the start, then I execute a WAI, after that I execute another WAI so it has enough time to update, then I branch back to the first 3 bytes, which also have new input.
However this is very unstable, I couldn't even do that routine one more time, the shifting was completely different suddenly and everything was failing, so I had luck that it worked.

Input

The last 4 frames of the movie was the input that was executed:
             1-1              1-2              1-3              1-4              2-1              2-2              2-3              2-4 
F. 0 0|B.s.u..r........|.YsSud.r.X.R0..3|................|................|BY..u.lr...R0...|BYsSu...A.......|................|................
F. 0 0|........A...01.3|.YsSud.r.X.R0..3|................|................|BY..u.lr.......3|BYsSu...A.......|................|................
F. 0 0|....u...A.L.0..3|.YsSud.r.X.R0..3|................|................|BY..u.lrAXL.0.2.|BYsSu...A.......|................|................
F. 0 0|BY...dl.A...01.3|.YsSud.r.X.R0..3|................|................|.Ys........R..23|BYsSu...A.......|................|................
B=B, Y=Y, s=select, S=start, u=up, d=down, l=left, r=right, A=A, X=X, L=L, R=R, 0,1,2,3=the 4 extra bits
Every controller has 2 bytes and they are stored in the registers $4218 - $421F.
$4218, $421A, $421C and $421E are the low bytes (AXLR0123) and $4219, $421B, $421D and $421F are the high bytes (BYsSudlr) of the controllers 1-1, 2-1, 1-2, 2-2 (respectively). So that $4218 has for example 0xFF if AXLR0123 are pressed or 0xEA if AXL.0.2. are pressed.
So let's convert the input into hex numbers, that would be for the first frame: 00 A9 18 CB 59 7D 80 F8. This movie jumps to $4219 so the first thing it does is LDA #$18 (A9 18). Then there is the WAI (CB) and the bytes are shifted wrong so that results turning 59 7D into EA CB which is NOP (do nothing) and WAI again. After WAIing twice the game had enough time to update the values so it executes BRA $F8 (80 F8) (from the second frame) which means it branches 8 bytes back to $4218 where the second input frame starts.
More information about why it fails the indexing and what the code executes from the input here.

Suggested Screenshots


feos: Nach didn't pick it yet? Judging!
Nach: A good way to ensure that is to submit when I'm away for ~26 hours, which is at least once a week.
feos: Accept and publish.

Joined: 4/3/2007
Posts: 29
yes! very nice work
Mitjitsu
He/Him
Banned User, Experienced player (531)
Joined: 4/24/2006
Posts: 2997
Its like you got a bot to brute force frames for a couple of minutes.
Glitcher
He/Him
Joined: 3/24/2007
Posts: 216
Location: London, U.K.
kaizoman666 wrote:
Glitcher wrote:
Any way of getting this run to work on good old Snes 9x?
Yep, masterjun already made a test run of the glitch on Snes9x.
Thanks. I didn't notice any sound glitch during the credits, though. Did I miss something? EDIT: Never mind, I noticed what's going on.
Active player (303)
Joined: 8/21/2012
Posts: 429
Location: France
This kinda looks like superhuman play... That's what happens when superhumans get drunk, plug 2 multitap for a single player game, and proceed to mash all these buttons until the game can't take it anymore. Yes vote :D
GhostSonic
He/Him
Joined: 3/14/2013
Posts: 61
jlun2 wrote:
Also, console verify this please. :D
I plan on trying this, I just don't actually have the stuff necessary to actually do four controllers at the moment.
Masterjun
He/Him
Site Developer, Skilled player (1968)
Joined: 10/12/2010
Posts: 1179
Location: Germany
I just want to add that executing controller registers has been verified on console with this unoptimized other method where it just executes a STP (stop processor) instruction and the result is perfect: The music doesn't freeze (it runs on another processor). The status bar disappears (the position isn't updated through IRQ anymore). The game doesn't crash! This movie also shows that a custom controller with 16 buttons can be created, since executing the STP requires extra button 0, 2 and 3. The only open questions are if multitap works, if it is emulated correctly and if the Auto-Joypad update has a correct timing (as I said in the submission text, it is very very unstable).
Warning: Might glitch to credits I will finish this ACE soon as possible (or will I?)
Joined: 6/22/2012
Posts: 81
Amazing TAS, but one question: Is possible use the same system to find the address value to execute the end title screen in other games of same console or games from another consoles like Super Metroid, Sonic....
Patashu
He/Him
Joined: 10/2/2005
Posts: 3999
Hikaruon wrote:
Amazing TAS, but one question: Is possible use the same system to find the address value to execute the end title screen in other games of same console or games from another consoles like Super Metroid, Sonic....
In theory, all it takes to jump to the credits of the game is writing the values into RAM that tell the game 'play the credits' or jumping to the instructions for the game directly that run the credits. In practice, to do this you need to find a memory corruption AND/OR 'data as code' execution related glitch. - either a very strong, general one, or one that you get lucky with and has a way to jump to credits. Examples from other games are: -Arbitrarily writing over RAM, and then jumping to the place in code you have written - the ideal case, arbitrary execution of any memory you want (Pokemon Yellow) -Mapping arbitrary RAM as level data, allowing you to interact with sprites/blocks that shouldn't exist and trick the game into ending the level (Wario Land 2) or going straight to the end sequence (Super Mario Land 2) -Scribbling a specific value over memory by going out of bounds, writing the fact that the final boss is dead to memory (Dawn of Sorrow) (also Ocarina of Time, but it can't be used to warp you, only to give you items and equipment) -Running 'code' for a non-existent sprite/weapon/behaviour/player state, executing data as code at the arbitrary addressed pointed to (Kirby's Adventure), and then jumping to controller input to execute MORE code from there (Super Mario World) (if Super Metroid had a credits early glitch it would probably look like this, using one of the glitched beams to execute data as code) -Trick the game into executing code for more objects than exist, such that it executes the code for the object 'end game' (Battletoads) or 'end level' (Mega Man) -Read arbitrary memory and interpret it as text of a conversation, glitchily reach the debug menu, then use that to reach the end of the game (Earthbound)
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
Joined: 12/19/2010
Posts: 126
easy YES vote from me
live life
Lil_Gecko
He/Him
Player (94)
Joined: 4/7/2011
Posts: 520
And another YES vote !
Joined: 2/20/2010
Posts: 209
Location: I'm in space
ha, only on tasvideos. whatever the hell that was, i vote yes on it.
Oh, play it cool. Play it cool. Here come the space cops.
Player (12)
Joined: 6/17/2006
Posts: 498
I re-read the submission notes and now I understand most of it. That's some crazy and interesting stuff!
Masterjun wrote:
The music doesn't freeze (it runs on another processor).
There's a SFX stuck in a loop though. Personally I don't care but apparently some do.
Masterjun wrote:
This movie also shows that a custom controller with 16 buttons can be created, since executing the STP requires extra button 0, 2 and 3.
Masterjun, you always impress me in how you always push the boundaries of possibilities. I mean, we're going to need custom controllers that have useless buttons to make speedruns now? What's next, reading data from the EXT port? :)
Joined: 1/17/2008
Posts: 133
Voted yes because fish don't appear out of thin air this time, having been replaced with Yoshis.
Joined: 7/29/2009
Posts: 55
How can this be acceptable, if it uses non-existent buttons? Even a perfect player could not make buttons appear out of thin air.
GhostSonic
He/Him
Joined: 3/14/2013
Posts: 61
Potato Stomper wrote:
How can this be acceptable, if it uses non-existent buttons? Even a perfect player could not make buttons appear out of thin air.
You could potentially mod or create another controller that has these buttons. This demonstration Masterjun linked to uses these "non-existent" buttons, so it's not out of the question by any means.
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
Potato Stomper wrote:
How can this be acceptable, if it uses non-existent buttons? Even a perfect player could not make buttons appear out of thin air.
A perfect player has all SNES inputs and outputs wired into the skull anyway so in the end it's not much of a difference.
Skilled player (1703)
Joined: 9/17/2009
Posts: 4952
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
Finally managed to watch this. This makes it looks as if the TAS was trying to be a superplay before it suddenly realized that it's supposed to be a speedrun, and threw the credits at us. 0_o
BigBoct
He/Him
Editor
Joined: 8/9/2007
Posts: 1692
Location: Tiffin/Republic, OH
They exist, therefore they can be exploited.
Previous Name: boct1584
Joined: 7/29/2009
Posts: 55
GhostSonic wrote:
You could potentially mod or create another controller that has these buttons. This demonstration Masterjun linked to uses these "non-existent" buttons, so it's not out of the question by any means.
Yeah, but modding the controller is hardware modification (as the name implies). Is cartridge tilting going to be acceptable too, if it's emulated correctly? How much of a difference do these 0-3 buttons make anyway? Is the run fundamentally different without them or would it be just a bit slower setup?
Skilled player (1703)
Joined: 9/17/2009
Posts: 4952
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
Potato Stomper wrote:
GhostSonic wrote:
You could potentially mod or create another controller that has these buttons. This demonstration Masterjun linked to uses these "non-existent" buttons, so it's not out of the question by any means.
Yeah, but modding the controller is hardware modification (as the name implies). Is cartridge tilting going to be acceptable too, if it's emulated correctly? How much of a difference do these 0-3 buttons make anyway? Is the run fundamentally different without them or would it be just a bit slower setup?
Why are we using this thread to discuss some trick that isn't even in this run? This run doesn't use those extra buttons; it uses the multitap instead.
Emulator Coder, Skilled player (1140)
Joined: 5/1/2010
Posts: 1217
Potato Stomper wrote:
Yeah, but modding the controller is hardware modification (as the name implies).
Left+Right is not possible on pristine controller either (or at least shouldn't be). Note that unmodified console when asked to do hardware polling does read 16 buttons per line (for grand total of 64), not 12 per line. And controllers can't do DMA or anything blatantly unsafe, so modified controller can't be used to trivially hijack execution.
Potato Stomper wrote:
How much of a difference do these 0-3 buttons make anyway? Is the run fundamentally different without them or would it be just a bit slower setup?
It doesn't matter in setup time, but it would render the exploit much much harder (if possible at all).
Post subject: Movie published
TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 14773
Location: 127.0.0.1
This movie has been published. The posts before this message apply to the submission, and posts after this message apply to the published movie. ---- [2380] SNES Super Mario World "game end glitch" by Masterjun in 01:39.74
ALAKTORN
He/Him
Player (99)
Joined: 10/19/2009
Posts: 2527
Location: Italy
why did this get accepted so quickly? shouldn’t we discuss whether it’s a legitimate way of beating the game? accepting a run that uses inputs impossible to replicate on real hardware sounds ridiculous to me…
Site Admin, Skilled player (1234)
Joined: 4/17/2010
Posts: 11251
Location: RU
The 4 extra bits used for each controller bus in this run are not present on an actual controller, but they are present inside it. Input for them is polled each frame and they are by default read as "released". You can send the "pressed" signal for them. But they ARE a part of SNES input. Let's say you need to stick a needle somewhere to make them pressed. I don't see any problem here, it's pretty similar to pressing the opposite directions at once or pressing a button at 30Hz. On a real hardware we'd use a direct access to these bits and send all the necessary input via the SNESbot device, since the real controller is not used.
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.
Joined: 1/13/2007
Posts: 334
just need a bot wired to two multitaps to verify it, i would think. :)