Do you happen to know why the minus world is the way it is? Was it a level that was designed, or is it a level where it's rendering some random program or other data? I'd love to learn more about that part too.
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.
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
"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/