You can still get the minus world bug even if you go above the top of the screen. If you only fix the scroll stop AND bug, do the normal minus world bug, reach the right side of the screen, jump up on top of the level (to unlock the scroll), and drop down into the warp zone room as soon as possible, then the text hasn't loaded yet but you can still enter the pipes, which results in the normal minus world behavior. The real bug is that the scroll stop unlock object, for some reason, increments the variable the video author calls WarpZoneCtrl, resulting in it containing a value of 1, while the actual warp zone routine expects 4, 5, or 6, which it subsequently ANDs with 3 (removing all but the bottom two bits, leaving 0, 1, or 2). Entering this subroutine with an incorrect value of 1 results in the value remaining 1 (since 1 AND 3 is equivalent to 5 AND 3) and thus treating the warp zone as world 5, which is corrected when the routine that prints the warp zone text appears. The real minus world bug is the incrementation of WarpZoneCtrl. Removing that, and keeping the value at 0 until the warp zone text loads, makes the pipes use the last known pipe destination - the L-pipe that leads to the normal 1-2 level end.

The video author did not discuss level 4-2, but I would presume there may be a similar scroll unlock object present at the end of that level (in fact, my long history of playing SMB1 leads me to remember that I feel like I have also experienced in 4-2 that slight scroll hiccup the author mentions if you jump just right and keep the low bit of your X position set). However, since the standard end-of-level warp zone in 4-2 is meant to take you to 5-1, and there is only one pipe, the minus world bug doesn't apply as entering the routine with WarpZoneCtrl set to 1 is equivalent to entering it with WarpZoneCtrl set to 5.

> The memory location is corrupted because they set a boolean flag with an increment operation, which of course causes an overflow instead of setting a zero to a 1.

Huh? No, the increment operation simply changes the warp zone control flag from 0 to 1. The valid values are normally 4, 5, and 6 (since they only use the low 2 bits to index into a table, and 0 is reserved for "no warp zone") -- so 1 is treated identically to 5.

Why this increment is even there is not clear at all, since the 1 should just get overwritten by a 4 later on, once the screen is scrolled all the way to the right and the warp zone is properly loaded. The only situation where this 1 has any effect is when entering the warp zone before it's properly loaded in order to go to the minus world.

Given that this increment is right after the nonsensical AND, I'm just gonna guess that whoever wrote this code was very sleep-deprived :)

Perhaps they meant to increment another variable and typed the label or address wrong (labels back then were generally much more limited in length on the average development system, I bet that the actual name for the variable in question was nowhere near the length of WarpZoneCtrl, most likely it was limited to 6 or 8 characters). I don't know the low level logic of the engine enough to know if there is a different variable that it would actually make sense to increment in this place.

Based on the original leaked source code, it appears they really did intend to increment the variable they did. The comment matches the name and purpose:

             BEQ      PLTMRT          ; Scrool stopping ?
    ;                                 : yes !
             LDA      PLYPS1
             AND      <PLYPS0
             BNE      PLTMRT          ; Player Y pos = 0 ?
    ;
             STA      SRSTFG          ; yes !
             INC      CMSLFG          ; Chimney  select flag

The buggy AND is really interesting to me -- the comment suggests that maybe the programmer meant to use an ORA instead, which would have been a clever way to check if both bytes of the Y position were zero. But that's still not something that makes sense to check, right? Assuming I'm understanding the video right, that'd only unlock the scroll if Mario was way up above the top of the screen...

I believe the NES's 6502 didn't have a logical-OR operator (which is what the situation calls for), only bitwise. The apparent goal was to find out, "Are either PLYPS0 or PLYPS1 equal to 0?"

They probably started with ORA, and when that didn't work, tried AND, and that seemed to work, so they went with it.

Ohhh, that makes sense. Thanks!