Game objectives
- Emulator used: lsnes rr2-beta7 (works with rr1)
- Aims for fastest time
- Uses game-breaking glitches
- Heavy luck manipulation
- Achieves credits early
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.
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.
