Super Mario Bros warp zones were intended to work slightly differently [video]

Re:Super Mario Bros warp zones were intended to work slightl... by NobodyNada on Monday June 27, 2022 @11:22AM (#31895826)

> 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 :)

[ Parent | on HN ]

Re:Super Mario Bros warp zones were intended to work slightl... by LocalH on Monday June 27, 2022 @11:34AM (#31896026)

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.

[ Parent | on HN ]

Re:Super Mario Bros warp zones were intended to work slightl... by raldi on Monday June 27, 2022 @12:25PM (#31896851)

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

[ Parent | on HN ]

Re:Super Mario Bros warp zones were intended to work slightl... by NobodyNada on Monday June 27, 2022 @06:10PM (#31901514)

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...

[ Parent | on HN ]

Re:Super Mario Bros warp zones were intended to work slightl... by raldi on Monday June 27, 2022 @06:23PM (#31901667)

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.

[ Parent | on HN ]

Re:Super Mario Bros warp zones were intended to work slightl... by NobodyNada on Monday June 27, 2022 @06:40PM (#31901847)

Ohhh, that makes sense. Thanks!

[ Parent | on HN ]