Since this article is being written about a year and a half after I finished making this TAS, it may contain ambiguous expressions. Also, the author is a novice in TAS and may have written some incorrect things. Please forgive me.
Table of contents
What Is "unintended exits"?
Even though SMW has so many interesting glitches, only a few of them are available for speed runs, which is very unfortunate. So, I have devised a regulation to make the most of the interesting glitches inherent in SMW and make it work as a speed run (not an official regulation).
The rule is: “Complete the game without any game strategies intended by the game developer.”
In other words, you are not allowed to use the goal tape sprites that have already been intentionally placed to clear the course or defeat bosses, including Bowser, in order to advance.
In other words, you are not allowed to use the goal tape sprites that have already been intentionally placed to clear the course or defeat bosses, including Bowser, in order to advance.
I didn't want to use ACE at all, but it would have been a little boring without “ACE can only be used when recovering from a crash”.
So far, the rules are vague...
So far, the rules are vague...
Game Objectives
- Emulator used :BizHawk 2.6.1
- Rules... Clear the game by prohibiting any game strategy intended by the game developer /ACE can only be used when recovering from a crash
- Clear as soon as possible
- Packing a variety of glitches to the max
- Make it interesting TAS
- Allow L+R / U+D
I used two controllers (the ACE part) because I wasn't sure how to use the 8 controllers of the multitap in BizHawk. (If anyone knows more about this, please let me know...)
Pathway Overview
Indentation is the level used for setup
- YI2(1)...Reznor-kill
- YI3...wings
- YI4...Reznor-kill
- YI1...get an ORB in item reserve and die (not ACE)
- C#1...use the ORB
- DP1(1)...goal tape modification (secret exit)
- YI2(2)...get a key in item reserve (ACE)
- DS1...use stun glitch to spawn a keyhole and use the key (secret exit)
- DP1(2)...get ORB and cape (ACE)
- DSH...get flower and use the ORB
- DS2...Reznor-kill
- DP3...gray platform glitch (credits)
Why not via DGH?

Details Of Each Level
The configuration is as follows
- n) number of the corresponding frame
- description around n to n+1
- Subscripts match the subscripts in the image.
- n+1)...
YI2(1)

- 0)1634
- slot number adjustment by juggling shells
- 1)2149
- Duplicate the item box to produce three Yoshi’s.
- 2)2335
- Yoshi#5...store#2(avoid becoming invisible when the tongue is at its minimum length because you will not be able to eat-cancel with 8)
- Yoshi#4...(slot number adjustment)
- Yoshi#3...(lose interaction with the object by using null sprite overload later)
- 3)2483
- Carry shell#1.
- Eat ten berries.
- Take the checkpoint and get bigger.
- 4)3511
- Over 2f feet, yoshi#5 (the highest slot) gives birth off screen.
- Take advantage of freeze and do double tongue glitch.
- 5)3580
- null sprite overload→ object interaction of yoshi#3 disappears.
- 6)3858
- Do stun glitch with P-switch.
- Set a stun timer on the fish using the bounce block above.
- Yoshi#3...Despawn him by swallowing the shell. (Whether or not Yoshi is stuffing his mouth with food is succeeded by the next visible Yoshi.)
- 7)3893
- Yoshi#4...He's just for slot number adjustment, so despawn him.
- 8)3920
- Yoshi#5...Finish setup with eat-cancel.
- 9)4140
- set up of stun glitch
- 10)4323
- kill Reznor
YI3
See warpsTAS by bruno visnadi.
Due to lack of ability, I was not able to fully imitate his methods. There is room for improvement. I did not know this when I created this, but there seems to be a frame rule that when duplicating a block, only the left side succeeds on even frames and the right side on odd frames (kaizoman told me this).
Due to lack of ability, I was not able to fully imitate his methods. There is room for improvement. I did not know this when I created this, but there seems to be a frame rule that when duplicating a block, only the left side succeeds on even frames and the right side on odd frames (kaizoman told me this).
YI4
YI1
C#1
DP1(1)

- 0)13763
- Get two feathers.
- Carry Shell#5.
- Scroll right to adjust the position of the blue shell-less koopa.
- 1)15015
(Change tweakers of #1 and #3 using null sprite overload later.)
- Yoshi#3...store #8 (Drop without despawning under the ground later.)
- Yoshi#2...(slot number adjustment)
- Yoshi#1...(Finally, despawn at the edge of the screen, the role of the trigger.)
- 2)15159
- To do double tongue glitch, take the damage and release the item in the reserve.
- 3)15209
- If Yoshi#2 is there, you can't do 7, so run him left, drop him in the hole, and despawn him.
- 4)15327
- Do double tongue glitch.
- 5)15385
- null sprite overload
- 6)15516
- Get off Yoshi#1 and #3 at the maximum speed of 49
- Yoshi#3(invisible) slips through the object and is projected horizontally to the right with speed 49
- Eat shell-less koopa (slot number adjustment)
- 7)15859
- Place Yoshi#1 on the left edge of the screen just before the despawn zone and the goal tape on the right edge of the screen just before the spawn zone.
- Wait until Yoshi#3's tongue is directly below Mario.
- 8)15930
- Go right to despawn Yoshi#1.
- Yoshi#3 becomes visible and 3f later, goal tape#8 spawns and be eat-canceled at the same time Yoshi#3 despawns.
- The coordinates of the goal tape are modified to make it a secret exit.
- Mario is jumping because the hit box of the tape appears slightly above the ground.
YI2(2)
If you eat Chuck (chargin') with Yoshi when he is a feather Mario, you will get the key in item reserve with a crash.
See BRK-method for recovery from crash.
See BRK-method for recovery from crash.
DS1

- 0)19872
- Use Yoshi to climb up the wall.
- 1)20714
- Fill empty slots with 1up (the goal is to put 1up in #1)
- 2)21023
- Put flower in #a and #b.
- Store #10 with tongue.
- Flip 1up with a feather. (to avoid despawning at the bottom of the screen)
- 3)21024
- release the item in reserve (Spawn in #a as slots are filled.) (At this point, the tweaker bugs out.)
- Yoshi spits it out and resets the sprite.
- 4)21107
- double tongue glitch
- 5)21353
- null sprite overload (The key is just thrown forward.)
- Recover unwanted 1ups. (to prevent processing failure)
- 6)21358
- Spawn two invisible shells.
- 7)21459
- double tongue glitch
- 8)21623
- set up of stun glitch
- 9)21684
- double tongue glitch
- 10)21728
- set up of stun glitch
- 11)22204
- Dino Rhino spawns
- 12)22261
- keyhole spawns
DP1(2)

- 0)22950
- Get two mushrooms and release them. (Beware of 6)
- 1)23957
- It is slightly faster to clip the corner.
- Despawn Yoshi#9 with tongue sticking out to complete the setup.
- 2)24138
- The mushroom was released to put Yoshi in #8
- 3)24251
- Yoshi#8...store#2
- Yoshi#4...store#7
- Yoshi#3...visible
- 4)24332
- Yoshi#8 stores #2
- 5)24396
- Yoshi#4 stores #7
- 6)24644
- get bull in stock (ACE)
- jml [$00e0] = jml $019ecd...So, for the y-coordinate in this frame,
- $e0 == cd (yoshi#8)
- $e1 == 9e (mushroom#9)
- $e2 == 01 (mushroom#A)
- Adjust the y-coordinate of the mushroom to get these values.
- In addition, the following conditions must be met
- $1a == dc (Layer 1 X position)
- $1c == 9c (Layer 1 Y position)
- (stun timer of chuck#7) < #$18
- 7)24963
- Spawn a feather in #2 to take after this.
- 8)25084
- Eat Chuck (clappin') in reserve using Item swap and get ORB. (Mario must be state of flower)
- 9)25165
- Crushed to death and yoshi#8 eats the feather from earlier and resurrects. (Wanted to take the feathers while holding item in reserve.)
- Ride Yoshi#8 and go out of the course.
DSH
Get flower and use the ORB
DS2

- 0)27584
- scroll left
- 1)27831
- Duplicate green shell.
- 2)27869
- Get the coin. (slot number adjustment)
- 3)27957
- shell-less koopa...(slot number adjustment)
- glowing vine...(slot number adjustment)
- 4)28166
- Get the coin. (slot number adjustment)
- 5)28221
- Scroll left to drop the shell-less koopa at the desired location.
- 6)28256
- Release the flower in reserve in the middle of the scroll.
- 7)28381
- Throw the shell toward the item box.
- 8)28413
- double tongue glitch
- 9)28430
- Spawn directional coins#4 before the growing vine despawns.
- 10)28444
- set up of stun glitch
- 11)28555
- double tongue glitch
- 12)28573
- set up of stun glitch
- 13)28694
- double tongue glitch
- 14)28725
- set up of stun glitch
- 15)28940
- kill Reznor
- The condition to kill Reznor at this time is (sum of 4 bytes from $1520) == #$4, (x = 4, 5, 6, 7)
- directional coin#4...$151c,4 == #$3(right)
- Reznor#7...$151c,7 == #$1 (seems to be 1 when spawned using stun glitch)
- These allow the reznor-kill to succeed.
DP3
Summon credits using gray platform glitch.
It seems that details about the gray platform glitch have not been posted yet. I don't fully understand it myself and have taken the trace log of the already posted run that summons credits and analyzed it.
It seems that details about the gray platform glitch have not been posted yet. I don't fully understand it myself and have taken the trace log of the already posted run that summons credits and analyzed it.
The part of the trace log for this run that is noteworthy is below
01f1fc: lda $e4,x [0000e8] A:f1d2 X:0004 Y:0000 S:01d8 D:0000 DB:01 nVMXdiZC V: 80 H:247 // A = x position of yoshi#4 low byte (= #$49) 01f1fe: clc A:f149 X:0004 Y:0000 S:01d8 D:0000 DB:01 nVMXdizC V: 80 H:254 01f1ff: adc $f305,y [01f305] A:f149 X:0004 Y:0000 S:01d8 D:0000 DB:01 nVMXdizc V: 80 H:258 // A = A + #$10 (direction) 01f202: ply A:f159 X:0004 Y:0000 S:01d8 D:0000 DB:01 nvMXdizc V: 80 H:266 01f203: sta $00e4,y [0101e3] A:f159 X:0004 Y:00ff S:01d9 D:0000 DB:01 NvMXdizc V: 80 H:273 // $01e3(stack) = A (= #$59, must be >= #$1C)...*1
01ea8a: pla A:f120 X:0004 Y:00ff S:01e2 D:0000 DB:00 nvMXdiZc V: 81 H:327 // A = $01e3 (= #$59) 01ea8b: sta $15e9 [0015e9] A:f159 X:0004 Y:00ff S:01e3 D:0000 DB:00 nvMXdizc V: 81 H:333 // $15e9 = A (= #$59)
0086f7: jmp [$0000] [000000] A:8172 X:001c Y:0000 S:01f5 D:0000 DB:01 nvMXdiZc V:151 H: 97 018172: lda #$08 A:8172 X:001c Y:0000 S:01f5 D:0000 DB:01 nvMXdiZc V:151 H:109 018174: sta $14c8,x [0114e4] A:8108 X:001c Y:0000 S:01f5 D:0000 DB:01 nvMXdizc V:151 H:113 018177: lda $9e,x [0000ba] A:8108 X:001c Y:0000 S:01f5 D:0000 DB:01 nvMXdizc V:151 H:122 // A = x speed of yoshi#4 (must be = #$0e) 018179: jsl $0086df [0086df] A:810e X:001c Y:0000 S:01f5 D:0000 DB:01 nvMXdizc V:151 H:130 0086df: sty $03 [000003] A:810e X:001c Y:0000 S:01f2 D:0000 DB:01 nvMXdizc V:151 H:155 0086e1: ply A:810e X:001c Y:0000 S:01f2 D:0000 DB:01 nvMXdizc V:151 H:161 0086e2: sty $00 [000000] A:810e X:001c Y:007c S:01f3 D:0000 DB:01 nvMXdizc V:151 H:168 0086e4: rep #$30 A:810e X:001c Y:007c S:01f3 D:0000 DB:01 nvMXdizc V:151 H:174 0086e6: and #$00ff A:810e X:001c Y:007c S:01f3 D:0000 DB:01 nvmxdizc V:151 H:180 0086e9: asl a A:000e X:001c Y:007c S:01f3 D:0000 DB:01 nvmxdizc V:151 H:186 // A = 2A (= #$0e x 2) 0086ea: tay A:001c X:001c Y:007c S:01f3 D:0000 DB:01 nvmxdizc V:151 H:189 // Y = A (= #$1c) 0086eb: pla A:001c X:001c Y:001c S:01f3 D:0000 DB:01 nvmxdizc V:151 H:193 0086ec: sta $01 [000001] A:0181 X:001c Y:001c S:01f5 D:0000 DB:01 nvmxdizc V:151 H:202 0086ee: iny A:0181 X:001c Y:001c S:01f5 D:0000 DB:01 nvmxdizc V:151 H:210 0086ef: lda [$00],y [018199] A:0181 X:001c Y:001d S:01f5 D:0000 DB:01 nvmxdizc V:151 H:213 0086f1: sta $00 [000000] A:e1b8 X:001c Y:001d S:01f5 D:0000 DB:01 Nvmxdizc V:151 H:227 0086f3: sep #$30 A:e1b8 X:001c Y:001d S:01f5 D:0000 DB:01 Nvmxdizc V:151 H:235 0086f5: ldy $03 [000003] A:e1b8 X:001c Y:001d S:01f5 D:0000 DB:01 NvMXdizc V:151 H:241 0086f7: jmp [$0000] [000000] A:e1b8 X:001c Y:0000 S:01f5 D:0000 DB:01 nvMXdiZc V:151 H:247 01e1b8: lda $e4,x [000100] A:e1b8 X:001c Y:0000 S:01f5 D:0000 DB:01 nvMXdiZc V:151 H:259 // A = $100(game mode) (= #$14) 01e1ba: clc A:e114 X:001c Y:0000 S:01f5 D:0000 DB:01 nvMXdizc V:151 H:266 01e1bb: adc #$08 A:e114 X:001c Y:0000 S:01f5 D:0000 DB:01 nvMXdizc V:151 H:270 // A = A + #$08 (= #$1C) 01e1bd: sta $e4,x [000100] A:e11c X:001c Y:0000 S:01f5 D:0000 DB:01 nvMXdizc V:151 H:274 // $100 = A (= #$1C)
The glitch starts by rewriting $15e9 (sprite index for the current sprite that is being processed) to a free value, and CPU decrements this value as it processes the sprite for that slot number.
It appears that the above process is done during the #1c process. I am surprised at the last 4 lines...
If you want to know more, please refer to amaraticando's youtube, etc.
*1 There is a limited number of available GRAY platforms for this.
ACE: BRK-method
This is a method I developed because I can only use two controllers and therefore can only use two trollers. In this article, I will write “BRK-method”.
- When the BRK instruction is executed, the 3-byte return addr and 1-byte processor flag are pushed in sequence, and the program jumps to the BRK vector address (2 bytes) stored in ROM$00FFE6. In the North American version, the vector address is $FFFF, so the jump is made to $00FFFF.
- In the North American version, $00FFFF = #$82, which executes the BRL instruction. Here, the cpu returns to $000000 and reads the 2-byte operand.
By the way, $00, $01 are scrach RAM and are used for very many purposes. That is, when a crash occurs and the BRK instruction is executed, where the values of $00 and $01 can be manipulated, the program can jump to any location.
Two concrete examples of YI2(2) and DP1(2) are shown below.
YI2(2)
- 1st frame
Just before BRK
03b6f0: lda $03b56c,x [03b56c] A:0000 X:0000 Y:0000 S:01e7 D:0000 DB:01 nVmXDIZc V: 24 H:216 03b6f4: bpl $b6f8 [03b6f8] A:0202 X:0000 Y:0000 S:01e7 D:0000 DB:01 nVmXDIzc V: 24 H:228 03b6f8: clc A:0202 X:0000 Y:0000 S:01e7 D:0000 DB:01 nVmXDIzc V: 24 H:233 03b6f9: adc $00e4,y [0100e4] A:0202 X:0000 Y:0000 S:01e7 D:0000 DB:01 nVmXDIzc V: 24 H:237 // $e4 == 17, (Reason for adjusting x and y coordinates for shell #0) 03b6fc: sta $00 [000000] A:0919 X:0000 Y:0000 S:01e7 D:0000 DB:01 nvmXDIzc V: 24 H:247 // $00 = 19 03b6fe: lda $14e0,y [0114e0] A:0919 X:0000 Y:0000 S:01e7 D:0000 DB:01 nvmXDIzc V: 24 H:255 03b701: adc $0f [00000f] A:0204 X:0000 Y:0000 S:01e7 D:0000 DB:01 nvmXDIzc V: 24 H:265 03b703: sta $08 [000008] A:0204 X:0000 Y:0000 S:01e7 D:0000 DB:01 nvmXDIzc V: 24 H:273 03b705: lda $03b5a8,x [03b5a8] A:0204 X:0000 Y:0000 S:01e7 D:0000 DB:01 nvmXDIzc V: 24 H:281 03b709: sta $02 [000002] A:0c0c X:0000 Y:0000 S:01e7 D:0000 DB:01 nvmXDIzc V: 24 H:293 03b70b: stz $0f [00000f] A:0c0c X:0000 Y:0000 S:01e7 D:0000 DB:01 nvmXDIzc V: 24 H:301 03b70d: lda $03b5e4,x [03b5e4] A:0c0c X:0000 Y:0000 S:01e7 D:0000 DB:01 nvmXDIzc V: 24 H:309 03b711: bpl $b715 [03b715] A:0303 X:0000 Y:0000 S:01e7 D:0000 DB:01 nvmXDIzc V: 24 H:321 03b715: clc A:0303 X:0000 Y:0000 S:01e7 D:0000 DB:01 nvmXDIzc V: 24 H:326 03b716: adc $00d8,y [0100d8] A:0303 X:0000 Y:0000 S:01e7 D:0000 DB:01 nvmXDIzc V: 24 H:329 // $d8 == 39, (Note that the addition is done under decimal mode.) 03b719: sta $01 [000001] A:4342 X:0000 Y:0000 S:01e7 D:0000 DB:01 nvmXDIzc V: 24 H:339 // $01 = 42
The BRK part
01ac97: asl $c0,x [0001ae] A:0000 X:00ee Y:0000 S:01ea D:0000 DB:01 nvmXDIZc V: 25 H:323 01ac99: sbc $a905f0,x [a906de] A:0000 X:00ee Y:0000 S:01ea D:0000 DB:01 NvmXDIzc V: 25 H:338 01ac9d: brk #$99 A:9999 X:00ee Y:0000 S:01ea D:0000 DB:01 NvmXDIzc V: 26 H: 10 00ffff: brl $421b [00421b] A:9999 X:00ee Y:0000 S:01e6 D:0000 DB:01 NvmXdIzc V: 26 H: 26 // Advance by 2 bytes when BRK is executed 00421b: brk #$00 A:9999 X:00ee Y:0000 S:01e6 D:0000 DB:01 NvmXdIzc V: 26 H: 33 // jmp ($0000) = jmp $4219 004219: brk #$00 A:9999 X:00ee Y:0000 S:01e6 D:0000 DB:01 NvmXdIzc V: 26 H: 42 // sep #$20 00421b: brk #$00 A:9999 X:00ee Y:0000 S:01e6 D:0000 DB:01 NvMXdIzc V: 26 H: 46 // jmp ($0000) 004219: brk #$00 A:9999 X:00ee Y:0000 S:01e6 D:0000 DB:01 NvMXdIzc V: 26 H: 55 // sep #$20... 00421b: brk #$00 A:9999 X:00ee Y:0000 S:01e6 D:0000 DB:01 NvMXdIzc V: 26 H: 59 004219: brk #$00 A:9999 X:00ee Y:0000 S:01e6 D:0000 DB:01 NvMXdIzc V: 26 H: 68 00421b: brk #$00 A:9999 X:00ee Y:0000 S:01e6 D:0000 DB:01 NvMXdIzc V: 26 H: 72 004219: brk #$00 A:9999 X:00ee Y:0000 S:01e6 D:0000 DB:01 NvMXdIzc V: 26 H: 81
(4 bytes from $004218 are as follows.)
00 e2 20 6c
- 2nd frame
Return portion
0082bc: rep #$30 A:0200 X:0000 Y:0024 S:01da D:0000 DB:00 nvMXdIZc V:247 H: 31 0082be: plb A:0200 X:0000 Y:0024 S:01da D:0000 DB:00 nvmxdIZc V:247 H: 37 0082bf: ply A:0200 X:0000 Y:0024 S:01db D:0000 DB:01 nvmxdIzc V:247 H: 44 0082c0: plx A:0200 X:0000 Y:0000 S:01dd D:0000 DB:01 nvmxdIZc V:247 H: 53 0082c1: pla A:0200 X:00ee Y:0000 S:01df D:0000 DB:01 nvmxdIzc V:247 H: 62 0082c2: plp A:9999 X:00ee Y:0000 S:01e1 D:0000 DB:01 NvmxdIzc V:247 H: 71 0082c3: rti A:9999 X:00ee Y:0000 S:01e2 D:0000 DB:01 NvMXdIzc V:247 H: 78 004219: brk #$00 A:9999 X:00ee Y:0000 S:01e6 D:0000 DB:01 NvMXdIzc V:247 H: 91 // jmp $f050 *2 00f050: cmp $00eac1,x [00ebaf] A:9999 X:00ee Y:0000 S:01e6 D:0000 DB:01 NvMXdIzc V:247 H: 95 00f054: beq $f05a [00f05a] A:9999 X:00ee Y:0000 S:01e6 D:0000 DB:01 nvMXdIzC V:247 H:105 00f056: dex A:9999 X:00ee Y:0000 S:01e6 D:0000 DB:01 nvMXdIzC V:247 H:109 00f057: bpl $f050 [00f050] A:9999 X:00ed Y:0000 S:01e6 D:0000 DB:01 NvMXdIzC V:247 H:113 00f059: clc A:9999 X:00ed Y:0000 S:01e6 D:0000 DB:01 NvMXdIzC V:247 H:117 00f05a: plx A:9999 X:00ed Y:0000 S:01e6 D:0000 DB:01 NvMXdIzc V:247 H:120 // PLX 00f05b: rtl A:9999 X:009c Y:0000 S:01e7 D:0000 DB:01 NvMXdIzc V:247 H:127 // RTL 01aca0: ora $c89e,y [01c89e] A:9999 X:009c Y:0000 S:01ea D:0000 DB:01 NvMXdIzc V:247 H:148 01aca3: trb $60 [000060] A:999f X:009c Y:0000 S:01ea D:0000 DB:01 NvMXdIzc V:247 H:156 01aca5: lda $167a,x [011716] A:999f X:009c Y:0000 S:01ea D:0000 DB:01 NvMXdIZc V:247 H:166 01aca8: and #$04 A:9900 X:009c Y:0000 S:01ea D:0000 DB:01 nvMXdIZc V:247 H:175 01acaa: bne $aca4 [01aca4] A:9900 X:009c Y:0000 S:01ea D:0000 DB:01 nvMXdIZc V:247 H:179
- In the 2nd frame, the controller input seems to be updated properly. Could it have something to do with the fact that $10 == #$00?
- The fact that line *2 starts at $004219 and not at $00421b may depend on the number of f instructions before this frame. (I assume from the fact that it sometimes crashes with only a slight change in input to the frame immediately before the frame that crashes.)
- For 1st and 2nd frame, the direct cause was thought to be a misreading of the program due to the M flag being cleared, so I set it, pulled the 1-byte processor register loaded on the stack, and excused RTL to recover.
- Normally, it would be sufficient to return from a safe return address on the stack that had not been destroyed by the time any code could be executed after the crash, but the fact that the above method worked may have been somewhat coincidental. It may be that I was thinking about various things when they created it...
DP1(2)
(only one frame)
01c4bf: lda $1540,x [011547] A:f398 X:0007 Y:0007 S:01e8 D:0000 DB:01 nvMXdizC V: 15 H: 10 // $1540,x (stun timer of chuck#7) must be < #$18 01c4c2: cmp #$18 A:f313 X:0007 Y:0007 S:01e8 D:0000 DB:01 nvMXdizC V: 15 H: 18 01c4c4: bcs $c4fa [01c4fa] A:f313 X:0007 Y:0007 S:01e8 D:0000 DB:01 NvMXdizc V: 15 H: 22 01c4c6: stz $14c8,x [0114cf] A:f313 X:0007 Y:0007 S:01e8 D:0000 DB:01 NvMXdizc V: 15 H: 26
0086f7: jmp [$0000] [000000] A:9eb5 X:0007 Y:0093 S:01e8 D:0000 DB:01 NVMXdizc V: 15 H:234 // This is where the crash occurs(?) 019eb5: cpx #$14 A:9eb5 X:0007 Y:0093 S:01e8 D:0000 DB:01 NVMXdizc V: 15 H:246
01a3d0: lda $e4,x [0000eb] A:c09c X:0007 Y:00bc S:01ee D:0000 DB:01 NvMXdizc V: 18 H:173 01a3d2: sec A:c0f3 X:0007 Y:00bc S:01ee D:0000 DB:01 NvMXdizc V: 18 H:181 01a3d3: sbc $1a [00001a] A:c0f3 X:0007 Y:00bc S:01ee D:0000 DB:01 NvMXdizC V: 18 H:184 // $1a (Layer 1 X position) == #$dc 01a3d5: sta $00 [000000] A:c017 X:0007 Y:00bc S:01ee D:0000 DB:01 nvMXdizC V: 18 H:190 // $00 = 17 01a3d7: lda $d8,x [0000df] A:c017 X:0007 Y:00bc S:01ee D:0000 DB:01 nvMXdizC V: 18 H:196 01a3d9: sec A:c0de X:0007 Y:00bc S:01ee D:0000 DB:01 NvMXdizC V: 18 H:204 01a3da: sbc $1c [00001c] A:c0de X:0007 Y:00bc S:01ee D:0000 DB:01 NvMXdizC V: 18 H:207 // $1c (Layer 1 Y position) == #$9c 01a3dc: sta $01 [000001] A:c042 X:0007 Y:00bc S:01ee D:0000 DB:01 nvMXdizC V: 18 H:213 // $01 = 42 01a3de: rts A:c042 X:0007 Y:00bc S:01ee D:0000 DB:01 nvMXdizC V: 18 H:219 0120ec: brk #$00 A:c042 X:0007 Y:00bc S:01f0 D:0000 DB:01 nvMXdizC V: 18 H:230 // Where the stacks are shallowest 012020: brk #$00 A:c042 X:0007 Y:00bc S:01ee D:0000 DB:01 nvMXdizC V: 18 H:240 012023: brk #$00 A:c042 X:0007 Y:00bc S:01ee D:0000 DB:01 nvMXdizC V: 18 H:250
01212c: brk #$00 A:c05b X:0007 Y:00bc S:01ee D:0000 DB:01 nvMXdizc V: 21 H: 4 012130: brk #$00 A:c05b X:0007 Y:00bc S:01ee D:0000 DB:01 nvMXdizc V: 21 H: 12 012134: brk #$00 A:c05b X:0007 Y:00bc S:01ee D:0000 DB:01 nvMXdizc V: 21 H: 20 00ffff: brl $4219 [004219] A:c05b X:0007 Y:00bc S:01ea D:0000 DB:01 nvMXdIzc V: 21 H: 35 // BRK executed. 004219: brk #$00 A:c05b X:0007 Y:00bc S:01ea D:0000 DB:01 nvMXdIzc V: 21 H: 43 019ecd: lsr a A:c05b X:0007 Y:00bc S:01ea D:0000 DB:01 nvMXdIzc V: 21 H: 53 // jml [$0000] = jml $019ecd, (#$cd is the y-coordinate of the idling Yoshi, and I found a subroutine that fits this number and matched the y-coordinate of the mushroom to it. )
(4 bytes from $004218 are as follows.)
00 dc e0 00
019ef2: pla A:c0b5 X:0007 Y:00c0 S:01ea D:0000 DB:01 nvMXdIzC V: 22 H:237 019ef3: sta $157c,x [011583] A:c030 X:0007 Y:00c0 S:01eb D:0000 DB:01 nvMXdIzC V: 22 H:244 019ef6: pla A:c030 X:0007 Y:00c0 S:01eb D:0000 DB:01 nvMXdIzC V: 22 H:254 019ef7: sta $15ea,x [0115f1] A:c036 X:0007 Y:00c0 S:01ec D:0000 DB:01 nvMXdIzC V: 22 H:261 019efa: pla A:c036 X:0007 Y:00c0 S:01ec D:0000 DB:01 nvMXdIzC V: 22 H:270 019efb: sta $14e0,x [0114e7] A:c021 X:0007 Y:00c0 S:01ed D:0000 DB:01 nvMXdIzC V: 22 H:277 019efe: pla A:c021 X:0007 Y:00c0 S:01ed D:0000 DB:01 nvMXdIzC V: 22 H:287 019eff: sta $e4,x [0000eb] A:c001 X:0007 Y:00c0 S:01ee D:0000 DB:01 nvMXdIzC V: 22 H:294 019f01: pla A:c001 X:0007 Y:00c0 S:01ee D:0000 DB:01 nvMXdIzC V: 22 H:301 019f02: sta $14d4,x [0114db] A:c0ee X:0007 Y:00c0 S:01ef D:0000 DB:01 NvMXdIzC V: 22 H:308 019f05: pla A:c0ee X:0007 Y:00c0 S:01ef D:0000 DB:01 NvMXdIzC V: 22 H:318 019f06: sta $d8,x [0000df] A:c020 X:0007 Y:00c0 S:01f0 D:0000 DB:01 nvMXdIzC V: 22 H:324 019f08: rts A:c020 X:0007 Y:00c0 S:01f0 D:0000 DB:01 nvMXdIzC V: 22 H:331 // Return from a secure (safe) stuck position with RTS.
Details Of Minor Glitches
I will add to it as needed.
Storing Berry Glitch
You can "store" a berry to Yoshi's tongue by picking up a berry with Yoshi's mouth, but canceling it by sticking out Yoshi's tongue and turning away. You can tell if it was done correctly if the berry doesn't turn into a sprite, but the game still freezes for a frame as if Yoshi ate it. As a result, the next sprite Yoshi swallows will add to his berry count, and can be repeated on a single berry indefinitely. A small additional side effect is that any sprite berries will inherit the palette of the stored berry until it is used.(source)
Yoshi-related Glitches
- Yoshi does not despawn under the ground while Mario is on it.
- When multiple Yoshi eggs are produced with no Yoshi present, only the Yoshi in the lowest slot is visible and behaves normally, while the Yoshi in the other slots are invisible and behave strangely.
- When Visible-yoshi despawns, the Yoshi in the lowest remaining slot becomes visible. It takes over whether or not Yoshi is stuffing his mouth with food.
- Eggs are laid by Yoshi with the highest slot number.
- Invisi-yoshi's coordinates are fixed when you gets on. When you get off,
- Y speed of Yoshi = 0
- X speed of him = X speed of Mario
- Y coordinate of Mario = Y coordinate of Yoshi
- When on an Invisi-Yoshi, if he contacts a sprite(?) with a higher slot number than it, it escapes.
Null Sprite Overload
The characteristics of #1 and #3 change.
- #1 omitted
- #3 will have the bits "Being eaten" set and "Interaction with Objects" cleared.
As a result, they will be able to penetrate walls and floors. (Invisible Yoshi will not despawn?)
Finally, I would like to thank those who have seen this run and read this article.