I'll post here what we know about the "credits glitch" discovered by あんた (anta).
What is the credits glitch?
In short, the credits glitch is a way for us to jump straight to the credits of Super Mario World very early on in the game, from Yoshi's Island 3. I've spoken with DarkKobold and he said it would be considered beating the game. It would probably also be separate category (glitched any%).
In a slightly more technical way, it's a way for us to write a value of #$1C to $7E:0100. This RAM address happens to be the game mode, and a value of #$1C will trick the game into running the final cutscene (the credits).
Don't get too excited though. The chances of it happening are something such as 1 in 1,000,000,000, or something ridiculous like this. So I'll continue to explain how to perform it and try to be not so technical.
How to perform?
As you may or may not know, when Yoshi holds a null sprite in his mouth, it has a slot value of 255 (#$FF). The sprite table is 12 bytes. So, as you can imagine, the properties of the null sprite get written elsewhere. For more information on this bug and how to perform it, please see
Mister's post. I will not describe it here.
So in short, when spitting out a sprite, it'll usually store to $7E00E4 + id. When the id is #$FF, it will store to a different address. When we stand on a brown platform, Mario's (and Yoshi's) image is obscured completely, and a new one is drawn instead. This writes values to the stack. Thus, an unusual program can be executed if we write 255 values to the stack too!
All of this below is the code set up to make this bug work. The values must fall into place perfectly, otherwise we'll get a crash, another strange effect or nothing.
Language: ASM
01f1fc lda $e4,x [0000e8] A:f177 X:0004 Y:0001 S:01e0 D:0000 DB:01 nVMXdizC V: 80
01f1fe clc A:f186 X:0004 Y:0001 S:01e0 D:0000 DB:01 NVMXdizC V: 80
01f1ff adc $f305,y [01f306] A:f186 X:0004 Y:0001 S:01e0 D:0000 DB:01 NVMXdizc V: 80
01f202 ply A:f176 X:0004 Y:0001 S:01e0 D:0000 DB:01 nVMXdizC V: 80
01f203 sta $00e4,y [0101e3] A:f176 X:0004 Y:00ff S:01e1 D:0000 DB:01 NVMXdizC V: 80
This is the first part of our executed code. I wouldn't worry too much about it; it just jumps to another piece of executed code.
Language: ASM
01ee77 ror $49,x [00004d] A:f100 X:0004 Y:00ff S:01e4 D:0000 DB:01 nvMXdiZC V: 81
01ee79 ora ($9d,x) [01355a] A:f100 X:0004 Y:00ff S:01e4 D:0000 DB:01 NvMXdizC V: 81
01ee7b jmp ($ad15,x) [01ad19] A:f135 X:0004 Y:00ff S:01e4 D:0000 DB:01 nvMXdizC V: 81
This is the second part. The first byte is the low byte of the random number generator and the second byte is the result of the random number generator. Thus, for this code to work, the RNG must be 92 F7.
Language: ASM
01148c jmp ($f792,x) [01f796] A:f135 X:0004 Y:00ff S:01e4 D:0000 DB:01 nvMXdizC V: 81
This code is executed in RAM, in the OAM mirrors. (From SMWiki: OAM is a chunk of memory in the PPU that stores the data about the sprite tiles to draw onto screen. It contains 128 "sprite slots", each slot requiring 4 bytes in the main table and two additional bits stored separately in a smaller table towards the end of the OAM.)
So for this bug to occur we must find out what the OAM values are and manipulate them accordingly. Below is how the code should align:
Language: ASM
010302 8E 28 81 stx $8128 [018128] A:f135 X:0004 Y:00ff S:01e4 D:0000 DB:01 nvMXdizC V: 81
010305 39 06 2A and $2a06,y [012b05] A:f135 X:0004 Y:00ff S:01e4 D:0000 DB:01 nvMXdizC V: 81
010308 B0 FA bcs $02fa [0102fa] A:f120 X:0004 Y:00ff S:01e4 D:0000 DB:01 nvMXdizC V: 81
0102fa 66 A0 ror $a0 [0000a0] A:f120 X:0004 Y:00ff S:01e4 D:0000 DB:01 nvMXdizC V: 81
0102fc A3 F0 lda $f0,s [0002d4] A:f120 X:0004 Y:00ff S:01e4 D:0000 DB:01 NvMXdizC V: 81 <-- Loads the "new game mode"
0102fe 66 20 ror $20 [000020] A:f11c X:0004 Y:00ff S:01e4 D:0000 DB:01 nvMXdizC V: 81
010300 8F F0 8E 28 sta $288ef0 [288ef0] A:f11c X:0004 Y:00ff S:01e4 D:0000 DB:01 NvMXdizc V: 81
010304 81 39 sta ($39,x) [010100] A:f11c X:0004 Y:00ff S:01e4 D:0000 DB:01 NvMXdizc V: 81 <-- Stores the "new game mode"
010306 06 2A asl $2a [00002a] A:f11c X:0004 Y:00ff S:01e4 D:0000 DB:01 NvMXdizc V: 81
010308 B0 FA bcs $02fa [0102fa] A:f11c X:0004 Y:00ff S:01e4 D:0000 DB:01 nvMXdiZc V: 81
01030a 04 60 tsb $60 [000060] A:f11c X:0004 Y:00ff S:01e4 D:0000 DB:01 nvMXdiZc V: 81
01030c 60 rts A:f11c X:0004 Y:00ff S:01e4 D:0000 DB:01 nvMXdiZc V: 81
So starting from $7E02FA, OAM should look like this:
66 A0 A3 F0 66 20 8F F0 8E 28 81 39 06 2A B0 FA 04 60 60
++ -- ** ** ++ -- ++ -- ++ -- ** ** ++ -- ** ** ++ -- **
** = required
++ = semi-required; the hex value must be the same opcode length as the given example.
Another OAM value we have to pay attention to that was previously overlooked is a lone value at $7E:02D4. This OAM value is the one which actually writes to the Game Mode, thus the following values are required:
#$1C: For the Yoshis "Thank You!" screen
#$20: Shows the enemies cutscene
#$26: Shows the "The End" screen
The others are not required, provided they don't change the Accumulator when the game mode is changed.
The only other thing we have to take into account is Yoshi's X Position and direction. It should be #$86 when facing left. When facing right it must be #$66.
Shut up and let me see it!
Okay.
The original movie by antaasas. This version jumps to the Yoshi "Thank You" screen. There is also an
encode here.
Masterjun's test movie, which jumps to the "THE END" screen instead.
The first thing you'll notice is that the players are performing what may seem to be an arbitrary set of actions, such as recycling fish. Well, it's all relevant.
When fish bounce, they call the Random Number Generator subroutine three times. Thus with many fish bouncing we can get to the desired RNG number quickly. However, during their INIT routine, koopas call it once. So we need to plan our RNG values accordingly. In addition, the monty moles which follow Mario call the subroutine once per frame; unfortunately, there are none in yi3 and the value gets reset on OW/level load.
p4plus2 is currently working on a C++ program that replicates the SMW RNG routine exactly so we can work out the miminum number of changes required.
Any other actions you see within the movie, such as cape-sliding or screen-scrolling seem to be required actions to manipulate the OAM.
Useful Links
Anta's documentation (Japanese).
p4plus2's documentation, from which most of this post is written according to.
SMWCentral RAM Map
Please, if you notice any mistakes in my writing, point it out to me on IRC or PM or something. I also urge anyone to help us if we've missed something important. I'm not very knowledgeable in the field of Assembly so I probably did get something wrong; most of this post is due to p4plus2/Smallhacker.
