Summary of "After 40 Years, Huge NEW Mario Glitch Discovered"

Storyline (what the video is “about”)

The video centers on discovering a new glitch capability in Super Mario Bros. (SMB1) by extending a breakthrough from another version/game: arbitrary code execution (ACE)—a “holy grail” glitch where the game can be tricked into executing chosen instructions.
ACE was first shown in the Japanese SMB2 (The Lost Levels, “SMB2J”), and the community then tried to determine whether ACE could be made to work in SMB1 by finding an SMB1-level setup that satisfies the same memory-corruption conditions.
The latter half describes an extended struggle to make ACE happen in SMB1’s glitched area (“World Minus one” / “Minus World”), eventually succeeding by using:
- a special corrupted powerup behavior, and
- the NES/Famicom Disc System’s reset/data behavior to “lock in” one critical instruction change.

Core gameplay / glitch concepts explained

What “ACE” means in this context

Arbitrary code execution = the game can be forced to jump to data it shouldn’t execute (typically RAM or other control memory), then treat those bytes as CPU/game instructions.
It’s “arbitrary” because the researchers can influence what instruction values get executed by manipulating in-game/engine state (like lives, action states, and/or memory contents).
ACE is fragile: many byte patterns cause immediate crashes, so the glitch requires precise setup.

How ACE happens (generic technical mechanism from the video)

Games store:

Code/data meant to execute in one memory region.
Non-code values (level/object state, RAM variables, etc.) in other regions.

The typical ACE path:

A glitch forces the game to jump outside the intended code segment.
The game begins executing whatever numbers exist in the jumped-to memory region as if they were instructions.
Because the player can influence some of that memory content, they gain partial control over what executes.

The “SMB2J ACE” setup (the basis for the SMB1 attempt)

Key discovery source

A casual player, Luigi’s Sidekick, accidentally triggered a crash while playing SMB2J (Lost Levels) and posted it.
The community (notably Simplistic) reverse-engineered the crash into a reproducible exploit.

The specific SMB2J glitch: “Object overflow” (as described)

Requires an object slot overflow pattern:
- All object slots are full except one.
- You then load an object that consists of two parts (like Long Fire Bar or Bowser).
- The overflow writes an unexpected value (84) into memory where it leads to out-of-range behavior.
Critical additional requirement:
- A specific enemy must be present: green Koopa (Koopa Troopa) because it has enemy ID = 0.
Result:
- The game misinterprets 84 as an enemy ID, causing it to jump via the wrong table entry.
- That wrong jump leads to execution of data as instructions—i.e., ACE.

SMB2J speedrun impact / example outcome

In speedruns, ACE enables reaching the ending cutscene about 19 seconds faster in the category discussed.
A specific optimized method uses:
- frame-perfect movements,
- enemy/object state manipulation (fireballs, mushroom, coin-score despawns),
- precise lava landing/damage timing,
- and other tight state control.

SMB1 attempt: why it’s so hard

Initial consensus: ACE could not be done in SMB1 “normally” because SMB1 lacked the right combination of:
- enough Long Fire Bar / Bowser placements, and
- a place where the object overflow conditions could be met (including the powerup slot difficulty).
The breakthrough angle comes from SMB1’s glitched “Minus World” and special version behavior.

The SMB1 breakthrough (what eventually enables ACE in SMB1)

Why “Minus World” matters

In SMB1 Minus World (especially on certain versions), enemies/objects behave oddly:

objects like Princess Peach objects and Bowsers can become permanently present (don’t unload),
the star flag can occupy the powerup slot and persist.

This creates (sometimes) the environment needed for the overflow glitch: “one open slot, others filled.”

The major blocker in Minus World

Even when object slots look correctly set up, the engine’s object spawning order list can be “out of logical order” due to the glitched memory basis.
This can prevent necessary enemies (like the needed green Koopa) from spawning where required.
Underwater behavior also prevents Koopa turning on damage, removing one fallback tactic.

First proof-of-concept: “one instruction ACE” via PPU corruption

The team succeeds in an intermediate step:
- They manage a crash such that code execution jumps into PPU-register memory (graphics/control registers).
- On the Famicom Disc System, they can:
  - modify what gets loaded into the adapter,
  - then reset after a crash, preserving a single changed instruction.
They confirm a form of ACE on original hardware, but it wasn’t yet the “full control” needed for clean in-game progression.

The key enabling discovery: infinite time / timer corruption

A later glitch possibility corrupts the routine that updates the digits/timer area.
Effect:
- Timer never ticks down → effectively infinite time.
This would allow reaching much later areas/Bowsers necessary for real ACE setups.

The catch

Infinite time prevented returning through normal completion flow.
To access Minus World again after using the title/start flow, they rely on:
- the game continuing, and
- being in the correct state/character setup to regain necessary powerups.

Final required character/state: Luigi + quest setup + Buzzy Beetle conversion

The video’s final working recipe relies on:

Activating Quest 2 by beating the relevant content (Minus World completion triggers it).
In Quest 2, all Gloombas become Buzzy Beetles, enabling a way to obtain behavior equivalent to needing an enemy with enemy ID = 0 (via a specific shell/follow behavior described).
Returning to Minus World using two-player mode:
- die as Mario,
- play as Luigi, collect powerups, and set up the critical memory overwrite.

How the final ACE execution is achieved (high-level sequence from the video)

Preconditions

Be in Quest 2 so enemy conversion behavior holds.
Reach Minus World and set up objects to satisfy the overflow/glitched write conditions.

Execution steps (condensed)

Enter Minus World as Luigi.
Ensure the overflow glitch can be performed on an appropriate Bowser (with slots prepared and a Buzzy Beetle/enemy behavior established).
Position so the glitched object overwrite hits Luigi’s action state when Bowser loads.
Use the blooper’s height to ensure the exact memory value at the moment of reset/crash produces the intended jump/corruption.
A corrupted powerup routine produces the crucial path where execution reaches RAM.
From there, chosen instruction/control becomes possible—leading to unusual outcomes (including the “Mario swim in the air / load wrong behaviors” style results shown).

Outcome stated by the video

ACE “exists” in SMB1 and works on completely original hardware.

The time to complete the whole route is about 5:15, which is ~20 seconds slower than normal completion.
Historically, it’s important because the ACE execution itself is genuinely new.

Strategies / key tips highlighted

When researchers see a crash in a suspected ACE chain, they:
- trace what memory is being written,
- identify values that appear only during the crash (e.g., the 84 theme),
- test whether those values can lead to out-of-bounds table lookups that redirect execution.
For SMB2J:
- ensure the object overflow conditions plus the presence of green Koopa (ID 0).
For SMB1:
- use Minus World because object persistence and glitched slot states can mimic required “full slots except one” conditions,
- compensate for engine/object-list out-of-order spawning,
- rely on Famicom Disc System + reset behavior to preserve the meaningful instruction corruption,
- ultimately use timer/powerup routine corruption and a Quest 2 state to gain enough control and reach the right execution window.

Gamers / sources featured (mentioned at the end or as contributors)

Luigi’s Sidekick (casual player whose post sparked the chain in SMB2J)
Simplistic (key researcher who replicated/reversed the crash into ACE)
Takuika Ninja (flagged the crash as promising via community discussion)
three Creepio (top contributor; heavily involved in SMB1 attempts and final setup)
100th coin (worked on emulator/PPU accuracy; later helped crack PPU/ACE-related behavior)
SpdWolf / spdwolf (previously cracked ACE in Castlevania; joined the SMB1 ACE effort)
Luki (credited for enabling a viable real-time method)
Nipsky (first ACE run in the SMB2J ACE category mentioned; record progression)
Hitskrits (credited with contributions around the method/category record context)
Scalpel (later improved record in the SMB2J ACE category)
Video sponsor mentioned: Flexispot (chair sponsor; not part of the glitch research)