Category: glitches

Super Mario All-Stars Random Debug Mode

We are told by The Cutting Room Floor this interesting fact. Super Mario Bros. 3 has a debug mode that activates when a specific memory location contains 80 hex, that allows the user to grant Mario any powerup. In normal play this never activates because the cartridge initializes all of RAM to 0 as part of initialization. But the version of the game included in SNES Super Mario All-Stars, while it closely follows the original’s logic in many ways including including debug mode and its criteria for activation, doesn’t initialize memory when starting up. When the console boots up, its RAM contains random voltages that can be interpreted as nearly any value, and there’s a chance that there’ll be 80 hex in memory location 7E0160, and enable the debug mode for Super Mario Bros. 3.

While ordinarily this would be a 1-in-256 chance, some consoles are prone to favoring specific values, so some units will turn on debug mode more often. As a result a legend developed that certain Super Mario All-Star cartridges are special debug versions that accidentally got put into retail boxes and sold.

Supper Mario Broth made a short video (about 1 1/2 minutes) explaining how it works in crudely animated form:

As it turns out, Mario All-Stars has its own debug modes for each game in the compilation, but the one for Mario 3 is different, and buggier. Meanwhile the original debug mode for Mario 3 remains, intact, buried in the code, waiting for the value 80 hex to appear in its magic location to unveil itself.

Why Is NES Strider So Janky?

There are a number of NES games that feel like they’re held together with paperclips and chewing gum. Some of them are almost endearing for their glitchiness. When it comes to janky NES games, a few that I tend to think of are those made by Micronics (who implemented Ghosts N’ Goblins, which has an awful frame rate) and Athena (where one boss has a death animation that causes it to flip through many of the sprites in the game).

A company that usually did a lot better with their internally-developed games was Capcom, makers of Mega Man, 1943, Bionic Commando, and all the Disney Afternoon games from the time, all of which have slick 60 fps update rates and smooth animation. One game they made of which that is definitely not true, however, is NES Strider.

If you’re only familiar with Strider from the beautiful arcade version, you might wonder what even NES Strider has to do with it. It’s not proper to say Famicom Strider, because Capcom never released it in their home territory, perhaps because they were too embarrassed to.

Other than the first stage being set in generally the same fictional location in Russia (even if it doesn’t look at all the same), its story has absolutely nothing to do with it. Jeremy Parish looked at it (and remarked on its glitchiness) in an episode of Metroidvania Works from a couple of weeks ago. Some people, like Kid Fenris of the self-titled blog, actually likes it, although acknowledges its many issues.

Behind the Code, one of the best game internals series on Youtube, had a look at the implementation of NES Strider. It’s an interesting 15 minutes to my taste, but if you want a tl;dr, NES Strider often doesn’t make its framerate target, and instead of slowing the game down as most games do, it plows ahead forward into the next frame, leaving the incomplete data in its update buffer to be copied into the PPU. This causes the individual hardware sprites that compose enemy characters to sometimes have only one of their coordinates updated, or even causing data remaining from previous frames to be copied over.

Why does it does this instead of just slowing the game down? Possibly the coding was so crappy that it would have caused excessive slowdown; the scene chosen as an example in the video has the problem occur when there’s only two basic enemies on the screen in the game’s first area! Not the best engine on the system there Capcom.

The Garbage Sprites in Strider (NES) (Behind the Code on Youtube, 15 minutes)

Video: GoldenTorizoCode

This is a channel on YouTube of various Super Metroid glitches and weirdness. A lot of it is pretty deep magic, and they tend to throw around evocative terms like Murder Beam, Chainsaw Beam, and even Spacetime Beam. Those links are useful in understanding what in the burning acidic heck the narrator is talking about. Knowing and caring about the gameplay of Super Metroid is, of course, required for comprehension.

But if you do know about Super Metroid, and you do care about learning about some of the more ridiculous glitches in videogamedom, then you’re in for something that is a reasonable approximation of entertainment.

The name of the channel refers to a debug feature left in Super Metroid’s code, that can be pulled off without hyper-obscure tech, although in the process it’s likely to crash your game. When you enter into the room of the of the bosses, the Golden Torizo, if all of the face buttons are held down during the transition, your equipment will be overwritten by a number of items. The code gives you all of the beam weapons in the game, which is good, but also turns them all on at once, producing the afore-mentioned Murder Beam, which will likely crash the game, not good. The opposite of good.

Here’s links to a few of these videos: an unused enemy called a Bang, activating “God Mode,” and how to obtain and use the end-game weapon Hyper Beam against bosses. It is some pretty intense geekery, but that’s sometimes what flows out of the faucets around here.