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.


ALAKTORN
He/Him
Former player
Joined: 10/19/2009
Posts: 2527
Location: Italy
feos wrote:
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.
you’re missing the point that a TAS doesn’t amount to shit if it’s not actually possible for real pressing left+right can still be done on a real controller
Emulator Coder, Skilled player (1112)
Joined: 5/1/2010
Posts: 1217
zaphod77 wrote:
just need a bot wired to two multitaps to verify it, i would think. :)
Actually, no. This run apparently never switches controller pairs, so one can just behave like there was 4 independent controllers (and two of those can even give constant button pattern when polled).
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
This IS possible to replicate on a real SNES.
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.
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
NES has 8 buttons. NES PowerPad has 12. There are also the third party controllers advertised by Nintendo. If this doesn't prove one can make real buttons for these 4 bits, I don't know what does. Also, Ilari said multitap DOES give access to these 4 bits (and more than that). And SNES mouse accesses not just 16 bits, but even 32. The signaling protocol places no limits on length of packet.
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
Use the controller of your choice.
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.
ALAKTORN
He/Him
Former player
Joined: 10/19/2009
Posts: 2527
Location: Italy
Nach wrote:
Use the controller of your choice.
I agree with ais523, if the controller isn’t an official one then it’s as relevant as using a famiclone to do TASes but if there’s an official controller that allows for the run to be played on real hardware, that’s cool; I didn’t understand which was the case from your post
GhostSonic
He/Him
Joined: 3/14/2013
Posts: 61
zaphod77 wrote:
just need a bot wired to two multitaps to verify it, i would think. :)
It should be possible to verify without owning any multitaps, due to the way the multitap works and the fact that Super Mario World isn't actually programed to use it.
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
ALAKTORN wrote:
Nach wrote:
Use the controller of your choice.
I agree with ais523, if the controller isn’t an official one then it’s as relevant as using a famiclone to do TASes but if there’s an official controller that allows for the run to be played on real hardware, that’s cool; I didn’t understand which was the case from your post
I wonder how at all you can talk about console verification when none of the tools we feed the console input from was released by Nintendo.
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
ALAKTORN wrote:
but if there’s an official controller that allows for the run to be played on real hardware
How do you even define official controller? What about that for many people back in the day, they never used an "official" controller?
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.
ALAKTORN
He/Him
Former player
Joined: 10/19/2009
Posts: 2527
Location: Italy
Nach wrote:
ALAKTORN wrote:
but if there’s an official controller that allows for the run to be played on real hardware
How do you even define official controller?
an official controller is something Nintendo endorsed, there should be some kind of Nintendo seal of approval on said controller’s box, I’d imagine?
Nach wrote:
What about that for many people back in the day, they never used an "official" controller?
how is that relevant?
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
ALAKTORN wrote:
Nach wrote:
ALAKTORN wrote:
but if there’s an official controller that allows for the run to be played on real hardware
How do you even define official controller?
an official controller is something Nintendo endorsed, there should be some kind of Nintendo seal of approval on said controller’s box, I’d imagine?
Which almost all the third party controllers are.
ALAKTORN wrote:
Nach wrote:
What about that for many people back in the day, they never used an "official" controller?
how is that relevant?
If the standard way to play the game is with a non first party controller, then you can't fault the TASer for doing the same. If Masterjun wants to use this, he has my blessing:
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.
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
ALAKTORN wrote:
an official controller is something Nintendo endorsed, there should be some kind of Nintendo seal of approval on said controller’s box, I’d imagine?
Can't see any on this one. Guys, our movies are illegal. Only the SNESbot made by Nintendo can be used to verify SNES TASes, otherwise ALAKTORN won't agree. [03:48] <GhostSonic> I've already console verified a proof of concept that uses the extra 4 buttons if that's relevant at all
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.
ALAKTORN
He/Him
Former player
Joined: 10/19/2009
Posts: 2527
Location: Italy
Nach wrote:
ALAKTORN wrote:
Nach wrote:
ALAKTORN wrote:
but if there’s an official controller that allows for the run to be played on real hardware
How do you even define official controller?
an official controller is something Nintendo endorsed, there should be some kind of Nintendo seal of approval on said controller’s box, I’d imagine?
Which almost all the third party controllers are.
then I guess they are fine?
Nach wrote:
ALAKTORN wrote:
Nach wrote:
What about that for many people back in the day, they never used an "official" controller?
how is that relevant?
If the standard way to play the game is with a non first party controller, then you can't fault the TASer for doing the same.
I highly doubt that most people would use unofficial hardware as the standard way to play, and even then what’s official has more relevance than what people use
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
ALAKTORN wrote:
I highly doubt that most people would use unofficial hardware as the standard way to play
Then perhaps read this thread. Back in 1993, Nintendo even released a controller buyers guide, so players can find the controller that best suited them, or had novelty features. It was quite simple really, people wanted more players, wireless, a joystick instead of a pad, turbo buttons, or whatever, and they went out and got those devices. When I was young, everyone had an NES or SNES, out of all my friends, I can only recall one of them who didn't go out and get a non-official controller. I only used this for NES: Or this for SNES: And that was the norm. Later, the X-Band was also immensely popular, as it allowed selected games to magically become multiplayer online. Nintendo advertised it too, despite not being from them, and also had a contest to win some for free.
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.
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
<GhostSonic> any SNES controller that uses dual 4021s has the necessary pins to support the extra 4 buttons. Mario Paint actually checks for one of these extra buttons being pressed. The SNES mouse reports one of them being pressed while polling in order to indicate the mouse is plugged in.
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.
ALAKTORN
He/Him
Former player
Joined: 10/19/2009
Posts: 2527
Location: Italy
@Nach: well, you might be right on that, but that doesn’t change anything as I said in the phrase following the one you cited
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
ALAKTORN wrote:
@Nach: well, you might be right on that, but that doesn’t change anything as I said in the phrase following the one you cited
Well guess what, the SNES Mouse was official, and the mouse movements inputs way more bits than the standard pad does.
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.
ALAKTORN
He/Him
Former player
Joined: 10/19/2009
Posts: 2527
Location: Italy
Nach wrote:
ALAKTORN wrote:
@Nach: well, you might be right on that, but that doesn’t change anything as I said in the phrase following the one you cited
Well guess what, the SNES Mouse was official, and the mouse movements inputs way more bits than the standard pad does.
that is the question I have been making the whole time… why do you think I’m against the publication of this movie? all I wanted was clarification, if the mouse allows for the run to be playable on real hardware, that’s ok with me
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
ALAKTORN wrote:
Nach wrote:
ALAKTORN wrote:
@Nach: well, you might be right on that, but that doesn’t change anything as I said in the phrase following the one you cited
Well guess what, the SNES Mouse was official, and the mouse movements inputs way more bits than the standard pad does.
that is the question I have been making the whole time… why do you think I’m against the publication of this movie? all I wanted was clarification, if the mouse allows for the run to be playable on real hardware, that’s ok with me
I said a page ago this is possible on real hardware.
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.
ALAKTORN
He/Him
Former player
Joined: 10/19/2009
Posts: 2527
Location: Italy
Nach wrote:
ALAKTORN wrote:
Nach wrote:
ALAKTORN wrote:
@Nach: well, you might be right on that, but that doesn’t change anything as I said in the phrase following the one you cited
Well guess what, the SNES Mouse was official, and the mouse movements inputs way more bits than the standard pad does.
that is the question I have been making the whole time… why do you think I’m against the publication of this movie? all I wanted was clarification, if the mouse allows for the run to be playable on real hardware, that’s ok with me
I said a page ago this is possible on real hardware.
your definition of “possible” seemed to be different to mine, and now you’re actually making me wonder whether I understood right what you meant about the mouse…
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
ALAKTORN wrote:
Nach wrote:
Well guess what, the SNES Mouse was official, and the mouse movements inputs way more bits than the standard pad does.
that is the question I have been making the whole time… why do you think I’m against the publication of this movie? all I wanted was clarification, if the mouse allows for the run to be playable on real hardware, that’s ok with me
Tried reading the previous page?
feos wrote:
SNES mouse accesses not just 16 bits, but even 32. The signaling protocol places no limits on length of packet.
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
ALAKTORN wrote:
Nach wrote:
ALAKTORN wrote:
Nach wrote:
ALAKTORN wrote:
@Nach: well, you might be right on that, but that doesn’t change anything as I said in the phrase following the one you cited
Well guess what, the SNES Mouse was official, and the mouse movements inputs way more bits than the standard pad does.
that is the question I have been making the whole time… why do you think I’m against the publication of this movie? all I wanted was clarification, if the mouse allows for the run to be playable on real hardware, that’s ok with me
I said a page ago this is possible on real hardware.
your definition of “possible” seemed to be different to mine, and now you’re actually making me wonder whether I understood right what you meant about the mouse…
The mouse (a first party controller) when plugged in sets 4 bits on, each button when clicked sets a bit, and IIRC, the movement with the mouse sends some combination of 16 bits, depending on direction and speed. You could get any combination to output from that, but for an actual human to do it is impossible, as no one has that kind of precision in their wrist, and their brain to hand coordination. Now if you were to use a third party controller with lots of buttons, like the piano, or the phone, you could as a human press any combination you want, and you don't need expensive surgery either.
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.
ALAKTORN
He/Him
Former player
Joined: 10/19/2009
Posts: 2527
Location: Italy
thanks for the clarification, you don’t sound sure of the fact that the mouse can achieve it though… third-party controllers shouldn’t be taken into consideration
Emulator Coder
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
ALAKTORN wrote:
thanks for the clarification, you don’t sound sure of the fact that the mouse can achieve it though…
The mouse can if operated with extreme precision by a robot, but a human using the mouse can't. The part that I'm unsure about is the precise amount of bits set by each operation. It's been a decade since I worked on SNES mouse emulation code.
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.
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
12 buttons are present on regular SNES controller. This run ises 16. SNES mouse allows 32. What sounds more sure than that?
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.