Also, the video has a lot of info about how levels are constructed in Mario in general, which I found very informative.
If you'd like a lot more on this kind of topic, check out the book "I Am Error" by Nathan Altice (published by MIT Press; don't buy from Amazon). It goes into a bunch of detail about how the NES hardware worked and how specific games used it.
I assumed they were for testers to quickly go to some level on a release build?
It could even only work for the P2 controller, or use inputs not normally possible like left + right simultaneously.
Are there NES games (or mods) that have different (useful) behavior when an emulator permits such inputs?
https://tasvideos.org/GameResources/NES/SuperMarioBros#Turni...
This sparked a mild controversy recently in the speedrunning community: L+R walljumping makes it possible to climb walls underwater without Gravity Suit or Hi-Jump Boots. Through the use of very esoteric and difficult speedrun tech, this enabled a runner to complete the game while collecting only 13% of available items, which would beat the previous low% record of 14% if left+right runs were allowed on the leaderboard: https://wiki.supermetroid.run/13%25_xCharge
Other versions of SMB have different minus worlds (and some versions had the bug either fixed as in Super Mario All-Stars, or blocked off as in VS Super Mario Bros). Famicom Disk System version of SMB1 has a three-level minus world that ends with a Bowser fight that completes the game as if it was 8-4.
The minus world is a total bug. It was not designed or intended to exist. The bug was solely the result of the INC WarpZoneCtrl instruction that the video author mentions, which makes the game treat the warp zone pipes as the 4-2 warp zone until the text appears. Remove that INC, and the game will instead dump you out as if you'd gone in the L-pipe prior to the warp zone.
Obviously this bug doesn't exist at all in SMB DX for Game Boy Color, as it is a completely rewritten engine. I would presume the bug didn't exist at all in Super Mario Bros 35.
"Players quickly figured out that it was possible to access levels beyond 8-4 by hot-swapping cartridges.
What is positively known is that in 1986 a magazine called “FC Bug Boy Special: Super Mario 256W ” was released by JICC Publishing Office in Japan.3 This magazine detailed how to access worlds beyond 8-4 with the hot-swap method.4 It also included data tables and information about these mysterious levels.5 This publication most likely helped information about “256-World” spread through the budding player/hacking community."
This ultimately led to the release of the Tonkachi Editor, sort of like a primitive Game Genie where you could laboriously modify memory to more precisely hack together your own levels.
"It was a binary editor, but far from the sophisticated software available on today’s computers, it was light and simple at best, and could only patch data displayed in hexadecimal or ASCII code, not move or copy data. Since there was no environment, of course, no printout was possible. Moreover, due to the nature of quick disks, subsequent files could easily be destroyed if they were rewritten on a different drive or other device, and recovering them required a great deal of effort. In fact, even now that I am accustomed to using a Tonkachi, a task that can be done in a few minutes on a PC can take up to an hour or two on the NES if you use a Tonkachi."
This ultimately resulted in a ROM Hack version of SMB called Tonkachi Mario released all the way back in 1987, at least a decade before I'd have assumed such hacks were being released.
[1] https://glitchcat7.com/the-complete-history-of-kaizo-mario/
Just yesterday I was storing my color planes in three separate adjacent buffers for reasons, and if you looped the player off the bottom of the screen it came back up in a different color on the top. Now I need to figure out what to do with that…
The point is this stuff arises whenever you have, like `char level_data[8][4][10][100]` rather than, like `class level { std::vector<actor*> actors; std::vector<sprite*> background; }`. And storing stuff in large contiguous blocks that can be interesting when misinterpreted is still a pretty good way to write modern games if you don't have OO brain rot.
Pretty much the only ways an NES game can "crash" is by calling an invalid function pointer, corrupting the stack, or getting stuck in an infinite loop somewhere. Otherwise, the game will more-or-less stumble on no matter what you throw at it -- accessing an array out of bounds will usually give you a nonsensical value taken from whatever comes after the array on the cartridge, dereferencing an invalid pointer will just give you some arbitrary data from RAM or ROM, etc. Therefore, the effects of going to an out-of-bounds level can vary from game to game, depending on what sort of format the game uses to store level data. Off the top of my head:
- Super Mario Bros. gives you slightly broken versions of regular levels, such as the various Minus Worlds. I haven't looked into the code, but presumably this is because a "level" is really just a header that contains indexes into tables of rooms & enemy lists & whatnot. So, going into an invalid level gives you a weird combination of existing rooms and enemies.
- Super Mario Bros. 3's level format has a lot of function pointers, so it usually crashes if you select an invalid level from the map screen. But the levels get decompressed into a big 2D array of tiles in RAM, so if you go out-of-bounds within a level you end up in a world of garbled tiles. Although some of those tiles will call invalid function pointers & crash the game when you interact with them; famously, this can be turned into an arbitrary code execution exploit. Here's a video of a speedrunner exploiting this in real time, manipulating enemies so that their positions in RAM form a short program that triggers the end cutscene: https://youtu.be/mUeozQtSmrg?t=202
- Mega Man 2 stores level data as a grid of tiles on the cartridge, but all the levels are stored consecutively, so if you go out-of-bounds you usually end up in a garbled version of another level.
- The famous MissingNo. glitch in Pokemon Red and Blue is caused by use of an uninitialized variable that causes a decompression routine to run on bad input, which then triggers a buffer overflow that stomps on part of your save file: https://youtu.be/ZI50XUeN6QE?t=880
Here Y is the vertical position of Mario (0--> on top of the level). So, one bug is: there was supposed to be a scroll stop unless Mario was on top of the level. Because you can scroll the screen while not on top of the level produces the -1 level bug where you scroll Mario through to the warp zone with some junk in a certain memory location.
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. (EDIT: I misunderstood this point, see discussion below)
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.
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 :)
BEQ PLTMRT ; Scrool stopping ?
; : yes !
LDA PLYPS1
AND <PLYPS0
BNE PLTMRT ; Player Y pos = 0 ?
;
STA SRSTFG ; yes !
INC CMSLFG ; Chimney select flagThey probably started with ORA, and when that didn't work, tried AND, and that seemed to work, so they went with it.
.. yes, text is great, but video can, too, be great, whether it's explaining something fictional or not. Different strokes for different folks.
https://telehack.com/ -> starwars
or
(which apologies for video of text of video) https://www.youtube.com/watch?v=EJAbbRh9q4k
since the original is dead.
But TL;DR is a way of life.
Video is a nice relaxing medium with video and audio.
Some prefer it others prefer text, I prefer both depending on where I am.
Guess what I prefer on the couch
The underground 1-2 level is supposed to stop scrolling as soon as the mundane return-to-surface pipe comes onto the right edge of the screen. (Unless you're walking on the ceiling.) But because of a programming error, it keeps scrolling, revealing that the warp zone room is there.
It was originally intended to be a much more hidden secret than it turned out to be.
(This is all explained much more thoroughly yet accessibly, and illustrated much more brilliantly, in the video; I suggest you watch it when you can.)
Now for some speculation on my part.
It's unclear whether the error was missed in testing or intentionally left unfixed because they decided they liked the erroneous behavior better. But there's a bunch of evidence that warp zones were added very late in the game's development, perhaps as a last-minute change.
This includes:
* Comments in original SMB source code (revealed in the 2021 "Nintendo Gigaleak") confirm that the programmer thought they were checking if Y = 0 when deciding whether to lock scrolling for the warp zone, even though the code doesn't do that. And these subroutines are located at the ends of their files/sections.
* Each object and enemy in the game is assigned a code, and the ones used to control warp zones are assigned the last codes used in the game.
* Memory addresses assigned to warp zone control variables are at the end of their respective tables.
* The code that decides where the warp pipes take you is implemented as: "Are we in World 1-x? Then 2-3-4. Else, are we underground? Then 5. Else, 6-7-8." This indicates that the level maps were stable when the warp code was written.