Introduction

Super Mario Bros. is 40 kilobytes of ROM. Eight worlds, 32 levels, enemies, music, power-ups, all of it fits in there.

But if you open an emulator and tweak the right bytes, you can load level 36-1. Or 255-1. Or land in a world made entirely of Bowser sprites and pipes that lead nowhere.

These glitch worlds exist for a simple reason: SMB1's level storage system is a marvel of 8-bit optimization, and when you force the game to read where it shouldn't, you get fascinating results.

Retro Game Mechanics Explained did a 4-part video series on this -- we're going to compile it all into one deep dive into the 6502 code of the best-selling game of its era.

The warm start: why Tennis's RAM survives in SMB1

Before we talk about level storage, we need to understand how SMB1 boots. Because the NES Tennis cart swap glitch relies entirely on the game's warm start / cold start detection system.

The 41 preserved bytes

When SMB1 detects a cold start (first power-on or power off/on), it wipes all the RAM. But when it detects a warm start (reset button, no power cycle), it preserves a 41-byte memory region:

; Les 41 bytes préservés en RAM lors d'un warm start
; Adresses $075F-$0787
;
; $075F : byte de démarrage (world - 1)    [1 byte]
; $0760 : flag de sélection de monde (B button) [1 byte]
; $0761-$0762 : inutilisé                    [2 bytes]
; $0763-$0768 : timer (6 digits, 3 affichés) [6 bytes]
; $0769-$076E : coins Luigi                   [6 bytes]
; $076F-$0774 : coins Mario                   [6 bytes]
; $0775-$077A : score Luigi                   [6 bytes]
; $077B-$0780 : score Mario                   [6 bytes]
; $0781-$0786 : top score (6 digits, 1 caché) [6 bytes]
; $0787 : le byte magique $A5                 [1 byte]

These 41 bytes serve a single purpose: allowing the player to continue on the same world after a game over. If you die in 6-3, the game writes world 6 into the start byte, and at the title screen, if you hold A + Start, you restart in 6-1.

The double warm start check

When SMB1 boots, it doesn't check a single criterion but two:

CheckWarmStart:
  ; 1. Vérifier le byte magique $A5 à $0787
  lda $0787
  cmp #$A5
  bne ColdStart        ; pas $A5 → cold start

  ; 2. Vérifier les 6 digits du top score ($0781-$0786)
  ;    Chaque digit doit être entre 0 et 9
  ldx #0
CheckLoop:
  lda $0781,x
  cmp #$0A
  bcs ColdStart        ; digit >= 10 → cold start
  inx
  cpx #6
  bne CheckLoop

  ; Si les deux conditions passent → warm start
  ; La RAM n'est pas effacée, le monde de départ est préservé
  jmp WarmStartBoot

Why a double check? Because the $A5 byte could be present by chance (another game leaving that value behind, or the default idle state of the RAM chip). By verifying that the top score digits are valid (0-9), it ensures the data is coherent.

Why Tennis is the only game that works

When you insert SMB1 for the first time (cold start), the game:

1. Wipes all the RAM → top score = 0, world byte = 0
2. Writes $A5 at address $0787

Then you swap to Tennis without turning off the console. Tennis:

• Doesn't clean RAM on boot (few NES games do)
• Doesn't write to the top score bytes → they stay at 0 (valid)
• Doesn't touch the $A5 byte → it stays intact
• Uses address $075F for the player's step counter

; Le footstep increment dans Tennis :
; À chaque pas du joueur sur le court, Tennis incrémente le byte à $075F.
; Ce même byte est utilisé par SMB1 comme "world number - 1".
;
; 0 pas  → world 0 → SMB1 = world 1
; 1-7 pas → world 1-7 → worlds normaux
; 8+ pas → world 8+ → glitch worlds !
;
; Le compteur ne s'incrémente que quand la musique s'arrête
; (les footstep sounds ne jouent pas pendant la musique).

When you put SMB1 back in:

1. The $A5 byte is still there (Tennis didn't touch it)
2. The top score digits are still 0 (valid)
3. The world byte is now 8+ (incremented by Tennis's footsteps)
4. SMB1 detects a warm start → preserves the corrupted world byte
5. Hold A + Start → world 9-1, world A-1, world 36-1, etc.

Why you have to boot Mario before Tennis

One subtlety: you have to boot SMB1 first, then Tennis, then SMB1 again. If you started directly with Tennis, the $A5 byte would never be written (Tennis doesn't write $A5), so the warm start detection would fail and the RAM would be wiped.

How SMB1 stores its levels in 40KB

Nintendo R&D4 had to solve a deceptively simple problem: represent levels that scroll horizontally with tiles, enemies, items, all within an ultra-tight ROM budget.

The solution is a separation into two completely independent data layers:

The tile layout (the level map)

Each level is defined by a pointer to a compressed tile structure in ROM. The compression is rudimentary but brilliant: a control byte followed by 1-3 data bytes.

The tile format uses a run-length system:

; Format tile SMB1 (simplifié)
; Chaque "commande" est un byte contrôle :
;
; $00-$7F : pose une tile, avance d'1 colonne
; $80-$BF : pose une tile répétée N fois (N = byte - $80 + 1)
; $C0-$FF : commande spéciale (fin de ligne, saut, changement de palette)

Exemple : pour dessiner 3 briques consécutives :
  $82 $01    ; répète la tile $01 (brick) 3 fois

Each level contains 13 rows of 16 tile columns (13x16 = 208 visible tiles). But the compressed format allows for much smaller data -- for example, the sky and empty columns take up almost no space.

The 6502 rendering loop:

; Décompression tile - loop principale
; Entrée : pointeur tile_data en $XX
; Sortie : tilemap niveau dans la RAM PPU

DecompressTile:
  lda (tile_ptr),y      ; lire byte contrôle
  iny
  cmp #$80
  bcc SingleTile        ; $00-$7F : tile unique
  cmp #$C0
  bcc RunLength         ; $80-$BF : run-length
  jmp SpecialCommand    ; $C0-$FF : commande spéciale

SingleTile:
  sta PPU_DATA          ; écrire la tile directement
  jmp Next

RunLength:
  sec
  sbc #$7E              ; N = control - $7E
  tax
  lda (tile_ptr),y      ; lire la tile à répéter
  iny
: sta PPU_DATA
  dex
  bne :-
  jmp Next

The sprite layout (enemies and objects)

In parallel, enemies and objects (question blocks, pipes, goombas, koopas) are stored in a completely separate structure. Each spawn is defined by 2 bytes:

; Format sprite SMB1
; Byte 0 : position X (en colonnes)
; Byte 1 : type de sprite + bits de page Y
; Y est dérivé de l'index dans la séquence

Une séquence de sprites :
  $01 $4B    ; goomba à la colonne 1
  $09 $4B    ; goomba à la colonne 9
  $10 $61    ; bloc ? à la colonne 16 (contient pièce)
  $15 $54    ; koopa verte à la colonne 21
  $FF        ; fin de séquence

Each level can reference up to 5 different sprite pages (well, 5 "screens" of 16 columns), but in practice most levels only use 2-3.

The pointer table

The genius of the design is the pointer table. Each level is stored as a pair of ROM addresses:

// Structure interne (simplifiée) du World Map
struct LevelPointer {
    uint16_t tile_ptr;   // Adresse ROM des données tiles
    uint16_t sprite_ptr; // Adresse ROM des données sprites
};

// 4 tables séparées, une par AreaType :
// 0 = Water, 1 = Overworld, 2 = Underground, 3 = Castle
LevelPointer level_table[4][128];

128 entries per table. 4 area types. 512 possible combinations, but only a fraction is used by the official game. The rest is uninitialized RAM or data being interpreted as pointers.

When the game loads a level, it does this:

; Chargement d'un niveau
; A = AreaType (0-3), X = LevelID (0-127)

LoadLevel:
  sta AREA_TYPE
  asl                  ; *2 pour offset dans table 16-bit
  tax
  lda LevelTable_TilePtr, x
  sta TILE_PTR
  lda LevelTable_TilePtr+1, x
  sta TILE_PTR+1       ; pointeur vers les tiles
  lda LevelTable_SpritePtr, x
  sta SPRITE_PTR
  lda LevelTable_SpritePtr+1, x
  sta SPRITE_PTR+1     ; pointeur vers les sprites
  jsr DecompressTiles

No validation. No check that the pointer is valid. The game reads the address from the table and decompresses whatever is at that address, end of story.

The 34 unique levels and the 7-bit ID system

SMB1 doesn't have 32 levels, but 34 unique levels. Many levels are duplicates (5-3 = 1-3 but with Bullet Bills) marked with a "hard mode" flag. The truly unique levels:

• Water (Type 0): 3 levels (2-2, 7-2, bonus area 5-2/6-2)
• Overworld (Type 1): 22 levels (including the 2 cloud bonus rooms)
• Underground (Type 2): 3 levels (including underground bonus rooms)
• Castle (Type 3): 6 levels
• + 1 cutscene room (before underground/water levels)
• + 1 warp zone from 4-2

Each level has a 7-bit ID. The 5 low bits = number within the subgroup, the 2 high bits = area type:

; Encodage 7-bit du Level ID
; Bits 6-5 : Type (00=Water, 01=Overworld, 10=Underground, 11=Castle)
; Bits 4-0 : Numéro dans le sous-groupe
;
; Water IDs      : $00-$02  (types 00, numéros 0-2)
; Overworld IDs  : $20-$35  (types 01, numéros 0-21)
; Underground IDs: $40-$42  (types 10, numéros 0-2)
; Castle IDs     : $60-$65  (types 11, numéros 0-5)
;
; ID $25 = %0100101 → type 01 (Overworld), numéro 5 → 1-1
; ID $23 = %0100011 → type 01 (Overworld), numéro 3 → 6-2

128 possible IDs ($00-$7F), only 34 assigned to real levels. Unused IDs point to whatever happens to be there.

The pointer tables: two lists, two orderings

The tile and sprite pointers aren't stored in the same order. The code uses two separate 16-bit lists (high byte / low byte in two distinct tables):

Ordre des pointeurs sprites :
  Index 0-5   : Castle (6 niveaux)
  Index 6-27  : Overworld (22 niveaux)
  Index 28-30 : Underground (3 niveaux)
  Index 31-33 : Water (3 niveaux)

Ordre des pointeurs tiles :
  Index 0-2   : Water (3 niveaux)
  Index 3-24  : Overworld (22 niveaux)
  Index 25-27 : Underground (3 niveaux)
  Index 28-33 : Castle (6 niveaux)

Why different orderings? No technical reason -- it's probably just how the data was organized during development. But it creates a fascinating consequence: when a level ID is invalid, the tile and sprite pointers load different levels, creating Frankenstein levels.

To navigate between these two lists, the game uses small offset tables (like a table of contents):

; Tables d'offset par type (Water, Overworld, Underground, Castle)
; Chaque entrée = index de début dans la liste correspondante

SpriteOffsetTable:
  .byte $1F, $06, $1C, $00    ; Water=31, Overworld=6, Underground=28, Castle=0

TileOffsetTable:
  .byte $00, $03, $19, $1C    ; Water=0, Overworld=3, Underground=25, Castle=28

To load level 6-2 (ID $23, Overworld number 3):

; 1. Type = 01 (Overworld) → index dans table d'offset = 1
; 2. Sprite offset = SpriteOffsetTable[1] = 6
;    Index final = 6 + 3 (numéro de niveau) = 9 → 10ème pointeur sprites
; 3. Tile offset = TileOffsetTable[1] = 3
;    Index final = 3 + 3 = 6 → 7ème pointeur tiles
; 4. Résultat : pointeur tiles $A619 + pointeur sprites $9ED0 = 6-2 ✓

Now, what happens with an invalid ID like $43 (Underground number 3, which doesn't exist)?

; ID $43, Type = 10 (Underground), numéro = 3
; Sprite offset = SpriteOffsetTable[2] = $1C = 28
;   Index = 28 + 3 = 31 → 32ème pointeur sprites = eau bonus 5-2 !
; Tile offset = TileOffsetTable[2] = $19 = 25
;   Index = 25 + 3 = 28 → 29ème pointeur tiles = 1-4 (Castle) !
;
; Résultat : un niveau souterrain avec les tiles de 1-4
; et les Bloopers de la zone eau de 5-2. Un vrai Frankenstein.

The world index table: why world 9 overflows

There's an 8-byte ROM table that gives the index of the first level in each world (1-8). And right after it, the table of 36 Level IDs for all levels in gameplay order.

; WorldIndexTable (8 bytes)
  .byte 0, 5, 10, 15, 20, 25, 28, 33
;   -> Monde 1 commence au niveau 0
;   -> Monde 2 commence au niveau 5
;   -> Monde 8 commence au niveau 33

; LevelIDTable (36 bytes)
  .byte $25, $28, $29, $26, $24, ... ; les 36 Level IDs

When trying to load world 9, the game reads the 9th byte of WorldIndexTable... which doesn't exist. It overflows by 1 byte into LevelIDTable, reads the value $25, then uses $25 as an index into LevelIDTable (37th entry) -- which overflows by 2 bytes into SpriteOffsetTable, and reads the value 6.

; World 9 :
;   1. WorldIndexTable[8] (overflow) → lit $25 dans LevelIDTable
;   2. LevelIDTable[37] (overflow) → lit le 2ème byte de SpriteOffsetTable = 6
;   3. ID = 6 → Water level number 6 (qui n'existe pas)
;   4. Tile pointer = pointeur water numéro 6 = tiles de 6-2
;   5. Sprite pointer = index 31+6 = 37 > 33 → pointeur invalide
;   6. Résultat : 6-2 sous l'eau avec des sprites glitchés
;      → world 9-1 !

For world G (16), the overflow goes even further and lands on Level ID $01, which is the cutscene level that precedes 1-2:

; World G (16) :
;   WorldIndexTable[15] → lit $01 dans LevelIDTable
;   LevelIDTable[1] = $29 (cutscene 1-2)
;   → world G-1 = la cutscene d'entrée de 1-2

Why the glitch worlds exist

The game has 32 "legitimate" levels (8 worlds x 4 levels). But the pointer table has 128 entries per area type. Entries beyond level 32 contain whatever is at those ROM addresses -- sometimes another level, sometimes sound data, sometimes RAM, sometimes anything at all.

Level ID $01 + AreaType 0 = Minus World

The most famous of the glitch worlds. Level ID $01 in AreaType 0 (water) points to:

• Tile pointer: $AE45 → the underwater area from 2-2/7-2
• Sprite pointer: $A171 → the sprites from 2-2/7-2

The result: a water level that looks like 2-2, but loops forever because the flagpole doesn't exist. No level end, no exit.

It's level 36-1 (or 36-1 in world $-1).

; Pourquoi le flagpole manque dans le Minus World :
; Les sprites de 2-2/7-2 ($A171) n'ont pas de flagpole
; dans leur séquence. Le jeu cherche le sprite $FD (flagpole)
; mais ne le trouve jamais → boucle infinie
;
; Le jeu continue de générer le niveau à l'infini
; jusqu'à ce que le timer atteigne zéro.

Pointers that point to RAM

When the tile pointer or sprite pointer points to a RAM address ($00-$7F) instead of ROM, the game tries to interpret the constantly changing RAM values as tiles:

; Exemple : Level ID $03 en Water
; Tile Pointer : $A46B (3-3 - valide)
; Sprite Pointer : $009D (pointe vers la RAM page zéro !)
;
; La RAM page zéro contient les registres du jeu,
; la position de Mario, l'état des compteurs...
; Le jeu décompresse ça comme une séquence de sprites,
; et le résultat c'est un niveau avec des ennemis
; qui sont en fait des valeurs de registres.

When the zero page changes (because Mario moves, the timer ticks, etc.), the level's "sprites" change too. That's why some glitch worlds have enemies that blink and constantly transform.

Level ID $36: the empty level (Overworld)

Level ID $36 in Overworld:

• Tile pointer: $AC35 (1-2)
• Sprite pointer: $A0D8 (1-2)

Result: nothing. The game loads the level but it's marked "no level" in RGMechEx's catalog. The tiles might be valid but the sprites point to a location that produces an empty or non-functional level.

Level ID $1D (Castle): the crash champion

Level ID $1D in Castle:

• Tile pointer: $A210 (4-4)
• Sprite pointer: $7EA0 (RAM!)

Sprite pointer in RAM = undefined sprites. The game tries to display a Spiny ball or Bullet Bill blaster in the first row of tiles. It crashes immediately.

; Quand le sprite pointer pointe vers la RAM,
; le jeu décompresse des bytes qui changent tout le temps
; comme des instructions "spawn". Le résultat :
; - Apparition d'objets inexistants (valeur undefined)
; - Crash PPU quand le sprite NES essaie d'afficher un tile invalide
; - Freeze complet de la console

The 256 cataloged glitch worlds

RGMechEx wrote a script that generates maps of every level, for all 4 area types, and all 128 IDs each.

The world counter is 8-bit (0-255). Worlds 1-8 are legitimate. That leaves 248 potential glitch worlds. Each glitch world corresponds to the first level of that world, and its Level ID is calculated by the WorldIndexTable overflow mechanism.

Out of the 128 possible IDs, only 68 are "first levels" of a world (accessible via the glitch world number). The other 60 are level 2+ or inaccessible.

Type	Playable unique IDs	IDs that crash	Empty IDs
Water (0)	~20	~60	~48
Overworld (1)	~30	~55	~43
Underground (2)	~15	~65	~48
Castle (3)	~25	~58	~45

Many IDs lead to the same level because the pointers land on the same ROM addresses. Level ID $28 (Overworld), for example -- tile pointer $A7CD (2-1) -- appears in 38 different glitch worlds, because its sprite pointer $9F51 points to a region of ROM that's used as padding/sound data reused by many IDs.

The 6 truly unique glitch levels

Out of the 19 accessible glitch level IDs, only 6 don't crash immediately on load:

World	Level ID	Description
E-1 (224)	$50	A single ? block over a chasm. Mario dies instantly.
W	$57	Mario spawns stuck, unable to move.
42 (133)	$50	Cloud tunnel that traps Mario if he goes far enough.
62 (131, 240)	$4D	Frozen castle: Mario spawns at the top, can't fall → stuck.
127	$4B	Underground tunnel, but crashes if you go too far.
137	$4B	Activates cutscene auto-scrolling. Mario meets a single brick block that blocks him forever.

Six glitch worlds out of 248 that produce something truly new. The rest are normal levels with the wrong area type, or black screens.

The level format in detail

Let's dive into the exact level data format, to understand why glitch levels hold up (or don't).

The level header: 2 bytes, 6 properties

Each level starts with a 2-byte header that controls 6 properties:

; Byte 0 : timer + Y start + modifier
;   Bits 7-6 : timer (00=inchangé, 01=200, 10=300, 11=400)
;   Bits 5-3 : Y start Mario (111/110 = autowalk)
;   Bits 2-0 : level type modifier
;              000=default, 001=waves, 010=brick wall,
;              011=water bottom, 100=night, 101=snow,
;              110=snow night, 111=gray night

; Byte 1 : platform + background + floor pattern
;   Bits 7-6 : special platform (00=tree, 01=mushroom,
;                                 10=Bullet Bill, 11=cloud)
;   Bits 5-4 : background (00=none, 01=clouds,
;                           10=montains, 11=fences)
;   Bits 3-0 : floor pattern initial (0-15)

The modifier type controls visual variations: the waves at the top of water levels, the brick background of 8-3, the night palette of 4-3, the snow of 6-2, etc.

Tile objects: 2 bytes, Next Screen Flag, 3-slot queue

After the header comes a list of tile objects, each object is 2 bytes. The byte $FD marks the end of the list.

; Format objet tile (16 bits) :
; Byte 0 :
;   Bits 7-4 : X position (colonne 0-15)
;   Bits 3-0 : Y position
;     Y=0-11  : position Y normale
;     Y=12    : objets spéciaux (trous, ponts, rope, ? blocks)
;     Y=13    : screen skip / objets spéciaux 2
;     Y=14    : changement de modifier/scenery/floor
;     Y=15    : objets spéciaux 3 (château, escaliers, gros tuyau)

; Byte 1 :
;   Bit  7   : NEXT SCREEN FLAG
;   Bits 6-4 : type d'objet (0-7)
;   Bits 3-0 : largeur/hauteur / sous-type

When the "next screen" bit is set, the current working column is incremented by 1. This allows placing objects beyond the first 16 columns. Objects must be listed in order (left to right) because the game loads them sequentially:

; La routine de chargement a DEUX phases par colonne :
; Phase 1 : chercher les nouveaux objets qui commencent sur cette colonne
;            et les ajouter à la file d'attente (queue)
; Phase 2 : traiter chaque objet dans la queue en dessinant les tiles,
;            et retirer ceux qui finissent sur cette colonne

The queue holds exactly 3 slots. Direct consequence: you can't have more than 3 objects starting on the same column. If the queue is full, the 4th object is ignored and never loaded.

That's why well-designed levels avoid stacking too many objects. Example in 1-2: the column with the 1up block in the ceiling + the bricks next to it are split into two distinct objects to respect the 3-slot limit.

Special Y positions: 12, 13, 14, 15

When Y=12, the object has no Y position (it's hardcoded by type):

; Y=12 : objets sans Y position
;   Type 0 : trou (supprime le sol)
;   Type 1 : rope de plateforme mobile
;   Types 2-4 : ponts à Y fixe
;   Type 5 : trou avec eau/lave
;   Types 6-7 : rangées de ? blocks

When Y=13, two subgroups. If bit 6 of byte 1 is set:

; Y=13, bit6=1 : objets spéciaux
;   0 = L-pipe (cutscene), 1 = flagpole, 2-3 = pont/axe/hamer (fin château)
;   4 = stop screen, 5 = random enemies, 6 = loop level, 7+ = crash possible

If bit6=0, the 5 low bits encode a screen skip (jump directly to screen N, without going through the next screen flag one by one).

When Y=14: same principle with bit6=1 to change the modifier type, bit6=0 to change the background + floor pattern.

Floor patterns: 16 ground motifs

The ground in levels isn't made of individual objects. SMB1 uses floor patterns, a background motif that applies to all columns until the next change:

; Floor patterns (4 bits = 16 possibilités)
;   0 = vide total
;   1 = sol 2 tiles haut
;   2 = sol 1 tile haut
;   3 = sol + bottom
;   4 = sol + bottom 2
;   5 = sol 1/2 tile
;   6 = 3/4 sol
;   ... jusqu'à 15 = rempli total (sol + plafond)

That's why pits are objects: they override the floor pattern on a specific column without having to change the pattern for everything else.

The 256-byte limit and the repeat

All tile data in a level fits within 256 bytes maximum. The 6502 Y register is used as an index, and it's 8-bit. If the game reaches the end of the data without finding the $FD byte, it loops back to the start and repeats the 256 bytes forever:

; Index Y = 8 bits → max 256 bytes de données tiles
; Si Y overflow (255 → 0) sans rencontrer $FD → repeat
; Même chose pour les sprites, mais les objets pipe (3 bytes)
; décalent la parité de l'index à chaque chargement.

Some glitch levels exploit this repeat to generate levels that last "indefinitely".

The sprite system: 2 bytes + pipe transitions

Sprites follow a similar format, but without a header and with a few key differences. The byte $FF marks the end of the list.

; Format sprite (2 bytes) :
; Byte 0 : position X (colonne)
; Byte 1 :
;   Bit 7 : NEXT SCREEN FLAG
;   Bits 6-0 : type de sprite
;       Certains types incluent : goomba, koopa, Blooper,
;       Bullet Bill, Lakitu, Spiny, plateformes,
;       commande warp zone, toad/princesse,
;       commandes de spawn de groupes d'ennemis

The low bit of byte 1 is the hard level flag: when set to 1, the sprite only appears in levels >= 5-3. That's how "hard mode" levels are created.

Y position 15 = screen skip (same as tiles). Y position 14 = pipe transition (3 bytes):

; Sprite Y=14 : pipe/vine transition (3 bytes !)
;   Byte 0 : position X
;   Byte 1 : bits 6-0 = Level ID 7-bit (destination)
;   Byte 2 : bits 4-0 = screen de destination
;            bits 7-5 = world où cette transition est valide
;
; Pourquoi un world ? Les bonus rooms sont réutilisées entre mondes.
; Exemple : la salle bonus de 1-1 est aussi utilisée par 2-1 et 7-1.
; Cette salle a 3 transitions, une par monde, pour que Mario
; réapparaisse au bon endroit.

Sprites don't have a queue system. The only limit is that no more than 4 sprites can be loaded simultaneously in the spawn area (just off-screen to the right). Beyond that, sprites are ignored.

How to access the glitch worlds

There are two main methods.

The classic method: the wall clip

The wall clip (passing through walls) lets you get out of the normal level and walk to the hidden warp zone. By manipulating the world counter via RAM, you can load any Level ID.

The technique:

1. World 1-2: go into the hidden end pipe
2. Perform the wall clip on the right wall
3. Walk through the void to the warp zone
4. The game interprets the values as worlds

But this method only gives access to a small portion of the glitch worlds.

The extreme method: NES Tennis cart swap

See the "warm start" section above for the full details. In short: Tennis's step counter writes to the same RAM byte as SMB1's start world, and the warm start detection preserves that value.

The tinkerer's corner: code to explore everything

If you want to explore all the glitches yourself in an emulator, you can patch the Level ID directly:

; Patch pour FCEUX / Mesen :
; Adresse RAM $075F = Level ID actuel
; Adresse RAM $0760 = Area Type (0=Water, 1=Overworld, 2=Underground, 3=Castle)

; Exemple : charger le Level 57 (0x39) en Overworld
; Dans l'émulateur, ouvrir le traceur mémoire et écrire :
; $075F = 0x39
; $0760 = 0x01
; Puis entrer dans un tuyau de warp ou mourir et recommencer
; → Le jeu charge le niveau ID $39 en Overworld

RGMechEx published the complete list of 128 levels x 4 types with auto-generated maps on rgmechex.com. Each entry shows the tile pointer, the sprite pointer, and a visual map of the level.

The most wtf levels

Level ID $1F (Water): 15 glitch worlds in one

Tile pointer $A302 (3-4) combined with sprite pointer $02A0 gives 15 different glitch worlds (D-1, J-1, Y-1, Z-1, 55-1, 73-1...). Explanation: the sprite pointer points to a region of ROM that contains data close enough to valid sprites to produce playable results, but combining the 3-4 castle tiles with overworld sprites creates an absurd rendering.

Level ID $28 (Overworld): 38 glitch worlds = record

The absolute record. 38 glitch world entries point to the same level (2-1 tiles + $9F51 sprites). Why? Because the sprite pointer $9F51 falls into a ROM region used as padding/sound data reused by many IDs.

Level ID $49 (Underground): the FDS level

Tile pointer $76AE + sprite pointer $1C9D. The tile pointer points to the ROM region reserved for the Famicom Disk System version. Result: a level with tiles that don't exist in the standard cartridge. It's the level that produces world 52-1 and 196-1.

Level ID $00-$02: the real bonus levels

These IDs are used by legitimate sub-levels in the game:

• $00: underwater area of 5-2/6-2 (used by H-1, 39-1)
• $01: the water of 2-2/7-2 (the Minus World, 36-1)
• $02: sub-level of 8-4 (136-1, 151-1, 215-1)

The difference between a "bonus" level accessible normally and a glitch world is that warp zones check the current world:

; Vérification warp zone (simplifié)
; Le jeu vérifie que le monde cible est entre 1 et 8
CheckWarp:
  lda TARGET_WORLD
  cmp #1
  bcc InvalidWarp       ; < 1 → refusé
  cmp #9
  bcs InvalidWarp       ; > 8 → refusé
  ; world valide entre 1 et 8 uniquement
  jmp DoWarp

Glitch worlds with numbers > 8 or 0 can't be reached through normal pipes. You need the wall clip or the cart swap.

Why some levels crash: the jump tables

When the game loads a tile object, it uses its type as an index into a jump table:

; Jump table des objets tiles standards (types 0-11)
JumpTable_TileObjects:
  .word Obj_Special       ; type 0 : bloc ?, hidden, flagpole...
  .word Obj_Platform      ; type 1 : plateforme spéciale
  .word Obj_BrickRow      ; type 2 : rangée de briques
  .word Obj_BlockRow      ; type 3 : rangée de blocks
  .word Obj_CoinRow       ; type 4 : rangée de pièces
  .word Obj_BrickCol      ; type 5 : colonne de briques
  .word Obj_BlockCol      ; type 6 : colonne de blocks
  .word Obj_Pipe          ; type 7 : tuyau
  .word Obj_8             ; type 8
  .word Obj_9             ; type 9
  .word Obj_10            ; type 10
  .word Obj_11            ; type 11

If an object has an invalid type (>=12), the game jumps to a pointer that doesn't exist in this table. 4 possible outcomes:

1. Valid pointer → the object loads normally
2. Pointer to another jump table (overlap) → a different object appears. Example: type 12 points to the Y=13 table, which produces an L-pipe.
3. Pointer to executable code → execution of random code (probable crash)
4. Explicit placeholder (NOP) → the object does nothing (some sprites are like this, producing enemies that hover in place without moving)

Glitch level ID $58 (the crashing tunnel): its sprite pointer points to a memory region that doesn't exist on a NES without mapper ROM. The game tries to load the same Koopa 5 times per frame at position (0,0), which saturates the PPU and causes a freeze.

; Pourquoi ID $58 crashe :
; Sprite pointer → adresse invalide (hors espace NES standard)
; → Le jeu lit des bytes indéterminés comme des types de sprite
; → Le Koopa $00 (type invalide sans handler) boucle en appel récursif
; → Stack overflow 6502 → freeze

The pipe warp paradox

Remember the check target_world BETWEEN 1 AND 8. Even if you find a pipe in a glitch world, the game checks that the destination world is between 1 and 8. Glitch worlds have numbers > 8 (36-1, 255-1...), so the warp fails.

That's also why the Minus World has no end: the flagpole isn't present in the sprites, and the pipes lead nowhere.

The 5-objects-in-one-column trick

There's an edge case that lets you bypass the 3-objects-per-column limit. When the queue gets stuck (slots full + next object missing the next screen flag), the game "preprocesses" the current column in a loop until it finds an object with the next screen flag. During each preprocessing pass:

; Pendant le prétraitement de colonne :
; 1. Les objets dans la queue voient leur largeur restante
;    décrémentée à chaque "fausse avancée" de colonne
; 2. Si un objet atteint largeur=0, il quitte la queue
; 3. Un slot libéré peut être rempli par un nouvel objet
;    ajouté dans la même colonne

; Résultat : jusqu'à 5 objets peuvent être traités sur la même colonne.
; Technique : placer 2 objets qui traversent la screen boundary
; (slots 1 et 2), 1 objet dummy en X < précédent (bloque la queue),
; puis 3 objets à X=0 de l'écran suivant (dont un avec next screen flag).

This is called a "queue skip" and it's used by some ROM hackers to create levels denser than the format normally allows.

The differences between versions

Famicom Disk System

The FDS version of SMB1 has a different memory map. All level pointers are shifted, but the data is the same. What changes: the glitch world indices are completely different:

FDS World 36 → Level ID $09 (eau version de 5-3)
  → Le flagpole est présent ! On peut finir le niveau.
  → Ensuite : $27 (7-3 normal) → $44 (4-4 underground)
  → $44 est finissable → la hache fonctionne → fin du jeu !
  
Le Minus World FDS est donc un "bonus world" qui peut mener
à la complétion du jeu, contrairement à la version NES.

My favorite FDS level: ID $5F, an underground version of the second half of 3-3 in a low tunnel (too bad it's an autoscroller).

The Lost Levels (Super Mario Bros. 2 Japanese)

Lost Levels changes a lot of things:

1. Same tiles/sprites ordering: no more Frankenstein levels (tiles and sprites load the same level even with an invalid ID)
2. A single 16-bit pointer table instead of two separate high/low tables
3. 4 disk files: the ROM was split for FDS:
   • File 1: worlds 1-4
   • File 2: worlds 5-8
   • File 3: world 9 + sound engine
   • File 4: worlds A-D (completely different pointer table)
4. Same Level ID = 4 possible levels depending on which file is loaded
5. No more Tennis glitch: the continue option (continue on the same world after game over) makes the warm start unnecessary, and the game resets immediately if world > 9
6. New objects: poison mushroom, invisible block, invisible fire flower, upside-down pipes, wind -- but inserted in the middle of existing lists → backward incompatibility with SMB1
7. Piranha Plants always red after world 4, springboards green only in worlds 2/B/3/C/7

Super Mario All-Stars (SNES)

Direct port with the same 6502 routines (the SNES runs NES code in a compatible mode):

• Warp zone fixed: no more Minus World (entering the left pipe before the text leads to the correct world)
• Crashing: most glitch levels crash (except ID $6A and 9-1)
• Castle objects added: more unique renderings
• But: the 4-2 wrong warp still works (not patched!)

The 4-2 wrong warp: an object placement bug

In 4-2, there are two pipe transition objects: the vine (warp zone) and the pipe (coin cash room). The first transition object (the vine) is placed well before the vine appears on screen. The second (the pipe) is placed too late in the level.

; Timing des transitions dans 4-2 :
; Objet transition 1 (vigne → warp zone) : placé 3 écrans avant la vigne
; Objet transition 2 (tuyau → coin cash) : placé 1 écran après le tuyau
;
; Normalement le premier objet est désactivé avant que Mario
; n'atteigne le tuyau. Mais si Mario va vite (ou utilise
; le raccourci du bloc B+right), la transition de la vigne
; est toujours active quand il touche le tuyau !
; → Le jeu charge la warp zone au lieu du coin cash.
;
; Si l'objet avait été placé juste après la vigne mais avant
; le tuyau, le bug n'existerait pas.

The loop levels

How do the loops work (8-4, 7-4)? The level has checkpoints with hardcoded screen numbers and Y positions:

; Checkpoint : {screen_number, vertical_position}
; Si Mario passe ce checkpoint à la bonne hauteur → niveau continue
; Sinon → warp back de 4 écrans (64 blocks)
;
; Pour faire une boucle infinie : vertical_position = $F0
; (en dessous du bas de l'écran) → impossible de valider.
;
; Les checkpoints sont simples (un seul flag) sauf pour world 7
; qui utilise des triplets (3 flags, il faut en échouer au moins 1)
;
; Le warp back est rude : offset de tile data réglé à une valeur
; hardcodée, offset de sprite data remis à 0. Les ennemis présents
; sont déchargés instantanément → les firebars disparaissent.

Changing the format, not the code

One of the most fascinating lessons from this architecture is that SMB1's developers managed to create a highly expressive level system without ever touching the 6502 rendering code. All variation between levels comes from data (pointers, objects, sprites, floor patterns), not code.

The 256 glitch worlds exist because the pointer tables are sized for 128 entries x 4 types, and the game never validates the values it reads. When a pointer lands in RAM, the game interprets Mario's registers as tiles. When a pointer lands in sound data, the game plays music in the form of level design. And when the jump tables overflow, the game executes anything until it crashes.

What we can learn from all this

1. Tile/sprite separation: complete independence of the two layers, with different storage orderings creating unique Frankenstein levels
2. RLE compression + object system: levels aren't bitmaps but lists of placed objects, with floor patterns for the ground
3. 3-slot queue: strict hardware (and level design) limitation
4. No validation: the game trusts pointers and jump tables, producing either playable glitches or crashes
5. 256 bytes max: the limit of the 6502 Y register, causing data to repeat if you go too far
6. Warm start / cold start: a "continue" system that opened the door to the Tennis → Mario cart swap

The best part: all of this is 6502 code that fits in 40KB. No abstraction layer, no memory access validation, no exception handler. If the pointer is garbage, the game crashes. And the crashes, we call them glitch worlds.

The 3 key takeaways

1. Glitch worlds are pointers gone wrong -- The game has 128 IDs x 4 area types, but only 34 unique levels. When the world number is corrupted (by Tennis or wall clip), the game loads a pointer designed for a different level, and the 512 possible combinations produce unpredictable results.

2. The Minus World is a warp bug combined with corruption -- The left pipe in 1-2, if activated before the text appears, loads world 36 (0x24). This world points to Level ID $01 (water from 2-2), a level with no flagpole. And since there's no pipe transition for world 36, the level loops forever. The lack of validation creates the icon.

3. Tennis → Mario, 15 years before OoT → Paper Mario -- NES RAM survives a cartridge swap thanks to capacitors and SMB1's warm start / cold start system. Tennis's step counter (which increments a RAM byte while playing the footstep sound) lands exactly on the world number address. The top score digits have to stay at 0, the $A5 byte has to be intact, and the game has to detect a warm start -- a perfect confluence of circumstances that only worked with Tennis.

The original videos by Retro Game Mechanics Explained are an absolute labor of love -- the level of detail on the 6502 disassembly, the auto-generated maps of every level, the cart swap and warm start explanations. If you haven't watched the series, check it out, it's short and every minute is dense.

The map source code is available on rgmechex.com, and the complete SMB1 disassembly is open source across many repos. 40 years ago, Japanese programmers wrote this level system in 6502 with zero unit tests and zero bug trackers, and we're still learning stuff by opening their code today.

Introduction

Super Mario Bros., c'est 40 kilooctets de ROM. Huit mondes, 32 niveaux, des ennemis, de la musique, des power-ups, tout tient là-dedans.

Mais si tu ouvres un émulateur et que tu trifouilles les bonnes bytes, tu peux charger le niveau 36-1. Ou le 255-1. Ou atterrir dans un monde où tout est fait de sprites de Bowser et de tuyaux qui mènent nulle part.

Ces glitch worlds existent pour une raison simple : le système de stockage des niveaux de SMB1 est une merveille d'optimisation 8-bit, et quand on force le jeu à lire là où il faut pas, ça donne des résultats fascinants.

Retro Game Mechanics Explained a fait une série de 4 vidéos là-dessus -- on va les compiler en une seule plongée dans le code 6502 du jeu le plus vendu de son époque.

Le warm start : pourquoi la RAM de Tennis survit dans SMB1

Avant de parler de stockage de niveaux, il faut comprendre comment SMB1 démarre. Parce que le glitch du cart swap NES Tennis repose entièrement sur le système de détection warm start / cold start du jeu.

Les 41 bytes préservés

Quand SMB1 détecte un cold start (première mise sous tension ou power off/on), il efface toute la RAM. Mais quand il détecte un warm start (reset bouton, pas de coupure d'alimentation), il préserve une zone mémoire de 41 bytes :

; Les 41 bytes préservés en RAM lors d'un warm start
; Adresses $075F-$0787
;
; $075F : byte de démarrage (world - 1)    [1 byte]
; $0760 : flag de sélection de monde (B button) [1 byte]
; $0761-$0762 : inutilisé                    [2 bytes]
; $0763-$0768 : timer (6 digits, 3 affichés) [6 bytes]
; $0769-$076E : coins Luigi                   [6 bytes]
; $076F-$0774 : coins Mario                   [6 bytes]
; $0775-$077A : score Luigi                   [6 bytes]
; $077B-$0780 : score Mario                   [6 bytes]
; $0781-$0786 : top score (6 digits, 1 caché) [6 bytes]
; $0787 : le byte magique $A5                 [1 byte]

Ces 41 bytes servent à une seule fonctionnalité : permettre au joueur de continuer au même monde après un game over. Si tu meurs en 6-3, le jeu écrit le monde 6 dans le byte de démarrage, et au title screen, si tu maintiens A + Start, tu recommences en 6-1.

La double vérification du warm start

Quand SMB1 boote, il ne vérifie pas un seul critère mais deux :

CheckWarmStart:
  ; 1. Vérifier le byte magique $A5 à $0787
  lda $0787
  cmp #$A5
  bne ColdStart        ; pas $A5 → cold start

  ; 2. Vérifier les 6 digits du top score ($0781-$0786)
  ;    Chaque digit doit être entre 0 et 9
  ldx #0
CheckLoop:
  lda $0781,x
  cmp #$0A
  bcs ColdStart        ; digit >= 10 → cold start
  inx
  cpx #6
  bne CheckLoop

  ; Si les deux conditions passent → warm start
  ; La RAM n'est pas effacée, le monde de départ est préservé
  jmp WarmStartBoot

Pourquoi une double vérification ? Parce que le byte $A5 pourrait être présent par hasard (un autre jeu qui laisse cette valeur, ou l'état de repos par défaut du chip RAM). En vérifiant que les digits du top score sont valides (0-9), on s'assure que les données sont cohérentes.

Pourquoi Tennis est le seul jeu qui marche

Quand on insère SMB1 pour la première fois (cold start), le jeu :

1. Efface toute la RAM → top score = 0, world byte = 0
2. Écrit $A5 à l'adresse $0787

Ensuite, on swap sur Tennis sans éteindre la console. Tennis :

• Ne nettoie pas la RAM au démarrage (peu de jeux NES le font)
• N'écrit pas sur les bytes du top score → ils restent à 0 (valides)
• Ne touche pas au byte $A5 → il reste présent
• Utilise l'adresse $075F pour le compteur de pas du joueur

; Le footstep increment dans Tennis :
; À chaque pas du joueur sur le court, Tennis incrémente le byte à $075F.
; Ce même byte est utilisé par SMB1 comme "world number - 1".
;
; 0 pas  → world 0 → SMB1 = world 1
; 1-7 pas → world 1-7 → worlds normaux
; 8+ pas → world 8+ → glitch worlds !
;
; Le compteur ne s'incrémente que quand la musique s'arrête
; (les footstep sounds ne jouent pas pendant la musique).

Quand on remet SMB1 :

1. Le byte $A5 est toujours là (Tennis ne l'a pas touché)
2. Les digits du top score sont toujours 0 (valides)
3. Le world byte vaut maintenant 8+ (incrémenté par les pas de Tennis)
4. SMB1 détecte un warm start → préserve le world byte corrompu
5. Maintenir A + Start → world 9-1, world A-1, world 36-1, etc.

Pourquoi il faut booter Mario avant Tennis

Une subtilité : il faut d'abord booter SMB1, puis Tennis, puis SMB1 à nouveau. Si tu commençais directement par Tennis, le byte $A5 ne serait jamais écrit (Tennis n'écrit pas $A5), donc la détection warm start échouerait et la RAM serait effacée.

Comment SMB1 stocke ses niveaux dans 40KB

Nintendo R&D4 a dû résoudre un problème simple en apparence : représenter des niveaux qui scrollent horizontalement avec des tiles, des ennemis, des items, le tout dans un budget ROM ultra-serré.

La solution, c'est une séparation en deux couches de données complètement indépendantes :

Le tile layout (la carte du niveau)

Chaque niveau est défini par un pointeur vers une structure de tiles compressée en ROM. La compression est rudimentaire mais géniale : un byte "contrôle" suivi de 1-3 bytes de données.

Le format tile utilise un système de runs (RLE-like) :

; Format tile SMB1 (simplifié)
; Chaque "commande" est un byte contrôle :
;
; $00-$7F : pose une tile, avance d'1 colonne
; $80-$BF : pose une tile répétée N fois (N = byte - $80 + 1)
; $C0-$FF : commande spéciale (fin de ligne, saut, changement de palette)

Exemple : pour dessiner 3 briques consécutives :
  $82 $01    ; répète la tile $01 (brick) 3 fois

Chaque niveau contient 13 lignes de 16 colonnes de tiles (13×16 = 208 tiles visibles). Mais le format compressé permet de descendre bien plus bas -- par exemple, le ciel et les colonnes vides ne prennent presque pas de place.

La boucle de rendu en 6502 :

; Décompression tile - loop principale
; Entrée : pointeur tile_data en $XX
; Sortie : tilemap niveau dans la RAM PPU

DecompressTile:
  lda (tile_ptr),y      ; lire byte contrôle
  iny
  cmp #$80
  bcc SingleTile        ; $00-$7F : tile unique
  cmp #$C0
  bcc RunLength         ; $80-$BF : run-length
  jmp SpecialCommand    ; $C0-$FF : commande spéciale

SingleTile:
  sta PPU_DATA          ; écrire la tile directement
  jmp Next

RunLength:
  sec
  sbc #$7E              ; N = control - $7E
  tax
  lda (tile_ptr),y      ; lire la tile à répéter
  iny
: sta PPU_DATA
  dex
  bne :-
  jmp Next

Le sprite layout (les ennemis et objets)

Parallèlement, les ennemis et objets (blocs ?, tuyaux, goombas, koopas) sont stockés dans une structure complètement séparée. Chaque spawn est défini par 2 bytes :

; Format sprite SMB1
; Byte 0 : position X (en colonnes)
; Byte 1 : type de sprite + bits de page Y
; Y est dérivé de l'index dans la séquence

Une séquence de sprites :
  $01 $4B    ; goomba à la colonne 1
  $09 $4B    ; goomba à la colonne 9
  $10 $61    ; bloc ? à la colonne 16 (contient pièce)
  $15 $54    ; koopa verte à la colonne 21
  $FF        ; fin de séquence

Chaque niveau peut référencer jusqu'à 5 pages de sprites différentes (enfin, 5 "screens" de 16 colonnes), mais en pratique la plupart des niveaux n'en utilisent que 2-3.

La table des pointeurs

Le génie du design, c'est la table de pointeurs. Chaque niveau est stocké comme une paire d'adresses ROM :

// Structure interne (simplifiée) du World Map
struct LevelPointer {
    uint16_t tile_ptr;   // Adresse ROM des données tiles
    uint16_t sprite_ptr; // Adresse ROM des données sprites
};

// 4 tables séparées, une par AreaType :
// 0 = Water, 1 = Overworld, 2 = Underground, 3 = Castle
LevelPointer level_table[4][128];

128 entrées par table. 4 types de zone. 512 combinaisons possibles, mais seulement une fraction est utilisée par le jeu officiel. Le reste, c'est de la RAM non initialisée ou des données qui sont interprétées comme des pointeurs.

Quand le jeu charge un niveau, il fait ça :

; Chargement d'un niveau
; A = AreaType (0-3), X = LevelID (0-127)

LoadLevel:
  sta AREA_TYPE
  asl                  ; *2 pour offset dans table 16-bit
  tax
  lda LevelTable_TilePtr, x
  sta TILE_PTR
  lda LevelTable_TilePtr+1, x
  sta TILE_PTR+1       ; pointeur vers les tiles
  lda LevelTable_SpritePtr, x
  sta SPRITE_PTR
  lda LevelTable_SpritePtr+1, x
  sta SPRITE_PTR+1     ; pointeur vers les sprites
  jsr DecompressTiles

Pas de validation. Pas de check que le pointeur est valide. Le jeu lit l'adresse dans la table et décompresse ce qui se trouve à cette adresse, point final.

Les 34 niveaux uniques et le système d'ID 7-bit

SMB1 n'a pas 32 niveaux, mais 34 niveaux uniques. Beaucoup de niveaux sont des doublons (5-3 = 1-3 mais avec des Bullet Bills) marqués par un drapeau "hard mode". Les vrais niveaux uniques :

• Eau (Type 0) : 3 niveaux (2-2, 7-2, zone bonus 5-2/6-2)
• Overworld (Type 1) : 22 niveaux (dont les 2 salles nuages bonus)
• Underground (Type 2) : 3 niveaux (dont les salles bonus souterraines)
• Castle (Type 3) : 6 niveaux
• + 1 cutscene room (avant les niveaux sous-terrains/eau)
• + 1 warp zone de 4-2

Chaque niveau a un ID sur 7 bits. Les 5 bits de poids faible = numéro dans le sous-groupe, les 2 bits de poids fort = type de zone :

; Encodage 7-bit du Level ID
; Bits 6-5 : Type (00=Water, 01=Overworld, 10=Underground, 11=Castle)
; Bits 4-0 : Numéro dans le sous-groupe
;
; Water IDs      : $00-$02  (types 00, numéros 0-2)
; Overworld IDs  : $20-$35  (types 01, numéros 0-21)
; Underground IDs: $40-$42  (types 10, numéros 0-2)
; Castle IDs     : $60-$65  (types 11, numéros 0-5)
;
; ID $25 = %0100101 → type 01 (Overworld), numéro 5 → 1-1
; ID $23 = %0100011 → type 01 (Overworld), numéro 3 → 6-2

128 IDs possibles ($00-$7F), seulement 34 assignés à des vrais niveaux. Les IDs inutilisés pointent vers n'importe quoi.

Les tables de pointeurs : deux listes, deux ordres

Les pointeurs tiles et sprites ne sont pas stockés dans la même ordre. Le code utilise deux listes 16-bit séparées (high byte / low byte dans deux tables distinctes) :

Ordre des pointeurs sprites :
  Index 0-5   : Castle (6 niveaux)
  Index 6-27  : Overworld (22 niveaux)
  Index 28-30 : Underground (3 niveaux)
  Index 31-33 : Water (3 niveaux)

Ordre des pointeurs tiles :
  Index 0-2   : Water (3 niveaux)
  Index 3-24  : Overworld (22 niveaux)
  Index 25-27 : Underground (3 niveaux)
  Index 28-33 : Castle (6 niveaux)

Pourquoi des ordres différents ? Aucune raison technique -- c'est probablement comme ça que les données ont été organisées pendant le développement. Mais ça crée une conséquence fascinante : quand un ID de niveau est invalide, les pointeurs tiles et sprites chargent des niveaux différents, créant des Frankenstein levels.

Pour naviguer entre ces deux listes, le jeu utilise des petites tables d'offset (comme une table des matières) :

; Tables d'offset par type (Water, Overworld, Underground, Castle)
; Chaque entrée = index de début dans la liste correspondante

SpriteOffsetTable:
  .byte $1F, $06, $1C, $00    ; Water=31, Overworld=6, Underground=28, Castle=0

TileOffsetTable:
  .byte $00, $03, $19, $1C    ; Water=0, Overworld=3, Underground=25, Castle=28

Pour charger le niveau 6-2 (ID $23, Overworld numéro 3) :

; 1. Type = 01 (Overworld) → index dans table d'offset = 1
; 2. Sprite offset = SpriteOffsetTable[1] = 6
;    Index final = 6 + 3 (numéro de niveau) = 9 → 10ème pointeur sprites
; 3. Tile offset = TileOffsetTable[1] = 3
;    Index final = 3 + 3 = 6 → 7ème pointeur tiles
; 4. Résultat : pointeur tiles $A619 + pointeur sprites $9ED0 = 6-2 ✓

Maintenant, que se passe-t-il avec un ID invalide comme $43 (Underground numéro 3, qui n'existe pas) ?

; ID $43, Type = 10 (Underground), numéro = 3
; Sprite offset = SpriteOffsetTable[2] = $1C = 28
;   Index = 28 + 3 = 31 → 32ème pointeur sprites = eau bonus 5-2 !
; Tile offset = TileOffsetTable[2] = $19 = 25
;   Index = 25 + 3 = 28 → 29ème pointeur tiles = 1-4 (Castle) !
;
; Résultat : un niveau souterrain avec les tiles de 1-4
; et les Bloopers de la zone eau de 5-2. Un vrai Frankenstein.

Le world index table : pourquoi world 9 overflow

Il y a une table ROM de 8 bytes qui donne l'index du premier niveau de chaque monde (1-8). Et juste après, la table des 36 Level IDs de tous les niveaux dans l'ordre de jeu.

; WorldIndexTable (8 bytes)
  .byte 0, 5, 10, 15, 20, 25, 28, 33
;   -> Monde 1 commence au niveau 0
;   -> Monde 2 commence au niveau 5
;   -> Monde 8 commence au niveau 33

; LevelIDTable (36 bytes)
  .byte $25, $28, $29, $26, $24, ... ; les 36 Level IDs

Quand on essaie de charger world 9, le jeu lit le 9ème byte de WorldIndexTable... qui n'existe pas. Il overflow de 1 byte dans LevelIDTable, lit la valeur $25, puis utilise $25 comme index dans LevelIDTable (37ème entrée) -- ce qui overflow à nouveau de 2 bytes dans SpriteOffsetTable, et lit la valeur 6.

; World 9 :
;   1. WorldIndexTable[8] (overflow) → lit $25 dans LevelIDTable
;   2. LevelIDTable[37] (overflow) → lit le 2ème byte de SpriteOffsetTable = 6
;   3. ID = 6 → Water level number 6 (qui n'existe pas)
;   4. Tile pointer = pointeur water numéro 6 = tiles de 6-2
;   5. Sprite pointer = index 31+6 = 37 > 33 → pointeur invalide
;   6. Résultat : 6-2 sous l'eau avec des sprites glitchés
;      → world 9-1 !

Pour world G (16), l'overflow va encore plus loin et tombe sur le Level ID $01, qui est le niveau cutscene qui précède 1-2 :

; World G (16) :
;   WorldIndexTable[15] → lit $01 dans LevelIDTable
;   LevelIDTable[1] = $29 (cutscene 1-2)
;   → world G-1 = la cutscene d'entrée de 1-2

Pourquoi les glitch worlds existent

Le jeu a 32 niveaux "légitimes" (8 mondes × 4 niveaux). Mais la table de pointeurs fait 128 entrées par type de zone. Les entrées au-delà du niveau 32 contiennent ce qui se trouve en ROM à ces adresses -- parfois un autre niveau, parfois des données sonores, parfois de la RAM, parfois n'importe quoi.

Level ID $01 + AreaType 0 = Minus World

Le plus célèbre des glitch worlds. Le Level ID $01 en AreaType 0 (eau) pointe vers :

• Tile pointer : $AE45 → la zone sous-marine de 2-2/7-2
• Sprite pointer : $A171 → les sprites de 2-2/7-2

Le résultat : un niveau d'eau qui ressemble à 2-2, mais qui boucle à l'infini parce que le flagpole n'existe pas. Pas de fin de niveau, pas de sortie.

C'est le niveau 36-1 (ou 36-1 dans le monde $-1).

; Pourquoi le flagpole manque dans le Minus World :
; Les sprites de 2-2/7-2 ($A171) n'ont pas de flagpole
; dans leur séquence. Le jeu cherche le sprite $FD (flagpole)
; mais ne le trouve jamais → boucle infinie
;
; Le jeu continue de générer le niveau à l'infini
; jusqu'à ce que le timer atteigne zéro.

Les pointeurs qui pointent vers la RAM

Quand le tile pointer ou le sprite pointer pointe vers une adresse en RAM ($00-$7F) plutôt qu'en ROM, le jeu tente d'interpréter les changements constants de la RAM comme des tiles :

; Exemple : Level ID $03 en Water
; Tile Pointer : $A46B (3-3 - valide)
; Sprite Pointer : $009D (pointe vers la RAM page zéro !)
;
; La RAM page zéro contient les registres du jeu,
; la position de Mario, l'état des compteurs...
; Le jeu décompresse ça comme une séquence de sprites,
; et le résultat c'est un niveau avec des ennemis
; qui sont en fait des valeurs de registres.

Quand la page zéro change (parce que Mario bouge, que le timer tourne, etc.), les "sprites" du niveau changent aussi. C'est pour ça que certains glitch worlds ont des ennemis qui clignotent et se transforment constamment.

Level ID $36 : le niveau vide (Overworld)

Level ID $36 en Overworld :

• Tile pointer : $AC35 (1-2)
• Sprite pointer : $A0D8 (1-2)

Résultat : rien. Le jeu charge le niveau mais il est marqué "sans niveau" dans le catalogue de RGMechEx. Les tiles sont peut-être valides mais les sprites pointent vers un endroit qui produit un niveau vide ou non fonctionnel.

Level ID $1D (Castle) : le champion des crashs

Level ID $1D en Castle :

• Tile pointer : $A210 (4-4)
• Sprite pointer : $7EA0 (RAM !)

Sprite pointer en RAM = undefined sprites. Le jeu essaie d'afficher un Spiny ball ou un Bullet Bill blaster dans la première ligne de tiles. Ça crashe immédiatement.

; Quand le sprite pointer pointe vers la RAM,
; le jeu décompresse des bytes qui changent tout le temps
; comme des instructions "spawn". Le résultat :
; - Apparition d'objets inexistants (valeur undefined)
; - Crash PPU quand le sprite NES essaie d'afficher un tile invalide
; - Freeze complet de la console

Les 256 glitch worlds catalogués

RGMechEx a écrit un script qui génère les maps de tous les niveaux, pour les 4 types de zone, et les 128 IDs chacun.

Le compteur de monde est sur 8 bits (0-255). Les mondes 1-8 sont légitimes. Il reste 248 glitch worlds potentiels. Chaque glitch world correspond au premier niveau de ce monde, et sa Level ID est calculée par le mécanisme d'overflow de la WorldIndexTable.

Sur les 128 IDs possibles, seulement 68 sont des "first level" d'un monde (accessibles via le glitch world number). Les 60 autres sont des niveaux 2+ ou inaccessibles.

Type	IDs uniques jouables	IDs qui crashent	IDs vides
Water (0)	~20	~60	~48
Overworld (1)	~30	~55	~43
Underground (2)	~15	~65	~48
Castle (3)	~25	~58	~45

Beaucoup de IDs mènent au même niveau à cause des pointeurs qui tombent sur les mêmes adresses ROM. Le Level ID $28 (Overworld) par exemple -- tile pointer $A7CD (2-1) -- apparaît dans 38 glitch worlds différents, parce que son sprite pointer $9F51 pointe vers une zone de la ROM qui est utilisée comme padding/données sonores réutilisé par plein d'IDs.

Les 6 glitch levels vraiment uniques

Parmi les 19 IDs de glitch level accessibles, seulement 6 ne crashent pas immédiatement au chargement :

World	Level ID	Description
E-1 (224)	$50	Un seul ? block au-dessus d'un gouffre. Mario meurt instantanément.
W	$57	Mario spawn bloqué, incapable de bouger.
42 (133)	$50	Tunnel de nuages qui piège Mario s'il va assez loin.
62 (131, 240)	$4D	Château gelé : Mario spawn en haut, ne peut pas tomber → bloqué.
127	$4B	Tunnel souterrain, mais crashe si on va trop loin.
137	$4B	Active le défilement automatique des cutscenes. Mario rencontre un unique brick block qui le bloque à jamais.

Six glitch worlds sur 248 qui produisent quelque chose de vraiment nouveau. Le reste, ce sont des niveaux normaux avec le mauvais type de zone, ou des écrans noirs.

Le format des niveaux en détail

Cap sur le format exact des données de niveau, pour comprendre pourquoi les glitch levels tiennent debout (ou pas).

Le header niveau : 2 bytes, 6 propriétés

Chaque niveau commence par un header de 2 bytes qui contrôle 6 propriétés :

; Byte 0 : timer + Y start + modifier
;   Bits 7-6 : timer (00=inchangé, 01=200, 10=300, 11=400)
;   Bits 5-3 : Y start Mario (111/110 = autowalk)
;   Bits 2-0 : level type modifier
;              000=default, 001=waves, 010=brick wall,
;              011=water bottom, 100=night, 101=snow,
;              110=snow night, 111=gray night

; Byte 1 : platform + background + floor pattern
;   Bits 7-6 : special platform (00=tree, 01=mushroom,
;                                 10=Bullet Bill, 11=cloud)
;   Bits 5-4 : background (00=none, 01=clouds,
;                           10=montains, 11=fences)
;   Bits 3-0 : floor pattern initial (0-15)

Le type modifier contrôle des variations visuelles : les vagues en haut des niveaux d'eau, le fond brique de 8-3, la palette nuit de 4-3, la neige de 6-2, etc.

Les objets tiles : 2 bytes, Next Screen Flag, queue 3 slots

Après le header vient une liste d'objets tile, chaque objet fait 2 bytes. Le byte $FD marque la fin de la liste.

; Format objet tile (16 bits) :
; Byte 0 :
;   Bits 7-4 : X position (colonne 0-15)
;   Bits 3-0 : Y position
;     Y=0-11  : position Y normale
;     Y=12    : objets spéciaux (trous, ponts, rope, ? blocks)
;     Y=13    : screen skip / objets spéciaux 2
;     Y=14    : changement de modifier/scenery/floor
;     Y=15    : objets spéciaux 3 (château, escaliers, gros tuyau)

; Byte 1 :
;   Bit  7   : NEXT SCREEN FLAG
;   Bits 6-4 : type d'objet (0-7)
;   Bits 3-0 : largeur/hauteur / sous-type

Quand le bit "next screen" est mis, la colonne de travail courante est incrémentée de 1. Ça permet de placer des objets au-delà des 16 premières colonnes. Les objets doivent être listés dans l'ordre (gauche à droite) parce que le jeu les charge séquentiellement :

; La routine de chargement a DEUX phases par colonne :
; Phase 1 : chercher les nouveaux objets qui commencent sur cette colonne
;            et les ajouter à la file d'attente (queue)
; Phase 2 : traiter chaque objet dans la queue en dessinant les tiles,
;            et retirer ceux qui finissent sur cette colonne

La queue fait exactement 3 slots. Conséquence directe : on ne peut pas avoir plus de 3 objets qui commencent sur la même colonne. Si la queue est pleine, le 4ème objet est ignoré et ne sera jamais chargé.

C'est pour ça que les niveaux bien conçus évitent d'empiler trop d'objets. Exemple dans 1-2 : la colonne avec le 1up block dans le plafond + les briques à côté sont splitées en deux objets distincts pour respecter la limite de 3.

Y position spéciale : 12, 13, 14, 15

Quand Y=12, l'objet n'a pas de position Y (elle est hardcodée par type) :

; Y=12 : objets sans Y position
;   Type 0 : trou (supprime le sol)
;   Type 1 : rope de plateforme mobile
;   Types 2-4 : ponts à Y fixe
;   Type 5 : trou avec eau/lave
;   Types 6-7 : rangées de ? blocks

Quand Y=13, deux sous-groupes. Si le bit 6 du byte 1 est à 1 :

; Y=13, bit6=1 : objets spéciaux
;   0 = L-pipe (cutscene), 1 = flagpole, 2-3 = pont/axe/hamer (fin château)
;   4 = stop screen, 5 = random enemies, 6 = loop level, 7+ = crash possible

Si bit6=0, les 5 bits de poids faible encodent un screen skip (sauter directement à un écran N, sans passer par le next screen flag un par un).

Quand Y=14 : même principe avec bit6=1 pour changer le type modifier, bit6=0 pour changer le fond + floor pattern.

Les floor patterns : 16 motifs de sol

Le sol des niveaux n'est pas fait d'objets individuels. SMB1 utilise des floor patterns, un motif de fond qui s'applique à toutes les colonnes jusqu'au prochain changement :

; Floor patterns (4 bits = 16 possibilités)
;   0 = vide total
;   1 = sol 2 tiles haut
;   2 = sol 1 tile haut
;   3 = sol + bottom
;   4 = sol + bottom 2
;   5 = sol 1/2 tile
;   6 = 3/4 sol
;   ... jusqu'à 15 = rempli total (sol + plafond)

C'est pour ça que les trous sont des objets : ils override le floor pattern sur une colonne spécifique, sans avoir à changer le pattern pour tout le reste.

La limite des 256 bytes et le repeat

Toutes les données tile d'un niveau tiennent dans 256 bytes maximum. Le Y register du 6502 est utilisé comme index, et il fait 8 bits. Si le jeu arrive à la fin des données sans trouver le byte $FD, il reboucle au début et répète les 256 bytes à l'infini :

; Index Y = 8 bits → max 256 bytes de données tiles
; Si Y overflow (255 → 0) sans rencontrer $FD → repeat
; Même chose pour les sprites, mais les objets pipe (3 bytes)
; décalent la parité de l'index à chaque chargement.

Certains glitch levels exploitent ce repeat pour générer des niveaux qui durent "indéfiniment".

Le système de sprites : 2 bytes + pipe transitions

Les sprites suivent un format similaire, mais sans header et avec quelques différences clés. Le byte $FF marque la fin de la liste.

; Format sprite (2 bytes) :
; Byte 0 : position X (colonne)
; Byte 1 :
;   Bit 7 : NEXT SCREEN FLAG
;   Bits 6-0 : type de sprite
;       Certains types incluent : goomba, koopa, Blooper,
;       Bullet Bill, Lakitu, Spiny, plateformes,
;       commande warp zone, toad/princesse,
;       commandes de spawn de groupes d'ennemis

Le bit de poids faible du byte 1 est le hard level flag : si mis à 1, le sprite n'apparaît que dans les niveaux ≥ 5-3. C'est ainsi que les niveaux "hard mode" sont créés.

Y position 15 = screen skip (identique aux tiles). Y position 14 = pipe transition (3 bytes) :

; Sprite Y=14 : pipe/vine transition (3 bytes !)
;   Byte 0 : position X
;   Byte 1 : bits 6-0 = Level ID 7-bit (destination)
;   Byte 2 : bits 4-0 = screen de destination
;            bits 7-5 = world où cette transition est valide
;
; Pourquoi un world ? Les bonus rooms sont réutilisées entre mondes.
; Exemple : la salle bonus de 1-1 est aussi utilisée par 2-1 et 7-1.
; Cette salle a 3 transitions, une par monde, pour que Mario
; réapparaisse au bon endroit.

Les sprites n'ont pas de queue system. La seule limite est qu'il ne peut pas y avoir plus de 4 sprites chargés simultanément dans la zone de spawn (juste hors-écran à droite). Au delà, les sprites sont ignorés.

Comment accéder aux glitch worlds

Il y a deux méthodes principales.

La méthode classique : le wall clip

Le wall clip (passage à travers les murs) permet de sortir du niveau normal et de marcher jusqu'à la warzone cachée. En manipulant le compteur de monde via la RAM, on peut charger n'importe quel Level ID.

La technique :

1. World 1-2 : aller dans le tuyau de fin caché
2. Faire le wall clip sur le mur de droite
3. Marcher dans le vide jusqu'à la zone warp
4. Le jeu interprète les valeurs comme des mondes

Mais cette méthode ne donne accès qu'à une petite partie des glitch worlds.

La méthode extreme : NES Tennis cart swap

Voir la section "Le warm start" plus haut pour le détail complet. En résumé : le compteur de pas de Tennis écrit sur le même byte RAM que le monde de départ de SMB1, et la détection warm start préserve cette valeur.

Le coin des bidouilleurs : le code pour tout explorer

Si tu veux explorer tous les glitch toi-même dans un émulateur, tu peux patcher le Level ID directement :

; Patch pour FCEUX / Mesen :
; Adresse RAM $075F = Level ID actuel
; Adresse RAM $0760 = Area Type (0=Water, 1=Overworld, 2=Underground, 3=Castle)

; Exemple : charger le Level 57 (0x39) en Overworld
; Dans l'émulateur, ouvrir le traceur mémoire et écrire :
; $075F = 0x39
; $0760 = 0x01
; Puis entrer dans un tuyau de warp ou mourir et recommencer
; → Le jeu charge le niveau ID $39 en Overworld

RGMechEx a publié la liste complète des 128 niveaux × 4 types avec des maps générées automatiquement sur rgmechex.com. Chaque entrée montre le tile pointer, le sprite pointer, et une carte visuelle du niveau.

Les niveaux les plus wtf

Level ID $1F (Water) : 15 glitch worlds en un

Le tile pointer $A302 (3-4) combiné au sprite pointer $02A0 donne 15 glitch worlds différents (D-1, J-1, Y-1, Z-1, 55-1, 73-1...). Explication : le sprite pointer pointe vers une zone de la ROM qui contient des données suffisamment proches de sprites valides pour produire des résultats jouables, mais la combinaison des tiles de château 3-4 avec des sprites d'overworld crée un rendu absurde.

Level ID $28 (Overworld) : 38 glitch worlds = record

Le record absolu. 38 entrées de glitch world pointent vers le même niveau (2-1 tiles + $9F51 sprites). Pourquoi ? Parce que le sprite pointer $9F51 tombe dans une zone de la ROM qui est utilisée comme padding/données sonores réutilisé par plein d'IDs.

Level ID $49 (Underground) : le niveau FDS

Tile pointer $76AE + sprite pointer $1C9D. Le tile pointer pointe vers la zone de la ROM réservée à la version Famicom Disk System. Résultat : un niveau avec des tiles qui n'existent pas dans la cartouche standard. C'est le niveau qui fait apparaître le niveau 52-1 et 196-1.

Level ID $00-$02 : les vrais niveaux bonus

Ces IDs sont utilisés par des sous-niveaux légitimes du jeu :

• $00 : zone sous-marine de 5-2/6-2 (utilisé par H-1, 39-1)
• $01 : l'eau de 2-2/7-2 (le Minus World, 36-1)
• $02 : sous-niveau de 8-4 (136-1, 151-1, 215-1)

La différence entre un niveau "bonus" accessible normalement et un glitch world, c'est que les warp zones vérifient le monde actuel :

; Vérification warp zone (simplifié)
; Le jeu vérifie que le monde cible est entre 1 et 8
CheckWarp:
  lda TARGET_WORLD
  cmp #1
  bcc InvalidWarp       ; < 1 → refusé
  cmp #9
  bcs InvalidWarp       ; > 8 → refusé
  ; world valide entre 1 et 8 uniquement
  jmp DoWarp

Les glitch worlds avec des numéros > 8 ou 0 ne peuvent pas être atteints par des tuyaux normaux. Il faut le wall clip ou le cart swap.

Pourquoi certains niveaux crash : les jump tables

Quand le jeu charge un objet tile, il utilise son type comme index dans une jump table :

; Jump table des objets tiles standards (types 0-11)
JumpTable_TileObjects:
  .word Obj_Special       ; type 0 : bloc ?, hidden, flagpole...
  .word Obj_Platform      ; type 1 : plateforme spéciale
  .word Obj_BrickRow      ; type 2 : rangée de briques
  .word Obj_BlockRow      ; type 3 : rangée de blocks
  .word Obj_CoinRow       ; type 4 : rangée de pièces
  .word Obj_BrickCol      ; type 5 : colonne de briques
  .word Obj_BlockCol      ; type 6 : colonne de blocks
  .word Obj_Pipe          ; type 7 : tuyau
  .word Obj_8             ; type 8
  .word Obj_9             ; type 9
  .word Obj_10            ; type 10
  .word Obj_11            ; type 11

Si un objet a un type invalide (≥12), le jeu saute à un pointeur qui n'existe pas dans cette table. 4 outcomes possibles :

1. Pointeur valide → l'objet se charge normalement
2. Pointeur vers une autre jump table (chevauchement) → un objet différent apparaît. Exemple : type 12 pointe vers la table Y=13, ce qui donne un L-pipe.
3. Pointeur vers de l'exécutable → exécution de code aléatoire (crash probable)
4. Placeholder explicite (NOP) → l'objet ne fait rien (certains sprites sont comme ça, produisant des ennemis qui volent sur place sans bouger)

La glitch level ID $58 (le tunnel qui crashe) : son sprite pointer pointe vers une région mémoire qui n'existe pas sur NES sans mapper ROM. Le jeu essaie de charger le même Koopa 5 fois par frame à la position (0,0), ce qui sature la PPU et provoque un freeze.

; Pourquoi ID $58 crashe :
; Sprite pointer → adresse invalide (hors espace NES standard)
; → Le jeu lit des bytes indéterminés comme des types de sprite
; → Le Koopa $00 (type invalide sans handler) boucle en appel récursif
; → Stack overflow 6502 → freeze

Le paradoxe pipe warp

Rappelle-toi le check target_world BETWEEN 1 AND 8. Même si tu trouves un tuyau dans un glitch world, le jeu vérifie que le monde de destination est entre 1 et 8. Les glitch worlds ont des numéros > 8 (36-1, 255-1...), donc la warp échoue.

C'est aussi pour ça que le Minus World n'a pas de fin : le flagpole n'est pas présent dans les sprites, et les tuyaux ne mènent nulle part.

Le trick des 5 objets dans une colonne

Il existe un edge case qui permet d'outrepasser la limite de 3 objets par colonne. Quand la queue se bloque (slots pleins + objet suivant avec next screen flag manquant), le jeu "prétraite" la colonne courante en boucle jusqu'à trouver un objet avec next screen flag. Pendant chaque prétraitement :

; Pendant le prétraitement de colonne :
; 1. Les objets dans la queue voient leur largeur restante
;    décrémentée à chaque "fausse avancée" de colonne
; 2. Si un objet atteint largeur=0, il quitte la queue
; 3. Un slot libéré peut être rempli par un nouvel objet
;    ajouté dans la même colonne

; Résultat : jusqu'à 5 objets peuvent être traités sur la même colonne.
; Technique : placer 2 objets qui traversent la screen boundary
; (slots 1 et 2), 1 objet dummy en X < précédent (bloque la queue),
; puis 3 objets à X=0 de l'écran suivant (dont un avec next screen flag).

C'est ce qu'on appelle un "queue skip" et c'est utilisé par certains romhackers pour créer des niveaux plus denses que ce que le format permet normalement.

Les différences entre versions

Famicom Disk System

La version FDS de SMB1 a une memory map différente. Tous les pointeurs de niveau sont décalés, mais les données sont les mêmes. Ce qui change : les indices des glitch worlds sont complètement différents :

FDS World 36 → Level ID $09 (eau version de 5-3)
  → Le flagpole est présent ! On peut finir le niveau.
  → Ensuite : $27 (7-3 normal) → $44 (4-4 underground)
  → $44 est finissable → la hache fonctionne → fin du jeu !
  
Le Minus World FDS est donc un "bonus world" qui peut mener
à la complétion du jeu, contrairement à la version NES.

Mon niveau FDS préféré : ID $5F, une version souterraine de la deuxième moitié de 3-3 en tunnel bas (dommage que ce soit un autoscroller).

The Lost Levels (Super Mario Bros. 2 japonais)

Lost Levels change beaucoup de choses :

1. Ordre identique tiles/sprites : plus de Frankenstein levels (tiles et sprites chargent le même niveau même avec un ID invalide)
2. Une seule table de pointeurs 16-bit au lieu de deux tables séparées high/low
3. 4 fichiers disque : la ROM a été splitée pour le FDS :
   • Fichier 1 : worlds 1-4
   • Fichier 2 : worlds 5-8
   • Fichier 3 : world 9 + sound engine
   • Fichier 4 : worlds A-D (table de pointeurs complètement différente)
4. Même Level ID = 4 niveaux possibles selon le fichier chargé
5. Plus de glitch Tennis : le continue option (continue au même monde après game over) rend le warm start inutile, et le jeu reset immédiatement si world > 9
6. Nouveaux objets : champignon poison, block invisible, block invisible fire flower, upside down pipes, vent -- mais insérés au milieu des listes existantes → incompatibilité backward avec SMB1
7. Piranha Plants toujours rouges après world 4, springboards verts seulement en worlds 2/B/3/C/7

Super Mario All-Stars (SNES)

Portage direct avec les mêmes routines 6502 (le SNES exécute le code NES en mode compatible) :

• Warp zone fixée : plus de Minus World (entrer dans le tuyau gauche avant le texte mène au bon monde)
• Plantage : la plupart des glitch levels crashent (sauf ID $6A et 9-1)
• Objets château ajoutés : rendus plus uniques
• Mais : le 4-2 wrong warp fonctionne encore (pas patché !)

Le 4-2 wrong warp : un bug de placement d'objet

Dans 4-2, il y a deux objets de transition pipe : la vigne (warp zone) et le tuyau (coin cash room). Le premier objet de transition (celui de la vigne) est placé bien avant que la vigne n'apparaisse sur l'écran. Le deuxième (le tuyau) est placé trop tard dans le niveau.

; Timing des transitions dans 4-2 :
; Objet transition 1 (vigne → warp zone) : placé 3 écrans avant la vigne
; Objet transition 2 (tuyau → coin cash) : placé 1 écran après le tuyau
;
; Normalement le premier objet est désactivé avant que Mario
; n'atteigne le tuyau. Mais si Mario va vite (ou utilise
; le raccourci du bloc B+right), la transition de la vigne
; est toujours active quand il touche le tuyau !
; → Le jeu charge la warp zone au lieu du coin cash.
;
; Si l'objet avait été placé juste après la vigne mais avant
; le tuyau, le bug n'existerait pas.

Les niveaux à boucle

Comment fonctionnent les loop (8-4, 7-4) ? Le niveau a des checkpoints avec des numéros d'écran et des positions Y hardcodés :

; Checkpoint : {screen_number, vertical_position}
; Si Mario passe ce checkpoint à la bonne hauteur → niveau continue
; Sinon → warp back de 4 écrans (64 blocks)
;
; Pour faire une boucle infinie : vertical_position = $F0
; (en dessous du bas de l'écran) → impossible de valider.
;
; Les checkpoints sont simples (un seul flag) sauf pour world 7
; qui utilise des triplets (3 flags, il faut en échouer au moins 1)
;
; Le warp back est rude : offset de tile data réglé à une valeur
; hardcodée, offset de sprite data remis à 0. Les ennemis présents
; sont déchargés instantanément → les firebars disparaissent.

Changer le format, pas le code

Une des leçons les plus fascinantes de cette architecture, c'est que les développeurs de SMB1 ont réussi à créer un système de niveau très expressif sans jamais toucher au code de rendu 6502. Toute la variation entre les niveaux vient des données (pointeurs, objets, sprites, floor patterns), pas du code.

Les 256 glitch worlds existent parce que les tables de pointeurs sont dimensionnées pour 128 entrées × 4 types, et que le jeu ne valide jamais les valeurs qu'il lit. Quand un pointeur tombe en RAM, le jeu interprète les registres de Mario comme des tiles. Quand un pointeur tombe dans les données sonores, le jeu joue de la musique sous forme de level design. Et quand les jump tables overflowent, le jeu exécute n'importe quoi jusqu'au crash.

Ce qu'on peut apprendre de tout ça

1. Séparation tiles/sprites : indépendance totale des deux couches, avec des ordres de stockage différents qui créent des Frankenstein levels uniques
2. Compression RLE + système d'objets : les niveaux ne sont pas des bitmaps mais des listes d'objets placés, avec des floor patterns pour le sol
3. Queue 3 slots : limite stricte du hardware (et du design de niveau)
4. Pas de validation : le jeu fait confiance aux pointeurs et aux jump tables, ce qui produit soit des glitchs jouables, soit des crashs
5. 256 bytes max : la limite du Y register 6502, qui fait que les données se répètent si on va trop loin
6. Warm start / cold start : un système de "continuer" qui a ouvert la porte au cart swap Tennis → Mario

Le plus beau : tout ça, c'est du code 6502 qui tient dans 40KB. Pas de couche d'abstraction, pas de validation d'accès mémoire, pas de gestionnaire d'exceptions. Si le pointeur est pourri, le jeu crashe. Et les crashs, on les appelle des glitch worlds.

Les 3 trucs à retenir

1. Les glitch worlds sont des pointeurs qui tombent mal -- Le jeu a 128 IDs × 4 types de zone, mais seulement 34 niveaux uniques. Quand le world number est corrompu (par Tennis ou wall clip), le jeu charge un pointeur conçu pour un autre niveau, et les 512 combinaisons possibles produisent des résultats imprévisibles.

2. Le Minus World est un bug de warp combiné à de la corruption -- Le tuyau gauche dans 1-2, si activé avant que le texte n'apparaisse, charge world 36 (0x24). Ce world pointe vers Level ID $01 (eau de 2-2), un niveau sans flagpole. Et comme il n'y a pas de transition pipe pour world 36, le niveau boucle à l'infini. L'absence de vérification crée l'icône.

3. Tennis → Mario, 15 ans avant OoT → Paper Mario -- La RAM du NES survit à un swap de cartouche grâce aux condensateurs et au système de warm start / cold start de SMB1. Le compteur de pas de Tennis (qui incrémente un byte RAM en jouant le son des pas) tombe pile sur l'adresse du world number. Il faut que les digits du top score restent à 0, que le byte $A5 soit intact, et que le jeu détecte un warm start -- un concours de circonstances parfait qui n'a fonctionné qu'avec Tennis.

Les vidéos originales de Retro Game Mechanics Explained sont un putain de travail de fourmi -- le niveau de détail sur la désassemble 6502, les maps automatiques de tous les niveaux, les explications du cart swap et du warm start. Si t'as pas vu la série, mate-la, elle est courte et chaque minute est dense.

Le code source des maps est dispo sur rgmechex.com, et le désassemble complet de SMB1 est open source sur plein de repos. Y'a 40 ans, des programmeurs japonais ont écrit ce système de niveau en 6502 avec zéro test unitaire et zéro bug tracker, et on continue d'apprendre des trucs en ouvrant leur code aujourd'hui.

引言

Super Mario Bros.，只有40KB ROM。八个世界，32个关卡，敌人、音乐、道具，全都在里面。

但如果你打开模拟器，修改正确的字节，你就能加载第36-1关。或者255-1关。甚至进入一个满屏都是Bowser精灵和通往虚空的水管的故障世界。

这些glitch world存在的原因很简单：SMB1的关卡存储系统是8位优化的杰作，而当你强制游戏在不该读取的地方读取数据时，就会产生令人着迷的结果。

Retro Game Mechanics Explained制作了一个4集系列视频----我们将把它们整合为一次对这个时代最畅销游戏6502代码的深入探索。

Warm Start：为什么Tennis的RAM能在SMB1中存活

在讨论关卡存储之前，需要先了解SMB1如何启动。因为NES Tennis卡带交换的glitch完全依赖于游戏的warm start / cold start检测系统。

被保留的41字节

当SMB1检测到cold start（首次通电或关机再开机）时，它会清除所有RAM。但当它检测到warm start（按重置键，没有断电）时，它会保留一个41字节的内存区域：

; Warm start时RAM中保留的41字节
; 地址 $075F-$0787
;
; $075F : 启动字节 (world - 1)    [1 byte]
; $0760 : 世界选择标志 (B button) [1 byte]
; $0761-$0762 : 未使用                    [2 bytes]
; $0763-$0768 : 计时器 (6位数字, 显示3位) [6 bytes]
; $0769-$076E : Luigi的金币                   [6 bytes]
; $076F-$0774 : Mario的金币                   [6 bytes]
; $0775-$077A : Luigi的分数                   [6 bytes]
; $077B-$0780 : Mario的分数                   [6 bytes]
; $0781-$0786 : 最高分 (6位数字, 1位隐藏) [6 bytes]
; $0787 : 魔法字节 $A5                 [1 byte]

这41字节只用于一个功能：让玩家在game over后能继续到同一个世界。如果你在6-3死了，游戏会把世界6写入启动字节，在标题画面中，如果你按住A + Start，就会从6-1重新开始。

Warm start的双重验证

当SMB1启动时，它不只是检查一个条件，而是两个：

CheckWarmStart:
  ; 1. 检查 $0787 处的魔法字节 $A5
  lda $0787
  cmp #$A5
  bne ColdStart        ; 不是 $A5 → cold start

  ; 2. 检查最高分的6位数字 ($0781-$0786)
  ;    每位数字必须在0到9之间
  ldx #0
CheckLoop:
  lda $0781,x
  cmp #$0A
  bcs ColdStart        ; 数字 >= 10 → cold start
  inx
  cpx #6
  bne CheckLoop

  ; 如果两个条件都通过 → warm start
  ; RAM不会被清除，启动世界被保留
  jmp WarmStartBoot

为什么要双重验证？因为$A5字节可能是偶然存在的（另一个游戏遗留了这个值，或RAM芯片的默认空闲状态）。通过验证最高分数字有效（0-9），可以确保数据是一致的。

为什么只有Tennis能用

当我们首次插入SMB1（cold start）时，游戏会：

1. 清除所有RAM → 最高分 = 0，世界字节 = 0
2. 在地址$0787写入$A5

然后我们不关机直接换上Tennis。Tennis：

• 启动时不清理RAM（很少有NES游戏这么做）
• 不写入最高分的字节 → 它们保持为0（有效）
• 不修改$A5字节 → 它保持不变
• 使用地址$075F 作为玩家的脚步计数器

; Tennis中的脚步递增机制：
; 每当玩家在球场上走一步，Tennis会递增$075F处的字节。
; SMB1使用同一个字节作为 "世界编号 - 1"。
;
; 0步  → world 0 → SMB1 = world 1
; 1-7步 → world 1-7 → 正常世界
; 8+步 → world 8+ → 故障世界！
;
; 计数器只在音乐停止时递增
; （脚步音效在音乐播放时不会触发）。

当我们重新插回SMB1时：

1. $A5字节仍然在（Tennis没有修改它）
2. 最高分数字仍然是0（有效）
3. 世界字节现在是8+（被Tennis的脚步递增）
4. SMB1检测到warm start → 保留损坏的世界字节
5. 按住A + Start → world 9-1, world A-1, world 36-1, 等等

为什么必须先启动Mario再启动Tennis

一个微妙之处：必须先启动SMB1，再启动Tennis，然后再启动SMB1。如果你直接从Tennis开始，$A5字节永远不会被写入（Tennis不会写入$A5），因此warm start检测会失败，RAM会被清除。

SMB1如何在40KB中存储关卡

Nintendo R&D4必须解决一个表面上很简单的问题：用有限的ROM预算表示水平滚动的关卡，包含图块、敌人、道具。

解决方案是将数据分为完全独立的两层：

Tile layout（关卡地图）

每个关卡由一个指向ROM中压缩图块结构的指针定义。压缩方式简单但精妙：一个"控制"字节后跟1-3个数据字节。

Tile格式使用游程编码（RLE-like）系统：

; SMB1的tile格式（简化）
; 每个"命令"是一个控制字节：
;
; $00-$7F : 放置一个tile，前进1列
; $80-$BF : 放置一个tile重复N次 (N = 字节 - $80 + 1)
; $C0-$FF : 特殊命令（行尾、跳转、调色板切换）

示例：绘制3个连续的砖块：
  $82 $01    ; 重复tile $01 (brick) 3次

每个关卡包含13行 × 16列的图块（13×16 = 208个可见图块）。但压缩格式可以大幅减少数据量----例如天空和空白列几乎不占空间。

6502的渲染循环：

; Tile解压缩 - 主循环
; 输入：tile_data指针在 $XX
; 输出：tilemap关卡数据写入PPU RAM

DecompressTile:
  lda (tile_ptr),y      ; 读取控制字节
  iny
  cmp #$80
  bcc SingleTile        ; $00-$7F : 单个tile
  cmp #$C0
  bcc RunLength         ; $80-$BF : 游程编码
  jmp SpecialCommand    ; $C0-$FF : 特殊命令

SingleTile:
  sta PPU_DATA          ; 直接写入tile
  jmp Next

RunLength:
  sec
  sbc #$7E              ; N = control - $7E
  tax
  lda (tile_ptr),y      ; 读取要重复的tile
  iny
: sta PPU_DATA
  dex
  bne :-
  jmp Next

Sprite layout（敌人和物体）

同时，敌人和物体（?方块、水管、goomba、koopa）存储在一个完全独立的结构中。每个spawn由2字节定义：

; SMB1的sprite格式
; Byte 0 : X位置（列）
; Byte 1 : sprite类型 + Y页面位
; Y由序列中的索引推导

一个sprite序列：
  $01 $4B    ; goomba在第1列
  $09 $4B    ; goomba在第9列
  $10 $61    ; ?方块在第16列（含金币）
  $15 $54    ; 绿色koopa在第21列
  $FF        ; 序列结束

每个关卡可以引用最多5个不同的sprite页面（即5个16列的"屏幕"），但大多数关卡实际上只使用2-3个。

指针表

设计的精妙之处在于指针表。每个关卡存储为一对ROM地址：

// World Map的内部结构（简化）
struct LevelPointer {
    uint16_t tile_ptr;   // Tile数据的ROM地址
    uint16_t sprite_ptr; // Sprite数据的ROM地址
};

// 4个独立的表，每个AreaType一个：
// 0 = Water, 1 = Overworld, 2 = Underground, 3 = Castle
LevelPointer level_table[4][128];

每个表128个条目。4种区域类型。512种可能的组合，但只有一小部分被官方游戏使用。其余的是未初始化的RAM或被当作指针解释的数据。

当游戏加载关卡时，它这样做：

; 加载关卡
; A = AreaType (0-3), X = LevelID (0-127)

LoadLevel:
  sta AREA_TYPE
  asl                  ; ×2 用于16位表偏移
  tax
  lda LevelTable_TilePtr, x
  sta TILE_PTR
  lda LevelTable_TilePtr+1, x
  sta TILE_PTR+1       ; 指向tiles的指针
  lda LevelTable_SpritePtr, x
  sta SPRITE_PTR
  lda LevelTable_SpritePtr+1, x
  sta SPRITE_PTR+1     ; 指向sprites的指针
  jsr DecompressTiles

没有验证。没有检查指针是否有效。游戏从表中读取地址，解压缩该地址处的数据，就这么简单。

34个独立关卡和7位ID系统

SMB1不是32个关卡，而是34个独立关卡。许多关卡是重复的（5-3 = 1-3 但有Bullet Bills），通过"hard mode"标志区分。真正的独立关卡：

• 水下（Type 0）：3个关卡（2-2, 7-2, 奖励区域5-2/6-2）
• Overworld（Type 1）：22个关卡（包括2个云端奖励房间）
• Underground（Type 2）：3个关卡（包括地下奖励房间）
• Castle（Type 3）：6个关卡
• + 1个过场房间（地下/水下关卡之前）
• + 1个4-2的warp zone

每个关卡有一个7位的ID。低5位=子组内的编号，高2位=区域类型：

; Level ID的7位编码
; Bit 6-5 : 类型 (00=Water, 01=Overworld, 10=Underground, 11=Castle)
; Bit 4-0 : 子组内的编号
;
; Water ID      : $00-$02  (类型 00, 编号 0-2)
; Overworld ID  : $20-$35  (类型 01, 编号 0-21)
; Underground ID: $40-$42  (类型 10, 编号 0-2)
; Castle ID     : $60-$65  (类型 11, 编号 0-5)
;
; ID $25 = %0100101 → 类型 01 (Overworld), 编号 5 → 1-1
; ID $23 = %0100011 → 类型 01 (Overworld), 编号 3 → 6-2

128个可能的ID（$00-$7F），只有34个被分配给真实关卡。未使用的ID指向任何地方。

指针表：两个列表，两种顺序

Tile和sprite指针的存储顺序不同。代码使用两个独立的16位列表（高位字节/低位字节分别在两个不同的表中）：

Sprite指针的顺序：
  索引 0-5   : Castle (6个关卡)
  索引 6-27  : Overworld (22个关卡)
  索引 28-30 : Underground (3个关卡)
  索引 31-33 : Water (3个关卡)

Tile指针的顺序：
  索引 0-2   : Water (3个关卡)
  索引 3-24  : Overworld (22个关卡)
  索引 25-27 : Underground (3个关卡)
  索引 28-33 : Castle (6个关卡)

为什么顺序不同？没有技术原因----可能只是开发过程中数据的组织方式。但这产生了一个令人着迷的后果：当关卡ID无效时，tile和sprite指针会加载不同的关卡，创造出Frankenstein关卡。

为了在这两个列表之间导航，游戏使用小型偏移表（就像目录一样）：

; 按类型划分的偏移表 (Water, Overworld, Underground, Castle)
; 每个条目 = 对应列表中的起始索引

SpriteOffsetTable:
  .byte $1F, $06, $1C, $00    ; Water=31, Overworld=6, Underground=28, Castle=0

TileOffsetTable:
  .byte $00, $03, $19, $1C    ; Water=0, Overworld=3, Underground=25, Castle=28

加载关卡6-2（ID $23, Overworld编号3）：

; 1. 类型 = 01 (Overworld) → 偏移表中的索引 = 1
; 2. Sprite偏移 = SpriteOffsetTable[1] = 6
;    最终索引 = 6 + 3 (关卡编号) = 9 → 第10个sprite指针
; 3. Tile偏移 = TileOffsetTable[1] = 3
;    最终索引 = 3 + 3 = 6 → 第7个tile指针
; 4. 结果：tile指针 $A619 + sprite指针 $9ED0 = 6-2 ✓

那么当ID无效时，比如$43（Underground编号3，实际上不存在）会怎样？

; ID $43, 类型 = 10 (Underground), 编号 = 3
; Sprite偏移 = SpriteOffsetTable[2] = $1C = 28
;   索引 = 28 + 3 = 31 → 第32个sprite指针 = 水下奖励5-2！
; Tile偏移 = TileOffsetTable[2] = $19 = 25
;   索引 = 25 + 3 = 28 → 第29个tile指针 = 1-4 (Castle)！
;
; 结果：一个地下关卡使用了1-4的tiles
; 和5-2水下区域的Bloopers。一个真正的Frankenstein。

World index表：为什么world 9会溢出

有一个8字节的ROM表，给出每个世界（1-8）第一个关卡的索引。紧随其后的是所有36个关卡的Level ID表，按游戏顺序排列。

; WorldIndexTable (8 bytes)
  .byte 0, 5, 10, 15, 20, 25, 28, 33
;   -> 世界1从关卡0开始
;   -> 世界2从关卡5开始
;   -> 世界8从关卡33开始

; LevelIDTable (36 bytes)
  .byte $25, $28, $29, $26, $24, ... ; 36个Level ID

当试图加载world 9时，游戏读取WorldIndexTable的第9个字节……但它不存在。它溢出1个字节到LevelIDTable，读取值$25，然后将$25作为LevelIDTable中的索引（第37个条目）----这又溢出2个字节到SpriteOffsetTable，读取值6。

; World 9：
;   1. WorldIndexTable[8] (溢出) → 从LevelIDTable读取 $25
;   2. LevelIDTable[37] (溢出) → 读取SpriteOffsetTable的第2个字节 = 6
;   3. ID = 6 → 水下关卡编号6（不存在）
;   4. Tile指针 = 水下第6个指针 = 6-2的tiles
;   5. Sprite指针 = 索引 31+6 = 37 > 33 → 无效指针
;   6. 结果：水下的6-2加上glitch sprites
;      → world 9-1！

对于world G（16），溢出更远，落入Level ID $01，这是1-2之前的过场关卡：

; World G (16)：
;   WorldIndexTable[15] → 从LevelIDTable读取 $01
;   LevelIDTable[1] = $29 (过场 1-2)
;   → world G-1 = 1-2的入场过场

故障世界为何存在

游戏有32个"合法"关卡（8个世界 × 4个关卡）。但指针表每个区域类型有128个条目。第32个关卡之后的条目包含ROM中这些地址处的数据----有时是另一个关卡，有时是音效数据，有时是RAM，有时是任何东西。

Level ID $01 + AreaType 0 = Minus World

最著名的故障世界。Level ID $01在AreaType 0（水下）指向：

• Tile指针：$AE45 → 2-2/7-2的水下区域
• Sprite指针：$A171 → 2-2/7-2的sprites

结果：一个看起来像2-2的水下关卡，但因为flagpole不存在而无限循环。没有关卡结束，没有出口。

这就是第36-1关（或世界$-1中的36-1）。

; Minus World中flagpole缺失的原因：
; 2-2/7-2的sprites ($A171) 中没有flagpole。
; 游戏搜索sprite $FD (flagpole) 但永远找不到 → 无限循环
;
; 游戏继续无限生成关卡
; 直到计时器归零。

指向RAM的指针

当tile指针或sprite指针指向RAM地址（$00-$7F）而非ROM时，游戏会尝试将RAM的持续变化解释为tiles：

; 示例：Level ID $03 在 Water
; Tile指针：$A46B (3-3 - 有效)
; Sprite指针：$009D (指向零页RAM！)
;
; 零页RAM包含游戏的寄存器、
; Mario的位置、计数器状态...
; 游戏将其解压缩为sprite序列，
; 结果是一个敌人实际上是
; 寄存器值的关卡。

当零页变化时（因为Mario移动、计时器运行等），关卡的"sprites"也会变化。这就是为什么某些故障世界的敌人会不断闪烁和变形。

Level ID $36：空关卡（Overworld）

Level ID $36在Overworld：

• Tile指针：$AC35 (1-2)
• Sprite指针：$A0D8 (1-2)

结果：什么都没有。游戏加载了关卡，但在RGMechEx的目录中标记为"无关卡"。tiles可能是有效的，但sprites指向一个产生空关卡或不可用关卡的位置。

Level ID $1D (Castle)：崩溃之王

Level ID $1D在Castle：

• Tile指针：$A210 (4-4)
• Sprite指针：$7EA0 (RAM！)

Sprite指针在RAM中 = 未定义的sprites。游戏尝试在第一行tiles中显示Spiny ball或Bullet Bill blaster。这会立即崩溃。

; 当sprite指针指向RAM时，
; 游戏解压缩不断变化的字节
; 作为"生成"指令。结果：
; - 出现不存在的物体（未定义的值）
; - 当NES sprite尝试显示无效tile时PPU崩溃
; - 控制台完全死机

256个故障世界目录

RGMechEx编写了一个脚本，生成所有关卡的地图，覆盖4种区域类型，每种128个ID。

世界计数器是8位的（0-255）。世界1-8是合法的。还剩248个潜在的故障世界。每个故障世界对应这个世界的第一关，其Level ID通过WorldIndexTable的溢出机制计算。

在128个可能的ID中，只有68个是某个世界的"第一关"（可通过故障世界编号访问）。其余60个是第2关以上或不可访问的关卡。

类型	可玩的唯一ID	会导致崩溃的ID	空ID
Water (0)	~20	~60	~48
Overworld (1)	~30	~55	~43
Underground (2)	~15	~65	~48
Castle (3)	~25	~58	~45

许多ID指向相同的关卡，因为指针落在相同的ROM地址上。例如Level ID $28（Overworld）----tile指针 $A7CD (2-1)----出现在38个不同的故障世界中，因为其sprite指针 $9F51指向一个被用作填充/音效数据的ROM区域，许多ID共用这段数据。

真正独特的6个故障关卡

在19个可访问的glitch level ID中，只有6个不会在加载时立即崩溃：

World	Level ID	描述
E-1 (224)	$50	深渊上方只有一个?方块。Mario瞬间死亡。
W	$57	Mario被卡住，无法移动。
42 (133)	$50	云端隧道，Mario走得太远会被困住。
62 (131, 240)	$4D	冰冻城堡：Mario出生在顶部，无法下落→被卡住。
127	$4B	地下隧道，但走得太远会崩溃。
137	$4B	激活过场的自动滚动。Mario遇到一个唯一的砖块方块，永远挡住去路。

248个故障世界中只有6个产生了真正新的东西。其余的是使用了错误区域类型的正常关卡，或者是黑屏。

关卡格式详解

深入了解关卡数据的精确格式，理解故障关卡为何能运作（或不能）。

关卡头部：2字节，6个属性

每个关卡以一个2字节的头部开始，控制6个属性：

; Byte 0 : 计时器 + Y起始 + 修改器
;   Bit 7-6 : 计时器 (00=不变, 01=200, 10=300, 11=400)
;   Bit 5-3 : Mario的Y起始 (111/110 = 自动行走)
;   Bit 2-0 : 关卡类型修改器
;              000=默认, 001=波浪, 010=砖墙,
;              011=水底, 100=夜晚, 101=雪,
;              110=雪夜, 111=灰色夜晚

; Byte 1 : 平台 + 背景 + 地面图案
;   Bit 7-6 : 特殊平台 (00=树, 01=蘑菇,
;                         10=Bullet Bill, 11=云)
;   Bit 5-4 : 背景 (00=无, 01=云,
;                   10=山, 11=栅栏)
;   Bit 3-0 : 初始地面图案 (0-15)

类型修改器控制视觉变化：水关卡顶部的波浪、8-3的砖块背景、4-3的夜间调色板、6-2的雪景等等。

Tile物体：2字节，Next Screen Flag，3槽队列

头部之后是tile物体列表，每个物体2字节。字节$FD标记列表结束。

; Tile物体格式 (16位) :
; Byte 0 :
;   Bit 7-4 : X位置 (列 0-15)
;   Bit 3-0 : Y位置
;     Y=0-11  : 正常Y位置
;     Y=12    : 特殊物体（洞、桥、绳子、?方块）
;     Y=13    : 屏幕跳转 / 特殊物体2
;     Y=14    : 修改器/场景/地面切换
;     Y=15    : 特殊物体3（城堡、楼梯、大水管）

; Byte 1 :
;   Bit  7   : NEXT SCREEN FLAG
;   Bit 6-4 : 物体类型 (0-7)
;   Bit 3-0 : 宽度/高度 / 子类型

当"next screen"位置位时，当前工作列增加1。这允许在前16列之外放置物体。物体必须按顺序列出（从左到右），因为游戏是顺序加载的：

; 加载例程每列有两阶段：
; 阶段1：查找从此列开始的新物体
;         并将它们添加到队列中
; 阶段2：处理队列中的每个物体（绘制tiles），
;         并移除在此列结束的物体

队列正好有3个槽。直接后果：同一列上不能有超过3个物体开始。如果队列已满，第4个物体被忽略且永远不会被加载。

这就是为什么精心设计的关卡避免在同一列堆叠太多物体。例如在1-2中：天花板中的1up方块+旁边的砖块被分成两个不同的物体，以遵守3个的限制。

特殊Y位置：12, 13, 14, 15

当Y=12时，物体没有Y位置（由类型硬编码）：

; Y=12 : 无Y位置的物体
;   类型 0 : 洞（删除地面）
;   类型 1 : 移动平台的绳子
;   类型 2-4 : 固定Y的桥
;   类型 5 : 带水/岩浆的洞
;   类型 6-7 : ?方块排

当Y=13时，有两个子组。如果byte 1的bit 6为1：

; Y=13, bit6=1 : 特殊物体
;   0 = L-pipe (过场), 1 = flagpole, 2-3 = 桥/斧头/锤子（城堡结尾）
;   4 = 停止屏幕, 5 = 随机敌人, 6 = 循环关卡, 7+ = 可能崩溃

如果bit6=0，低5位编码一个屏幕跳转（直接跳到第N个屏幕，不用一个个通过next screen flag）。

当Y=14时：相同原理，bit6=1更改类型修改器，bit6=0更改背景+地面图案。

地面图案：16种地面模式

关卡的地面不是由单个物体组成的。SMB1使用地面图案，一个应用于所有列的背景模式，直到下一次更改：

; 地面图案 (4位 = 16种可能)
;   0 = 完全空白
;   1 = 2个tile高的地面
;   2 = 1个tile高的地面
;   3 = 地面 + 底部
;   4 = 地面 + 底部2
;   5 = 1/2 tile高的地面
;   6 = 3/4 地面
;   ... 直到 15 = 完全填充（地面 + 天花板）

这就是为什么洞是物体：它们在特定列覆盖地面图案，而不必为其余部分更改图案。

256字节限制和repeat

一个关卡的所有tile数据最多占256字节。6502的Y寄存器用作索引，它是8位的。如果游戏到达数据末尾时未找到$FD字节，它会回到开头并无限重复256字节：

; 索引Y = 8位 → 最多256字节的tile数据
; 如果Y溢出 (255 → 0) 且未遇到 $FD → 重复
; sprites也是如此，但水管物体 (3字节)
; 会在每次加载时改变索引的奇偶性。

某些故障关卡利用这个repeat来生成"无限持续"的关卡。

Sprite系统：2字节 + 水管过渡

Sprites使用类似的格式，但没有头部，且有一些关键差异。字节$FF标记列表结束。

; Sprite格式 (2字节) :
; Byte 0 : X位置 (列)
; Byte 1 :
;   Bit 7 : NEXT SCREEN FLAG
;   Bit 6-0 : sprite类型
;       某些类型包括：goomba, koopa, Blooper,
;       Bullet Bill, Lakitu, Spiny, 平台,
;       warp zone命令, toad/公主,
;       敌人群生成命令

Byte 1的最低位是hard level flag：如果置1，该sprite只出现在≥ 5-3的关卡中。这就是"hard mode"关卡的创建方式。

Y位置15 = 屏幕跳转（与tiles相同）。Y位置14 = 水管过渡（3字节）：

; Sprite Y=14 : 水管/藤蔓过渡 (3字节！)
;   Byte 0 : X位置
;   Byte 1 : bit 6-0 = 7位Level ID (目的地)
;   Byte 2 : bit 4-0 = 目标屏幕
;            bit 7-5 = 该过渡有效的世界
;
; 为什么要指定世界？奖励房间在不同世界之间复用。
; 例如：1-1的奖励房间也被2-1和7-1使用。
; 这个房间有3个过渡，每个世界一个，
; 让Mario在正确的位置重新出现。

Sprites没有队列系统。唯一的限制是在spawn区域（屏幕右侧外）中不能同时加载超过4个sprites。超过的sprites会被忽略。

如何访问故障世界

有两种主要方法。

经典方法：wall clip

Wall clip（穿墙）允许你离开正常关卡，走到隐藏的warp zone。通过RAM操纵世界计数器，你可以加载任何Level ID。

技术要点：

1. World 1-2：进入隐藏的结尾水管
2. 在右侧墙壁做wall clip
3. 走到空白区域直到warp zone
4. 游戏将值解释为世界

但这种方法只能访问一小部分故障世界。

极端方法：NES Tennis卡带交换

参见上方"Warm Start"部分了解完整细节。简而言之：Tennis的脚步计数器写入与SMB1启动世界相同的RAM字节，warm start检测保留了这个值。

修改者专区：全面探索的代码

如果你想在模拟器中自行探索所有故障关卡，可以直接修改Level ID：

; FCEUX / Mesen的补丁：
; RAM地址 $075F = 当前Level ID
; RAM地址 $0760 = Area Type (0=Water, 1=Overworld, 2=Underground, 3=Castle)

; 示例：在Overworld加载关卡57 (0x39)
; 在模拟器中，打开内存追踪器并写入：
; $075F = 0x39
; $0760 = 0x01
; 然后进入warp水管或死亡后重新开始
; → 游戏在Overworld加载关卡ID $39

RGMechEx在 rgmechex.com 上发布了完整的128关卡 × 4类型列表及自动生成的地图。每个条目显示tile指针、sprite指针和关卡的可视化地图。

最离谱的关卡

Level ID $1F (Water)：15个故障世界合而为一

Tile指针 $A302 (3-4) 加上sprite指针 $02A0 产生15个不同的故障世界（D-1, J-1, Y-1, Z-1, 55-1, 73-1...）。解释：sprite指针指向一个ROM区域，其中的数据足够接近有效sprites，能产生可玩的结果，但城堡3-4的tiles与overworld sprites的组合创造了荒谬的渲染。

Level ID $28 (Overworld)：38个故障世界 = 纪录

绝对纪录。38个故障世界条目指向同一个关卡（2-1 tiles + $9F51 sprites）。为什么？因为sprite指针 $9F51落在一个被用作填充/音效数据的ROM区域，许多ID共用这段数据。

Level ID $49 (Underground)：FDS关卡

Tile指针 $76AE + sprite指针 $1C9D。Tile指针指向为Famicom Disk System版本保留的ROM区域。结果：一个包含标准卡带中不存在的tiles的关卡。这就是产生52-1和196-1关卡的那个。

Level ID $00-$02：真正的奖励关卡

这些ID被游戏的合法子关卡使用：

• $00：5-2/6-2的水下区域（被H-1, 39-1使用）
• $01：2-2/7-2的水下（Minus World, 36-1）
• $02：8-4的子关卡（136-1, 151-1, 215-1）

正常可访问的"奖励"关卡和故障世界的区别在于，warp zone会验证当前世界：

; Warp zone验证（简化）
; 游戏验证目标世界在1到8之间
CheckWarp:
  lda TARGET_WORLD
  cmp #1
  bcc InvalidWarp       ; < 1 → 拒绝
  cmp #9
  bcs InvalidWarp       ; > 8 → 拒绝
  ; 只有1到8之间的世界有效
  jmp DoWarp

编号> 8或0的故障世界无法通过正常水管到达。需要wall clip或卡带交换。

为什么某些关卡崩溃：Jump Table

当游戏加载tile物体时，它使用物体类型作为跳转表中的索引：

; 标准tile物体跳转表 (类型 0-11)
JumpTable_TileObjects:
  .word Obj_Special       ; 类型 0 : ?方块, 隐藏方块, flagpole...
  .word Obj_Platform      ; 类型 1 : 特殊平台
  .word Obj_BrickRow      ; 类型 2 : 砖块排
  .word Obj_BlockRow      ; 类型 3 : 方块排
  .word Obj_CoinRow       ; 类型 4 : 金币排
  .word Obj_BrickCol      ; 类型 5 : 砖块列
  .word Obj_BlockCol      ; 类型 6 : 方块列
  .word Obj_Pipe          ; 类型 7 : 水管
  .word Obj_8             ; 类型 8
  .word Obj_9             ; 类型 9
  .word Obj_10            ; 类型 10
  .word Obj_11            ; 类型 11

如果物体有一个无效类型（≥12），游戏会跳转到一个在此表中不存在的指针。4种可能的结果：

1. 有效指针 → 物体正常加载
2. 指向另一个跳转表的指针（重叠） → 出现不同的物体。例如：类型12指向Y=13的表，这会产生一个L-pipe。
3. 指向可执行代码的指针 → 执行随机代码（可能崩溃）
4. 显式占位符（NOP） → 物体不做任何事（某些sprites就是这样，在原地飘动而不移动的敌人）

故障关卡ID $58（会崩溃的隧道）：其sprite指针指向一个在无mapper ROM的NES上不存在的内存区域。游戏尝试以每帧5次的频率在位置(0,0)加载同一个Koopa，导致PPU饱和并死机。

; ID $58 崩溃的原因：
; Sprite指针 → 无效地址（超出NES标准空间）
; → 游戏将不确定的字节读取为sprite类型
; → $00 Koopa（无处理程序的无效类型）进行递归调用循环
; → 6502栈溢出 → 死机

水管warp悖论

还记得检查 target_world BETWEEN 1 AND 8 吗？即使你在故障世界中找到一个水管，游戏也会验证目标世界在1到8之间。故障世界的编号> 8（36-1, 255-1...），因此warp会失败。

Minus World没有终点也是因为这个：flagpole不在sprites中，水管也不通向任何地方。

每列5个物体的技巧

存在一个边缘情况，可以突破每列3个物体的限制。当队列阻塞（槽位已满 + 下一个物体缺少next screen flag）时，游戏会在当前列"预处理"循环直到找到带有next screen flag的物体。在每次预处理期间：

; 在列预处理期间：
; 1. 队列中的物体在每次"假进列"时
;    宽度递减
; 2. 如果物体达到宽度=0，它会离开队列
; 3. 释放的槽位可以被添加到同一列的
;    新物体填充

; 结果：同一列上最多可以处理5个物体。
; 技巧：放置2个跨越屏幕边界的物体
; （槽位1和2），1个X < 前一个的虚拟物体（阻塞队列），
; 然后3个X=0的下一个屏幕的物体（其中一个是next screen flag）。

这被称为"队列跳转"，被某些romhackers用来创建比格式正常允许的更密集的关卡。

不同版本之间的差异

Famicom Disk System

SMB1的FDS版本有不同的内存映射。所有关卡指针都偏移了，但数据是相同的。变化之处：故障世界的索引完全不同：

FDS World 36 → Level ID $09 (5-3的水下版本)
  → flagpole存在！可以完成关卡。
  → 接着：$27 (正常的7-3) → $44 (地下的4-4)
  → $44可以完成 → 斧头有效 → 游戏通关！
  
FDS的Minus World因此是一个可以通向
游戏通关的"奖励世界"，与NES版本不同。

我最喜欢的FDS关卡：ID $5F，3-3后半段的地下版本，低矮隧道（可惜是一个自动卷轴关卡）。

The Lost Levels（日本版Super Mario Bros. 2）

Lost Levels改变了许多东西：

1. Tile/sprite相同顺序：不再有Frankenstein关卡（即使ID无效，tiles和sprites也加载相同的关卡）
2. 单一16位指针表，取代了两个独立的high/low表
3. 4个磁盘文件：ROM为FDS而拆分：
   • 文件1：世界1-4
   • 文件2：世界5-8
   • 文件3：世界9 + 音效引擎
   • 文件4：世界A-D（完全不同的指针表）
4. 相同Level ID = 根据加载的文件有4种可能的关卡
5. 没有Tennis glitch：continue选项（game over后继续到相同世界）使warm start变得不必要，如果world > 9游戏会立即重置
6. 新物体：毒蘑菇、隐形方块、隐形火力花方块、倒置水管、风----但插入在现有列表中间 → 与SMB1不兼容
7. Piranha Plants在world 4后总是红色的，springboards只在world 2/B/3/C/7是绿色的

Super Mario All-Stars (SNES)

直接移植，使用相同的6502例程（SNES以兼容模式执行NES代码）：

• Warp zone修复：不再有Minus World（在文本前进入左侧水管到达正确世界）
• 崩溃：大多数故障关卡崩溃（ID $6A和9-1除外）
• 城堡物体添加：渲染更加独特
• 但是：4-2错误warp仍然有效（未修复！）

4-2错误warp：一个物体放置bug

在4-2中，有两个水管过渡物体：藤蔓（warp zone）和水管（金币房间）。第一个过渡物体（藤蔓的）放置在藤蔓出现在屏幕上之前很远的位置。第二个（水管的）放置在关卡中太晚的位置。

; 4-2中的过渡时序：
; 过渡物体1 (藤蔓 → warp zone)：在藤蔓之前3个屏幕放置
; 过渡物体2 (水管 → 金币房间)：在水管之后1个屏幕放置
;
; 通常第一个物体会在Mario到达水管前被禁用。
; 但如果Mario速度很快（或使用B+右方块的快捷方式），
; 藤蔓的过渡在他碰到水管时仍然有效！
; → 游戏加载warp zone而非金币房间。
;
; 如果物体放在藤蔓之后但水管之前，
; 这个bug就不会存在。

循环关卡

Loop关卡（8-4, 7-4）如何工作？关卡有检查点，包含硬编码的屏幕编号和Y位置：

; 检查点：{screen_number, vertical_position}
; 如果Mario以正确的高度通过此检查点 → 关卡继续
; 否则 → 回退4个屏幕 (64 blocks)
;
; 要实现无限循环：vertical_position = $F0
; （在屏幕底部下方） → 无法通过。
;
; 检查点很简单（只有一个flag），除了world 7
; 它使用三元组（3个flag，至少要失败1个）
;
; 回退很粗暴：tile data偏移设置为硬编码值，
; sprite data偏移重置为0。存在的敌人
# 立即卸载 → firebars消失。

改变格式，不改变代码

这个架构最令人着迷的教训之一是，SMB1的开发者在不修改6502渲染代码的情况下，创造了一个非常有表现力的关卡系统。所有关卡之间的变化都来自数据（指针、物体、sprites、地面图案），而非代码。

256个故障世界存在是因为指针表为128个条目 × 4种类型做了空间分配，且游戏从不验证读取的值。当指针落在RAM中时，游戏将Mario的寄存器解释为tiles。当指针落在音效数据中时，游戏将音乐当作关卡设计来播放。当jump table溢出时，游戏执行任何东西直到崩溃。

从中可以学到什么

1. Tile/Sprite分离：两层完全独立，不同的存储顺序创造了独特的Frankenstein关卡
2. RLE压缩 + 物体系统：关卡不是位图而是放置的物体列表，使用地面图案处理地面
3. 3槽队列：硬件（和关卡设计）的严格限制
4. 无验证：游戏信任指针和jump table，这产生了可玩的glitch或崩溃
5. 最大256字节：6502 Y寄存器的限制，使得数据在走得太远时会重复
6. Warm start / cold start：一个"继续"系统为Tennis卡带交换 → Mario打开了大门

最精彩的是：这一切都是40KB中的6502代码。没有抽象层，没有内存访问验证，没有异常处理器。如果指针是垃圾，游戏就崩溃。而这些崩溃，我们称之为故障世界。

3个要点

1. 故障世界是落在错误位置的指针 -- 游戏有128个ID × 4种区域类型，但只有34个独立关卡。当世界编号被损坏（通过Tennis或wall clip）时，游戏加载一个为其他关卡设计的指针，512种可能组合产生不可预测的结果。

2. Minus World是warp bug加上损坏 -- 1-2中的左侧水管，如果在文本出现前激活，会加载world 36 (0x24)。这个world指向Level ID $01（2-2的水下），一个没有flagpole的关卡。由于world 36没有水管过渡，关卡无限循环。缺少验证创造了这个标志性的glitch。

3. Tennis → Mario，比OoT → Paper Mario早15年 -- NES的RAM在卡带交换中存活，得益于电容器和SMB1的warm start / cold start系统。Tennis的脚步计数器（通过播放脚步音效递增RAM字节）恰好落在世界编号的地址上。需要最高分数字保持为0、$A5字节完好、且游戏检测到warm start----一个只与Tennis一起成功的完美巧合。

Retro Game Mechanics Explained 的原始视频是令人叹为观止的细致工作----6502反汇编的详细程度、所有关卡的自动地图、卡带交换和warm start的解释。如果你还没看过这个系列，去看，很短，每一分钟都是干货。

地图的源代码在 rgmechex.com 上，SMB1的完整反汇编是开源的，在多个仓库中。40年前，日本程序员用6502编写了这个关卡系统，没有单元测试，没有bug追踪器，而我们今天打开他们的代码仍然能学到东西。

はじめに

Super Mario Bros.はROM 40キロバイト。8つのワールド、32のレベル、敵、音楽、パワーアップ、全部これに収まっている。

でもエミュレーターを開いて適当なバイトをいじれば、レベル36-1をロードできる。255-1もだ。Bowserのスプライトとどこにも繋がらないパイプだけで構成されたワールドに着地することもできる。

これらのグリッチワールドが存在するのは単純な理由によるものだ。SMB1のレベル保存システムは8ビットの最適化の傑作であり、ゲームに本来読むべきでない場所を読ませると、興味深い結果が生まれる。

Retro Game Mechanics Explainedがこれについて4本の動画シリーズを制作した -- 当時最も売れたゲームの6502コードを1本の深掘りにまとめよう。

ワームスタート：なぜテニスのRAMがSMB1で生き残るのか

レベルの保存について話す前に、SMB1がどのように起動するかを理解する必要がある。NESテニスのカートリッジ交換グリッチは、ゲームのワームスタート／コールドスタート検出システムに完全に依存しているからだ。

保持される41バイト

SMB1がコールドスタート（初回の電源投入または電源オフ→オン）を検出すると、すべてのRAMを消去する。しかしワームスタート（リセットボタン、電源切断なし）を検出すると、41バイトのメモリ領域を保持する：

; Les 41 bytes préservés en RAM lors d'un warm start
; Adresses $075F-$0787
;
; $075F : byte de démarrage (world - 1)    [1 byte]
; $0760 : flag de sélection de monde (B button) [1 byte]
; $0761-$0762 : inutilisé                    [2 bytes]
; $0763-$0768 : timer (6 digits, 3 affichés) [6 bytes]
; $0769-$076E : coins Luigi                   [6 bytes]
; $076F-$0774 : coins Mario                   [6 bytes]
; $0775-$077A : score Luigi                   [6 bytes]
; $077B-$0780 : score Mario                   [6 bytes]
; $0781-$0786 : top score (6 digits, 1 caché) [6 bytes]
; $0787 : le byte magique $A5                 [1 byte]

この41バイトは単一の機能のために使われる：ゲームオーバー後に同じワールドを続けること。6-3で死ぬと、ゲームはワールド6を起動バイトに書き込み、タイトル画面でA + Startを長押しすると6-1から再開できる。

ワームスタートの二重チェック

SMB1は起動時に1つの条件だけでなく2つを確認する：

CheckWarmStart:
  ; 1. Vérifier le byte magique $A5 à $0787
  lda $0787
  cmp #$A5
  bne ColdStart        ; pas $A5 → cold start

  ; 2. Vérifier les 6 digits du top score ($0781-$0786)
  ;    Chaque digit doit être entre 0 et 9
  ldx #0
CheckLoop:
  lda $0781,x
  cmp #$0A
  bcs ColdStart        ; digit >= 10 → cold start
  inx
  cpx #6
  bne CheckLoop

  ; Si les deux conditions passent → warm start
  ; La RAM n'est pas effacée, le monde de départ est préservé
  jmp WarmStartBoot

なぜ二重チェックなのか？ バイト$A5が偶然存在する可能性があるからだ（別のゲームがこの値を残した、あるいはRAMチップのデフォルトの待機状態など）。トップスコアの桁が有効（0-9）であることを確認することで、データが整合していることを保証している。

なぜテニスだけが機能するのか

SMB1を初めて挿入すると（コールドスタート）、ゲームは：

1. すべてのRAMを消去 → トップスコア = 0、ワールドバイト = 0
2. アドレス$0787に$A5を書き込む

その後、コンソールを消さずにテニスに切り替える。テニスは：

• 起動時にRAMをクリーンアップしない（NESのほとんどのゲームは这样做らない）
• トップスコアのバイトに書き込まない → 0のまま（有効）
• バイト$A5に触れない → そのまま残る
• アドレス$075Fをプレイヤーの歩数カウンターに使う

; Le footstep increment dans Tennis :
; À chaque pas du joueur sur le court, Tennis incrémente le byte à $075F.
; Ce même byte est utilisé par SMB1 comme "world number - 1".
;
; 0 pas  → world 0 → SMB1 = world 1
; 1-7 pas → world 1-7 → worlds normaux
; 8+ pas → world 8+ → glitch worlds !
;
; Le compteur ne s'incrémente que quand la musique s'arrête
; (les footstep sounds ne jouent pas pendant la musique).

SMB1を戻すと：

1. バイト$A5はまだthere（テニスが触っていない）
2. トップスコアの桁はまだ0（有効）
3. ワールドバイトは現在8以上（テニスの歩数でインクリメントされた）
4. SMB1がワームスタートを検出 → 破損したワールドバイトを保持
5. A + Startを長押し → world 9-1、world A-1、world 36-1など

なぜ先にMarioを起動してからテニスに切り替える必要があるのか

細かい点がある：まずSMB1を起動し、次にテニス、そして再度SMB1を起動する必要がある。最初からテニスを始めた場合、バイト$A5は書き込まれない（テニスは$A5を書き込まない）。そのためワームスタート検出に失敗し、RAMが消去されてしまう。

SMB1が40KBにレベルを保存する方法

Nintendo R&D4は一見単純な問題を解決する必要があった：水平スクロールするタイル、敵、アイテムを備えたレベルを、ROMの超strictな予算内で表現することだ。

解決策は、完全に独立した2つのデータレイヤーに分離することだった：

タイルレイヤー（レベルの地図）

各レベルはROM内の圧縮されたタイル構造へのポインタで定義される。圧縮は原始的だが天才的だ：「コントロール」バイトの後に1-3バイトのデータが続く。

タイルフォーマットはラン（RLE風）システムを使用する：

; Format tile SMB1 (simplifié)
; Chaque "commande" est un byte contrôle :
;
; $00-$7F : pose une tile, avance d'1 colonne
; $80-$BF : pose une tile répétée N fois (N = byte - $80 + 1)
; $C0-$FF : commande spéciale (fin de ligne, saut, changement de palette)

Exemple : pour dessiner 3 briques consécutives :
  $82 $01    ; répète la tile $01 (brick) 3 fois

各レベルは16列 × 13行のタイル（13×16 = 208タイルの可視領域）を含む。しかし圧縮フォーマットにより、もっと小さくすることができる -- 例えば空や空の列はほとんどスペースを取らない。

6502のレンダリングループ：

; Décompression tile - loop principale
; Entrée : pointeur tile_data en $XX
; Sortie : tilemap niveau dans la RAM PPU

DecompressTile:
  lda (tile_ptr),y      ; lire byte contrôle
  iny
  cmp #$80
  bcc SingleTile        ; $00-$7F : tile unique
  cmp #$C0
  bcc RunLength         ; $80-$BF : run-length
  jmp SpecialCommand    ; $C0-$FF : commande spéciale

SingleTile:
  sta PPU_DATA          ; écrire la tile directement
  jmp Next

RunLength:
  sec
  sbc #$7E              ; N = control - $7E
  tax
  lda (tile_ptr),y      ; lire la tile à répéter
  iny
: sta PPU_DATA
  dex
  bne :-
  jmp Next

スプライトレイヤー（敵とオブジェクト）

並行して、敵とオブジェクト（?ブロック、パイプ、クリボー、ノコノコ）は完全に別の構造に保存される。各スポーンは2バイトで定義される：

; Format sprite SMB1
; Byte 0 : position X (en colonnes)
; Byte 1 : type de sprite + bits de page Y
; Y est dérivé de l'index dans la séquence

Une séquence de sprites :
  $01 $4B    ; goomba à la colonne 1
  $09 $4B    ; goomba à la colonne 9
  $10 $61    ; bloc ? à la colonne 16 (contient pièce)
  $15 $54    ; koopa verte à la colonne 21
  $FF        ; fin de séquence

各レベルは最大5ページの異なるスプライトを参照できる（つまり16列の5「スクリーン」）。しかし実際にはほとんどのレベルは2-3しか使わない。

ポインタテーブル

設計の天才はポインタテーブルにある。各レベルはROMアドレスのペアとして保存される：

// Structure interne (simplifiée) du World Map
struct LevelPointer {
    uint16_t tile_ptr;   // Adresse ROM des données tiles
    uint16_t sprite_ptr; // Adresse ROM des données sprites
};

// 4 tables séparées, une par AreaType :
// 0 = Water, 1 = Overworld, 2 = Underground, 3 = Castle
LevelPointer level_table[4][128];

テーブルごとに128エントリ。4つのエリアタイプ。512の組み合わせが可能だが、公式ゲームが使用するのはその一部のみ。残りは未初期化のRAMや、ポインタとして解釈されるデータだ。

ゲームがレベルをロードする際、以下のように行われる：

; Chargement d'un niveau
; A = AreaType (0-3), X = LevelID (0-127)

LoadLevel:
  sta AREA_TYPE
  asl                  ; *2 pour offset dans table 16-bit
  tax
  lda LevelTable_TilePtr, x
  sta TILE_PTR
  lda LevelTable_TilePtr+1, x
  sta TILE_PTR+1       ; pointeur vers les tiles
  lda LevelTable_SpritePtr, x
  sta SPRITE_PTR
  lda LevelTable_SpritePtr+1, x
  sta SPRITE_PTR+1     ; pointeur vers les sprites
  jsr DecompressTiles

バリデーションなし。ポインタが有効かどうかのチェックなし。ゲームはテーブル内のアドレスを読み、そのアドレスにあるものを解凍する。それだけだ。

34のユニークレベルと7ビットIDシステム

SMB1には32レベルではなく、34のユニークレベルがある。多くのレベルは重複（5-3 = 1-3だがBullet Billあり）で、"ハードモード"フラグでマークされている。本物のユニークレベルは：

• 水（タイプ0）：3レベル（2-2、7-2、ボーナスエリア5-2/6-2）
• オーバーワールド（タイプ1）：22レベル（2つの雲ボーナスルームを含む）
• アンダーグラウンド（タイプ2）：3レベル（地下ボーナスルームを含む）
• キャッスル（タイプ3）：6レベル
• + 1カットシーンルーム（地下/水中のレベルの前）
• + 14-2のワープゾーン

各レベルは7ビットのIDを持つ。下位5ビット = サブグループ内の番号、上位2ビット = エリアタイプ：

; Encodage 7-bit du Level ID
; Bits 6-5 : Type (00=Water, 01=Overworld, 10=Underground, 11=Castle)
; Bits 4-0 : Numéro dans le sous-groupe
;
; Water IDs      : $00-$02  (types 00, numéros 0-2)
; Overworld IDs  : $20-$35  (types 01, numéros 0-21)
; Underground IDs: $40-$42  (types 10, numéros 0-2)
; Castle IDs     : $60-$65  (types 11, numéros 0-5)
;
; ID $25 = %0100101 → type 01 (Overworld), numéro 5 → 1-1
; ID $23 = %0100011 → type 01 (Overworld), numéro 3 → 6-2

128の可能なID（$00-$7F）、34のみが実在のレベルに割り当てられている。未使用のIDはどこを指してもおかしくない。

ポインタテーブル：2つのリスト、2つの順序

タイルポインタとスプライトポインタは同じ順序で保存されていない。コードは2つの16ビットリストを別々に使用する（high byte / low byteを2つの別テーブルに格納）：

Ordre des pointeurs sprites :
  Index 0-5   : Castle (6 niveaux)
  Index 6-27  : Overworld (22 niveaux)
  Index 28-30 : Underground (3 niveaux)
  Index 31-33 : Water (3 niveaux)

Ordre des pointeurs tiles :
  Index 0-2   : Water (3 niveaux)
  Index 3-24  : Overworld (22 niveaux)
  Index 25-27 : Underground (3 niveaux)
  Index 28-33 : Castle (6 niveaux)

なぜ異なる順序なのか？ 技術的な理由はない -- 開発中にデータがこのように整理されたのだろう。しかし興味深い結果を生む：レベルIDが無効な場合、タイルポインタとスプライトポインタが異なるレベルをロードし、Frankensteinレベルが生まれる。

この2つのリスト間をナビゲートするために、ゲームは小さなオフセットテーブル（目次のようなもの）を使う：

; Tables d'offset par type (Water, Overworld, Underground, Castle)
; Chaque entrée = index de début dans la liste correspondante

SpriteOffsetTable:
  .byte $1F, $06, $1C, $00    ; Water=31, Overworld=6, Underground=28, Castle=0

TileOffsetTable:
  .byte $00, $03, $19, $1C    ; Water=0, Overworld=3, Underground=25, Castle=28

6-2（ID $23、オーバーワールド番号3）をロードする場合：

; 1. Type = 01 (Overworld) → index dans table d'offset = 1
; 2. Sprite offset = SpriteOffsetTable[1] = 6
;    Index final = 6 + 3 (numéro de niveau) = 9 → 10ème pointeur sprites
; 3. Tile offset = TileOffsetTable[1] = 3
;    Index final = 3 + 3 = 6 → 7ème pointeur tiles
; 4. Résultat : pointeur tiles $A619 + pointeur sprites $9ED0 = 6-2 ✓

では、$43のような無効なID（アンダーグラウンド番号3、存在しない）はどうなるか？

; ID $43, Type = 10 (Underground), numéro = 3
; Sprite offset = SpriteOffsetTable[2] = $1C = 28
;   Index = 28 + 3 = 31 → 32ème pointeur sprites = eau bonus 5-2 !
; Tile offset = TileOffsetTable[2] = $19 = 25
;   Index = 25 + 3 = 28 → 29ème pointeur tiles = 1-4 (Castle) !
;
; Résultat : un niveau souterrain avec les tiles de 1-4
; et les Bloopers de la zone eau de 5-2. Un vrai Frankenstein.

ワールドインデックステーブル：なぜWorld 9がオーバーフローするのか

各ワールド（1-8）の最初のレベルのインデックスを与える8バイトのROMテーブルがある。その直後、ゲーム順ですべての36Level IDのテーブルがある。

; WorldIndexTable (8 bytes)
  .byte 0, 5, 10, 15, 20, 25, 28, 33
;   -> Monde 1 commence au niveau 0
;   -> Monde 2 commence au niveau 5
;   -> Monde 8 commence au niveau 33

; LevelIDTable (36 bytes)
  .byte $25, $28, $29, $26, $24, ... ; les 36 Level IDs

World 9をロードしようとすると、ゲームはWorldIndexTableの9バイト目を読む...がそれは存在しない。LevelIDTableに1バイトオーバーフローし、値$25を読み、その$25をLevelIDTableのインデックスとして使用する（37番目のエントリ）-- これによりSpriteOffsetTableに2バイトオーバーフローし、値6を読む。

; World 9 :
;   1. WorldIndexTable[8] (overflow) → lit $25 dans LevelIDTable
;   2. LevelIDTable[37] (overflow) → lit le 2ème byte de SpriteOffsetTable = 6
;   3. ID = 6 → Water level number 6 (qui n'existe pas)
;   4. Tile pointer = pointeur water numéro 6 = tiles de 6-2
;   5. Sprite pointer = index 31+6 = 37 > 33 → pointeur invalide
;   6. Résultat : 6-2 sous l'eau avec des sprites glitchés
;      → world 9-1 !

World G（16）では、オーバーフローはさらに遠く、Level ID $01に到達する。これは1-2の前のカットシーンレベルだ：

; World G (16) :
;   WorldIndexTable[15] → lit $01 dans LevelIDTable
;   LevelIDTable[1] = $29 (cutscene 1-2)
;   → world G-1 = la cutscene d'entrée de 1-2

グリッチワールドが存在する理由

ゲームには32の「正規」レベル（8ワールド × 4レベル）がある。しかしポインタテーブルはエリアタイプごとに128エントリある。32以降のエントリには、そのROMアドレスにあるデータが入っている -- 時には別のレベル、有时はサウンドデータ、有时はRAM、有时はただのゴミ。

Level ID $01 + AreaType 0 = Minus World

最も有名なグリッチワールド。Level ID $01のAreaType 0（水）は以下を指す：

• タイルポインタ：$AE45 → 2-2/7-2の水中エリア
• スプライトポインタ：$A171 → 2-2/7-2のスプライト

結果：2-2に似た水中レベルだが、flagpoleが存在しないので無限にループする。レベルの終わりなし、出口なし。

これはレベル36-1（またはワールド$-1の36-1）だ。

; Pourquoi le flagpole manque dans le Minus World :
; Les sprites de 2-2/7-2 ($A171) n'ont pas de flagpole
; dans leur séquence. Le jeu cherche le sprite $FD (flagpole)
; mais ne le trouve jamais → boucle infinie
;
; Le jeu continue de générer le niveau à l'infini
; jusqu'à ce que le timer atteigne zéro.

RAMを指すポインタ

タイルポインタやスプライトポインタがROMではなくRAMのアドレス（$00-$7F）を指すと、ゲームはRAMのconstantな変化をタイルとして解釈しようとする：

; Exemple : Level ID $03 en Water
; Tile Pointer : $A46B (3-3 - valide)
; Sprite Pointer : $009D (pointe vers la RAM page zéro !)
;
; La RAM page zéro contient les registres du jeu,
; la position de Mario, l'état des compteurs...
; Le jeu décompresse ça comme une séquence de sprites,
; et le résultat c'est un niveau avec des ennemis
; qui sont en fait des valeurs de registres.

ゼロページが変化すると（Marioが動いたり、タイマーが回ったり）、レベルの「スプライト」も変わる。だから一部のグリッチワールドでは敵が点滅し、constantに変化するのだ。

Level ID $36：空のレベル（Overworld）

Level ID $36のOverworld：

• タイルポインタ：$AC35（1-2）
• スプライトポインタ：$A0D8（1-2）

結果：何もなし。ゲームはレベルをロードするが、RGMechExのカタログでは「レベルなし」とマークされている。タイルは有効かもしれないが、スプライトが空のレベルまたは機能しないレベルを生成する場所を指している。

Level ID $1D（Castle）：クラッシュの王者

Level ID $1DのCastle：

• タイルポインタ：$A210（4-4）
• スプライトポインタ：$7EA0（RAM！）

スプライトポインタがRAM = 未定義スプライト。ゲームはタイルの最初の行にSpiny ballやBullet Bill blasterを表示しようとする。即座にクラッシュ。

; Quand le sprite pointer pointe vers la RAM,
; le jeu décompresse des bytes qui changent tout le temps
; comme des instructions "spawn". Le résultat :
; - Apparition d'objets inexistants (valeur undefined)
; - Crash PPU quand le sprite NES essaie d'afficher un tile invalide
; - Freeze complet de la console

カタログ化された256のグリッチワールド

RGMechExはすべてのレベルのマップを生成するスクリプトを作成した。4つのエリアタイプすべて、それぞれ128IDだ。

ワールドカウンターは8ビット（0-255）。ワールド1-8は正規。残り248のグリッチワールドが潜在的に存在する。各グリッチワールドはそのワールドの最初のレベルに対応し、Level IDはWorldIndexTableのオーバーフローメカニズムで計算される。

128の可能なIDのうち、68のみがワールドの「最初のレベル」（グリッチワールド番号でアクセス可能）。残り60はレベル2以上またはアクセス不可能。

タイプ	プレイ可能なユニークID	クラッシュするID	空のID
Water（0）	~20	~60	~48
Overworld（1）	~30	~55	~43
Underground（2）	~15	~65	~48
Castle（3）	~25	~58	~45

多くのIDが同じポインタが同じROMアドレスを指すため、同じレベルに至る。例えばLevel ID $28（Overworld）-- タイルポインタ$A7CD（2-1）-- は38の異なるグリッチワールドに出現する。スプライトポインタ$9F51がROMのサウンドデータ/パディング領域を指し、多くのIDが再利用しているからだ。

本当にユニークな6つのグリッチレベル

アクセス可能な19のグリッチレベルIDのうち、ロード時に即座にクラッシュしないのは6のみ：

ワールド	Level ID	説明
E-1（224）	$50	穴の上に?ブロックが1つ。Marioは即死。
W	$57	Marioがスポーンして動けない。
42（133）	$50	雲のトンネル。十分進むとMarioが閉じ込められる。
62（131、240）	$4D	凍った城：Marioが上にスポーンし、落ちられない → ロック。
127	$4B	地下トンネル。だが進みすぎるとクラッシュ。
137	$4B	カットシーンの自動スクロールを有効化。Marioが唯一のbrick blockに永久にブロックされる。

248のグリッチワールドのうち、本当に新しいものを生み出すのは6のみ。残りは間違ったエリアタイプの通常レベルか、黒い画面だ。

レベルフォーマットの詳細

グリッチレベルが成立する（しない）理由を理解するため、レベルデータの正確なフォーマットに飛び込む。

レベルヘッダー：2バイト、6プロパティ

各レベルは2バイトのヘッダーで始まり、6プロパティを制御する：

; Byte 0 : timer + Y start + modifier
;   Bits 7-6 : timer (00=inchangé, 01=200, 10=300, 11=400)
;   Bits 5-3 : Y start Mario (111/110 = autowalk)
;   Bits 2-0 : level type modifier
;              000=default, 001=waves, 010=brick wall,
;              011=water bottom, 100=night, 101=snow,
;              110=snow night, 111=gray night

; Byte 1 : platform + background + floor pattern
;   Bits 7-6 : special platform (00=tree, 01=mushroom,
;                                 10=Bullet Bill, 11=cloud)
;   Bits 5-4 : background (00=none, 01=clouds,
;                           10=montains, 11=fences)
;   Bits 3-0 : floor pattern initial (0-15)

タイプモディファイアは視覚的なバリエーションを制御する：水中レベルの波、8-3のbrick背景、4-3のナイトパレット、6-2の雪など。

タイルオブジェクト：2バイト、Next Screen Flag、3スロットのキュー

ヘッダーの後にはタイルオブジェクトのリストが続く。各オブジェクトは2バイト。バイト$FDがリストの終わりを示す。

; Format objet tile (16 bits) :
; Byte 0 :
;   Bits 7-4 : X position (colonne 0-15)
;   Bits 3-0 : Y position
;     Y=0-11  : position Y normale
;     Y=12    : objets spéciaux (trous, ponts, rope, ? blocks)
;     Y=13    : screen skip / objets spéciaux 2
;     Y=14    : changement de modifier/scenery/floor
;     Y=15    : objets spéciaux 3 (château, escaliers, gros tuyau)

; Byte 1 :
;   Bit  7   : NEXT SCREEN FLAG
;   Bits 6-4 : type d'objet (0-7)
;   Bits 3-0 : largeur/hauteur / sous-type

「next screen」ビットが立つと、作業中の列が1インクリメントされる。これにより16列目以降にオブジェクトを配置できる。オブジェクトは順番に（左から右へ）リストする必要がある。ゲームが順番にロードするからだ：

; La routine de chargement a DEUX phases par colonne :
; Phase 1 : chercher les nouveaux objets qui commencent sur cette colonne
;            et les ajouter à la file d'attente (queue)
; Phase 2 : traiter chaque objet dans la queue en dessinant les tiles,
;            et retirer ceux qui finissent sur cette colonne

キューは正確に3スロット。直接的な結果：同じ列で始まるオブジェクトは3つ以上持てない。キューが満杯の場合、4番目のオブジェクトは無視され、ロードされない。

だから設計の良いレベルはオブジェクトの詰め込みを避ける。1-2の例：天井の1upブロックがある列 + 横のbrickは、3の制限を守ために2つの別オブジェクトに分割されている。

特殊なY位置：12、13、14、15

Y=12の場合、オブジェクトにはY位置がない（タイプでハードコードされている）：

; Y=12 : objets sans Y position
;   Type 0 : trou (supprime le sol)
;   Type 1 : rope de plateforme mobile
;   Types 2-4 : ponts à Y fixe
;   Type 5 : trou avec eau/lave
;   Types 6-7 : rangées de ? blocks

Y=13の場合、2つのサブグループがある。バイト1のビット6が1の場合：

; Y=13, bit6=1 : objets spéciaux
;   0 = L-pipe (cutscene), 1 = flagpole, 2-3 = pont/axe/hamer (fin château)
;   4 = stop screen, 5 = random enemies, 6 = loop level, 7+ = crash possible

ビット6=0の場合、下位5ビットがスクリーンスキップ（next screen flagを1つずつ使わずに、スクリーンNに直接ジャンプ）をエンコードする。

Y=14の場合：同じ原理でビット6=1はタイプモディファイアの変更、ビット6=0は背景 + フロアパターンの変更。

フロアパターン：16種類の床パターン

レベルの床は個別のオブジェクトで構成されていない。SMB1はフロアパターンを使用する。次の変更まで全列に適用される背景パターンだ：

; Floor patterns (4 bits = 16 possibilités)
;   0 = vide total
;   1 = sol 2 tiles haut
;   2 = sol 1 tile haut
;   3 = sol + bottom
;   4 = sol + bottom 2
;   5 = sol 1/2 tile
;   6 = 3/4 sol
;   ... jusqu'à 15 = rempli total (sol + plafond)

だから穴はオブジェクトだ：特定の列でフロアパターンをオーバーライドし、残りのパターンを変更せずに済む。

256バイトの制限とリピート

すべてのタイルデータは最大256バイトに収まる。6502のYレジスタがインデックスとして使われ、8ビットだ。$FDバイトを見つけずにデータの末尾に達した場合、最初に戻って256バイトを無限に繰り返す：

; Index Y = 8 bits → max 256 bytes de données tiles
; Si Y overflow (255 → 0) sans rencontrer $FD → repeat
; Même chose pour les sprites, mais les objets pipe (3 bytes)
; décalent la parité de l'index à chaque chargement.

一部のグリッチレベルはこのリピートを利用して、「無限」に続くレベルを生成する。

スプライトシステム：2バイト + パイプトランジション

スプライトは同様のフォーマットに従うが、ヘッダーがなく、いくつかの重要な違いがある。バイト$FFがリストの終わりを示す。

; Format sprite (2 bytes) :
; Byte 0 : position X (colonne)
; Byte 1 :
;   Bit 7 : NEXT SCREEN FLAG
;   Bits 6-0 : type de sprite
;       Certains types incluent : goomba, koopa, Blooper,
;       Bullet Bill, Lakitu, Spiny, plateformes,
;       commande warp zone, toad/princesse,
;       commandes de spawn de groupes d'ennemis

バイト1の最下位ビットはハードレベルフラグ：1に設定されると、スプライトは5-3以上のレベルにのみ出現する。これで「ハードモード」レベルが作られる。

Y位置15 = スクリーンスキップ（タイルと同じ）。Y位置14 = パイプトランジション（3バイト）：

; Sprite Y=14 : pipe/vine transition (3 bytes !)
;   Byte 0 : position X
;   Byte 1 : bits 6-0 = Level ID 7-bit (destination)
;   Byte 2 : bits 4-0 = screen de destination
;            bits 7-5 = world où cette transition est valide
;
; Pourquoi un world ? Les bonus rooms sont réutilisées entre mondes.
; Exemple : la salle bonus de 1-1 est aussi utilisée par 2-1 et 7-1.
; Cette salle a 3 transitions, une par monde, pour que Mario
; réapparaisse au bon endroit.

スプライトにはキューシステムがない。唯一の制限は、スポーンゾーン（画面右のすぐ外）に同時にロードできるスプライトが4つ以下であること。それ以上はスプライトが無視される。

グリッチワールドへのアクセス方法

主に2つの方法がある。

クラシックな方法：壁抜け

壁抜け（壁を通り抜ける）により、通常のレベルから脱出し、隠されたワープゾーンまで歩くことができる。RAM経由でワールドカウンターを操作することで、任意のLevel IDをロードできる。

テクニック：

1. World 1-2：隠された終点パイプに入る
2. 右の壁で壁抜けを行う
3. ワープゾーンまで虚空を歩く
4. ゲームが値をワールドとして解釈する

しかし、この方法はグリッチワールドの一部にしかアクセスできない。

極端な方法：NESテニスカートリッジ交換

詳細は上の「ワームスタート」セクションを参照。要するに：テニスの歩数カウンターがSMB1のワールドバイトと同じRAMバイトに書き込み、ワームスタート検出がこの値を保持する。

ハッカー向け：すべてを探索するコード

エミュレーターですべてのグリッチを自分で探索したい場合、Level IDに直接パッチを当てることができる：

; Patch pour FCEUX / Mesen :
; Adresse RAM $075F = Level ID actuel
; Adresse RAM $0760 = Area Type (0=Water, 1=Overworld, 2=Underground, 3=Castle)

; Exemple : charger le Level 57 (0x39) en Overworld
; Dans l'émulateur, ouvrir le traceur mémoire et écrire :
; $075F = 0x39
; $0760 = 0x01
; Puis entrer dans un tuyau de warp ou mourir et recommencer
; → Le jeu charge le niveau ID $39 en Overworld

RGMechExは128レベル × 4タイプの完全なリストと自動生成されたマップをrgmechex.comに公開している。各エントリにはタイルポインタ、スプライトポインタ、レベルの視覚マップが表示される。

最もクレイジーなレベル

Level ID $1F（Water）：1つで15のグリッチワールド

タイルポインタ$A302（3-4）にスプライトポインタ$02A0を組み合わせると、15の異なるグリッチワールド（D-1、J-1、Y-1、Z-1、55-1、73-1...）が生成される。説明：スプライトポインタがROMのサウンドデータ/パディング領域を指し、有効なスプライトに近いデータを含むためプレイ可能な結果を生む。しかし3-4のキャッスルタイルとオーバーワールドスプライトの組み合わせは、意味のないレンダリングを生む。

Level ID $28（Overworld）：38のグリッチワールド = 記録

絶対記録。38のグリッチワールドエントリが同じレベル（2-1タイル + $9F51スプライト）を指す。なぜ？ スプライトポインタ$9F51がROMのサウンドデータ/パディング領域を指し、多くのIDが再利用しているからだ。

Level ID $49（Underground）：FDSレベル

タイルポインタ$76AE + スプライトポインタ$1C9D。タイルポインタがFamicom Disk System用に予約されたROM領域を指す。結果：標準カートリッジには存在しないタイルを持つレベル。これがレベル52-1と196-1を生み出す。

Level ID $00-$02：本物のボーナスレベル

これらのIDはゲームの正規サブレベルに使用される：

• $00：5-2/6-2の水中エリア（H-1、39-1で使用）
• $01：2-2/7-2の水（Minus World、36-1）
• $02：8-4のサブレベル（136-1、151-1、215-1）

通常アクセス可能な「ボーナス」レベルとグリッチワールドの違いは、ワープゾーンが現在のワールドをチェックすることだ：

; Vérification warp zone (simplifié)
; Le jeu vérifie que le monde cible est entre 1 et 8
CheckWarp:
  lda TARGET_WORLD
  cmp #1
  bcc InvalidWarp       ; < 1 → refusé
  cmp #9
  bcs InvalidWarp       ; > 8 → refusé
  ; world valide entre 1 et 8 uniquement
  jmp DoWarp

番号が8超または0のグリッチワールドは通常のパイプでは到達できない。壁抜けまたはカートリッジ交換が必要だ。

なぜ一部のレベルがクラッシュするのか：ジャンプテーブル

ゲームがタイルオブジェクトをロードする際、タイプをジャンプテーブルのインデックスとして使う：

; Jump table des objets tiles standards (types 0-11)
JumpTable_TileObjects:
  .word Obj_Special       ; type 0 : bloc ?, hidden, flagpole...
  .word Obj_Platform      ; type 1 : plateforme spéciale
  .word Obj_BrickRow      ; type 2 : rangée de briques
  .word Obj_BlockRow      ; type 3 : rangée de blocks
  .word Obj_CoinRow       ; type 4 : rangée de pièces
  .word Obj_BrickCol      ; type 5 : colonne de briques
  .word Obj_BlockCol      ; type 6 : colonne de blocks
  .word Obj_Pipe          ; type 7 : tuyau
  .word Obj_8             ; type 8
  .word Obj_9             ; type 9
  .word Obj_10            ; type 10
  .word Obj_11            ; type 11

オブジェクトが無効なタイプ（≥12）を持つ場合、ゲームはこのテーブルに存在しないポインタにジャンプする。4つの結果が可能：

1. 有効なポインタ → オブジェクトが通常通りロードされる
2. 別のジャンプテーブルへのポインタ（オーバーラップ） → 異なるオブジェクトが出現。例：タイプ12がY=13テーブルを指し、L-pipeになる
3. 実行可能コードへのポインタ → ランダムコードの実行（クラッシュの可能性大）
4. 明示的なプレースホルダー（NOP） → オブジェクトが何もしない（一部のスプライトはこのように、動かない空中浮遊の敵を生成する）

グリッチレベルID $58（クラッシュするトンネル）：スプライトポインタがROMマッパーなしのNESには存在しないメモリ領域を指す。ゲームは（0,0）位置に同じKoopaを1フレームに5回ロードしようとして、PPUを飽和させ、フリーズを引き起こす。

; Pourquoi ID $58 crashe :
; Sprite pointer → adresse invalide (hors espace NES standard)
; → Le jeu lit des bytes indéterminés comme des types de sprite
; → Le Koopa $00 (type invalide sans handler) boucle en appel récursif
; → Stack overflow 6502 → freeze

パイプワープのパラドックス

target_world BETWEEN 1 AND 8のチェックを覚えているか？ グリッチワールドでパイプを見つけたとしても、ゲームは目的地のワールドが1-8の間であることを確認する。グリッチワールドは番号が8超（36-1、255-1...）なので、ワープは失敗する。

Minus Worldに終わりがないのもそのためだ：flagpoleがスプライトに存在せず、パイプはどこにも繋がらない。

1列に5つのオブジェクトのトリック

3オブジェクト/列の制限を上書きするエッジケースが存在する。キューがブロックされた場合（スロット満杯 + 次のオブジェクトにnext screen flagなし）、ゲームはnext screen flagを持つオブジェクトが見つかるまで現在の列をループで「プレプロセス」する。各プレプロセスで：

; Pendant le prétraitement de colonne :
; 1. Les objets dans la queue voient leur largeur restante
;    décrémentée à chaque "fausse avancée" de colonne
; 2. Si un objet atteint largeur=0, il quitte la queue
; 3. Un slot libéré peut être rempli par un nouvel objet
;    ajouté dans la même colonne

; Résultat : jusqu'à 5 objets peuvent être traités sur la même colonne.
; Technique : placer 2 objets qui traversent la screen boundary
; (slots 1 et 2), 1 objet dummy en X < précédent (bloque la queue),
; puis 3 objets à X=0 de l'écran suivant (dont un avec next screen flag).

これは「キュースキップ」と呼ばれ、一部のROMハッカーがフォーマットが通常許すより密度の高いレベルを作成するために使用している。

バージョン間の違い

Famicom Disk System

SMB1のFDSバージョンはメモリマップが異なる。すべてのレベルポインタがシフトされているが、データは同じ。違い：グリッチワールドのインデックスが完全に異なる：

FDS World 36 → Level ID $09 (eau version de 5-3)
  → Le flagpole est présent ! On peut finir le niveau.
  → Ensuite : $27 (7-3 normal) → $44 (4-4 underground)
  → $44 est finissable → la hache fonctionne → fin du jeu !
  
Le Minus World FDS est donc un "bonus world" qui peut mener
à la complétion du jeu, contrairement à la version NES.

お気に入りのFDSレベル：ID $5F、3-3の後半の地下バージョン（ autoscrollingなのが残念だが）。

The Lost Levels（Super Mario Bros. 日本版）

Lost Levelsは多くのことを変える：

1. タイル/スプライトの同じ順序：Frankensteinレベルなし（無効なIDでもタイルとスプライトが同じレベルをロードする）
2. 1つの16ビットポインタテーブル（high/lowの2テーブルではなく）
3. 4つのディスクファイル：ROMがFDS用に分割された：
   • ファイル1：ワールド1-4
   • ファイル2：ワールド5-8
   • ファイル3：ワールド9 + サウンドエンジン
   • ファイル4：ワールドA-D（完全に異なるポインタテーブル）
4. 同じLevel ID = 4つの可能なレベル（ロードされたファイルによる）
5. テニスグリッチなし：コンティニューオプション（ゲームオーバー後に同じワールドを続ける）がワームスタートを不要にし、ワールド > 9の場合即座にリセットする
6. 新しいオブジェクト：毒キノコ、不可視ブロック、不可視ファイアフラワーブロック、逆さまパイプ、風 -- だが既存リストの途中に挿入 → SMB1との後方互換性なし
7. ピラニアプラントがワールド4以降常に赤、スプリングボードがワールド2/B/3/C/7で緑のみ

Super Mario All-Stars（SNES）

同じ6502ルーチンによる直接移植（SNESは互換モードでNESコードを実行）：

• ワープゾーン修正：Minus Worldなし（テキストの前に左のパイプに入ると正しいワールドに到着）
• フリーズ：ほとんどのグリッチレベルがクラッシュ（ID $6Aと9-1を除く）
• キャッスルオブジェクト追加：よりユニークに
• しかし：4-2 wrong warpはまだ機能する（パッチされていない！）

4-2 wrong warp：オブジェクト配置のバグ

4-2には2つのパイプトランジションオブジェクトがある：蔦（ワープゾーン）とパイプ（コインキャッシュルーム）。最初のトランジションオブジェクト（蔦のもの）は、蔦が画面に出現するはるか前に配置されている。2番目（パイプ）はレベル内で遅すぎる位置に配置されている。

; Timing des transitions dans 4-2 :
; Objet transition 1 (vigne → warp zone) : placé 3 écrans avant la vigne
; Objet transition 2 (tuyau → coin cash) : placé 1 écran après le tuyau
;
; Normalement le premier objet est désactivé avant que Mario
; n'atteigne le tuyau. Mais si Mario va vite (ou utilise
; le raccourci du bloc B+right), la transition de la vigne
; est toujours active quand il touche le tuyau !
; → Le jeu charge la warp zone au lieu du coin cash.
;
; Si l'objet avait été placé juste après la vigne mais avant
; le tuyau, le bug n'existerait pas.

ループレベル

ループ（8-4、7-4）はどう機能するか？ レベルにはハードコードされたスクリーン番号とY位置を持つチェックポイントがある：

; Checkpoint : {screen_number, vertical_position}
; Si Mario passe ce checkpoint à la bonne hauteur → niveau continue
; Sinon → warp back de 4 écrans (64 blocks)
;
; Pour faire une boucle infinie : vertical_position = $F0
; (en dessous du bas de l'écran) → impossible de valider.
;
; Les checkpoints sont simples (un seul flag) sauf pour world 7
; qui utilise des triplets (3 flags, il faut en échouer au moins 1)
;
; Le warp back est rude : offset de tile data réglé à une valeur
; hardcodée, offset de sprite data remis à 0. Les ennemis présents
; sont déchargés instantanément → les firebars disparaissent.

フォーマットを変え、コードは変えない

このアーキテクチャの最も興味深い教訓の1つは、SMB1の開発者が6502レンダリングコードに触れることなく、非常に表現力豊かなレベルシステムを構築したことだ。レベル間のすべてのバリエーションはデータ（ポインタ、オブジェクト、スプライト、フロアパターン）から来ており、コードではない。

256のグリッチワールドが存在するのは、ポインタテーブルが128エントリ × 4タイプに Sizedされており、ゲームが読み取る値を決してバリデーションしないからだ。ポインタがRAMに落ちると、ゲームはMarioのレジスタをタイルとして解釈する。ポインタがサウンドデータに落ちると、ゲームは音楽をレベルデザインとして再生する。そしてジャンプテーブルがオーバーフローすると、ゲームはクラッシュまで何でも実行する。

ここから学べること

1. タイル/スプライトの分離：2レイヤーの完全な独立、異なる保存順序がユニークなFrankensteinレベルを生む
2. RLE圧縮 + オブジェクトシステム：レベルはビットマップではなく配置されたオブジェクトのリスト、床にはフロアパターン
3. 3スロットキュー：ハードウェア（とレベルデザイン）の厳格な制限
4. バリデーションなし：ゲームはポインタとジャンプテーブルを信頼し、プレイ可能なグリッチまたはクラッシュを生む
5. 最大256バイト：6502のYレジスタの制限により、進みすぎるとデータが繰り返される
6. ワームスタート／コールドスタート：「続ける」システムがテニスカートリッジ交換 → Marioへの扉を開いた

最も美しいのは、これらすべてが40KBに収まる6502コードだ。抽象レイヤーなし、メモリアクセスバリデーションなし、例外ハンドラなし。ポインタが壊れていたら、ゲームはクラッシュする。そしてクラッシュは、グリッチワールドと呼ばれる。

覚えるべき3つのこと

1. グリッチワールドは場違いに落ちたポインタだ -- ゲームには128ID × 4エリアタイプがあるが、ユニークレベルは34のみ。ワールド番号が（テニスや壁抜けによって）破損すると、別のレベル用に設計されたポインタがロードされ、512の組み合わせが予測不可能な結果を生む。

2. Minus Worldはワープバグと破損の組み合わせだ -- 1-2の左パイプがテキスト表示前にアクティブ化されると、ワールド36（0x24）がロードされる。このワールドはLevel ID $01（2-2の水）を指し、flagpoleのないレベルだ。そしてワールド36にはパイプトランジションがないため、レベルは無限にループする。検証の欠如がこのアイコンを生んだ。

3. テニス → Mario、OoT → Paper Marioの15年前 -- NESのRAMはコンデンサとSMB1のワームスタート／コールドスタートシステムのおかげでカートリッジ交換を生き残る。テニスの歩数カウンター（歩く音を再生しながらRAMバイトをインクリメントする）がワールド番号のアドレスにちょうど落ちる。トップスコアの桁が0のまま、バイト$A5が無傷、ゲームがワームスタートを検出する必要がある -- テニスでしか機能しなかった完璧な偶発的な組み合わせだ。

Retro Game Mechanics Explainedの元動画はとんでもない労力の産物だ -- 6502の逆アセンブル、すべてのレベルの自動マップ、カートリッジ交換とワームスタートの説明。シリーズを見ていなかったら見ろ。短いし、毎分が密集している。

マップのソースコードはrgmechex.comで利用可能で、SMB1の完全な逆アセンブルは多数のリポジトリでオープンソースになっている。40年前、日本のプログラマーたちがユニットテストゼロ、バグトラッカーゼロの6502でこのレベルシステムを書き、今日でも彼らのコードを開くと新しいことを学べる。

소개

Super Mario Bros.는 40KB ROM로 이루어져 있습니다. 8개 월드, 32개 레벨, 적, 음악, 파워업이 모두 거기 들어 있습니다.

하지만 에뮬레이터를 열고 올바른 바이트를 조작하면 레벨 36-1을 로드할 수 있습니다. 또는 255-1도 가능합니다. 또는 모든 것이 Bowser 스프라이트와 아무 데도 연결되지 않는 파이프로 이루어진 월드에 착륙할 수도 있습니다.

이 글리치 월드들이 존재하는 이유는 간단합니다: SMB1의 레벨 저장 시스템은 8비트 최적화의 걸작이고, 게임이 읽으면 안 되는 곳에서 읽도록 강제하면 매혹적인 결과가 나옵니다.

Retro Game Mechanics Explained가 이 주제에 대해 4편의 영상을 만들었습니다 -- 가장 많이 팔린 그 시대의 게임의 6502 코드를 하나의 깊이 있는 탐험으로 정리하겠습니다.

웜 스타트: 왜 테니스의 RAM이 SMB1에서 살아남는가

레벨 저장에 대해 이야기하기 전에, SMB1이 어떻게 시작되는지 이해해야 합니다. NES 테니스 카트 스왑 글리치는 게임의 웜 스타트 / 콜드 스타트 감지 시스템에 전적으로 의존하기 때문입니다.

보존되는 41바이트

SMB1이 콜드 스타트 (처음 전원 켜기 또는 전원 껐다가 켜기)를 감지하면 RAM 전체를 지웁니다. 하지만 웜 스타트 (리셋 버튼, 전원 차단 없음)를 감지하면 41바이트 메모리 영역을 보존합니다:

; Les 41 bytes préservés en RAM lors d'un warm start
; Adresses $075F-$0787
;
; $075F : byte de démarrage (world - 1)    [1 byte]
; $0760 : flag de sélection de monde (B button) [1 byte]
; $0761-$0762 : inutilisé                    [2 bytes]
; $0763-$0768 : timer (6 digits, 3 affichés) [6 bytes]
; $0769-$076E : coins Luigi                   [6 bytes]
; $076F-$0774 : coins Mario                   [6 bytes]
; $0775-$077A : score Luigi                   [6 bytes]
; $077B-$0780 : score Mario                   [6 bytes]
; $0781-$0786 : top score (6 digits, 1 caché) [6 bytes]
; $0787 : le byte magique $A5                 [1 byte]

이 41바이트는 하나의 기능을 위해 사용됩니다: 플레이어가 게임 오버 후 같은 월드에서 계속할 수 있게 하는 것. 6-3에서 죽으면 게임은 월드 6을 시작 바이트에 기록하고, 타이틀 화면에서 A + Start를 누르면 6-1에서 다시 시작합니다.

웜 스타트의 이중 검증

SMB1이 부팅할 때 하나의 기준만 확인하는 것이 아니라 두 가지를 확인합니다:

CheckWarmStart:
  ; 1. Vérifier le byte magique $A5 à $0787
  lda $0787
  cmp #$A5
  bne ColdStart        ; pas $A5 → cold start

  ; 2. Vérifier les 6 digits du top score ($0781-$0786)
  ;    Chaque digit doit être entre 0 et 9
  ldx #0
CheckLoop:
  lda $0781,x
  cmp #$0A
  bcs ColdStart        ; digit >= 10 → cold start
  inx
  cpx #6
  bne CheckLoop

  ; Si les deux conditions passent → warm start
  ; La RAM n'est pas effacée, le monde de départ est préservé
  jmp WarmStartBoot

왜 이중 검증일까요? 바이트 $A5가 우연히 존재할 수 있기 때문입니다 (다른 게임이 이 값을 남기거나, RAM 칩의 기본 유휴 상태). 탑 스코어의 자릿수가 유효한지 (0-9) 확인함으로써 데이터가 일관된다는 것을 보장합니다.

왜 테니스가 유일하게 작동하는 게임인가

처음으로 SMB1을 삽입하면 (콜드 스타트), 게임은:

1. RAM 전체를 지움 → 탑 스코어 = 0, 월드 바이트 = 0
2. $0787에 $A5를 기록

그런 다음 콘솔을 끄지 않고 테니스로 전환합니다. 테니스:

• 시작 시 RAM을 정리하지 않음 (NES 게임 중 거의 그렇게 하지 않음)
• 탑 스코어 바이트에 기록하지 않음 → 0으로 유지 (유효)
• 바이트 $A5를 건드리지 않음 → 유지됨
• $075F 주소를 사용하여 플레이어의 발걸음 카운터

; Le footstep increment dans Tennis :
; À chaque pas du joueur sur le court, Tennis incrémente le byte à $075F.
; Ce même byte est utilisé par SMB1 comme "world number - 1".
;
; 0 pas  → world 0 → SMB1 = world 1
; 1-7 pas → world 1-7 → worlds normaux
; 8+ pas → world 8+ → glitch worlds !
;
; Le compteur ne s'incrémente que quand la musique s'arrête
; (les footstep sounds ne jouent pas pendant la musique).

SMB1을 다시 넣으면:

1. 바이트 $A5가 아직 거기 있음 (테니스가 건드리지 않았음)
2. 탑 스코어 자릿수가 여전히 0 (유효)
3. 월드 바이트가 이제 8+ (테니스 발걸음으로 증가)
4. SMB1이 웜 스타트를 감지 → 손상된 월드 바이트를 보존
5. A + Start 유지 → world 9-1, world A-1, world 36-1 등

왜 테니스 전에 마리오를 부팅해야 하는가

미묘한 점이 있습니다: SMB1을 먼저 부팅한 다음, 테니스, 그리고 다시 SMB1을 부팅해야 합니다. 테니스부터 시작하면 바이트 $A5가 기록되지 않습니다 (테니스는 $A5를 기록하지 않으므로), 그래서 웜 스타트 감지가 실패하고 RAM이 지워집니다.

SMB1이 40KB에 레벨을 저장하는 방법

Nintendo R&D4는 겉보기에 단순한 문제를 해결해야 했습니다: 타일로 수평 스크롤하는 레벨을 표현하고, 적과 아이템을 포함하며, 모든 것을 초 Restricted ROM 예산 안에 넣기.

해결책은 완전히 독립된 두 개의 데이터 레이어로 분리하는 것입니다:

타일 레이아웃 (레벨 맵)

각 레벨은 ROM에서 압축된 타일 구조를 가리키는 포인터로 정의됩니다. 압축은 원시적이지만 영리합니다: "컨트롤" 바이트 뒤에 1-3바이트의 데이터.

타일 포맷은 런 (RLE 유사) 시스템을 사용합니다:

; Format tile SMB1 (simplifié)
; Chaque "commande" est un byte contrôle :
;
; $00-$7F : pose une tile, avance d'1 colonne
; $80-$BF : pose une tile répétée N fois (N = byte - $80 + 1)
; $C0-$FF : commande spéciale (fin de ligne, saut, changement de palette)

Exemple : pour dessiner 3 briques consécutives :
  $82 $01    ; répète la tile $01 (brick) 3 fois

각 레벨은 16열 × 13행의 타일 (13×16 = 208개 보이는 타일)을 포함합니다. 하지만 압축된 포맷은 훨씬 적은 공간으로 줄일 수 있습니다 -- 예를 들어, 하늘과 빈 열은 거의 공간을 차지하지 않습니다.

6502의 렌더링 루프:

; Décompression tile - loop principale
; Entrée : pointeur tile_data en $XX
; Sortie : tilemap niveau dans la RAM PPU

DecompressTile:
  lda (tile_ptr),y      ; lire byte contrôle
  iny
  cmp #$80
  bcc SingleTile        ; $00-$7F : tile unique
  cmp #$C0
  bcc RunLength         ; $80-$BF : run-length
  jmp SpecialCommand    ; $C0-$FF : commande spéciale

SingleTile:
  sta PPU_DATA          ; écrire la tile directement
  jmp Next

RunLength:
  sec
  sbc #$7E              ; N = control - $7E
  tax
  lda (tile_ptr),y      ; lire la tile à répéter
  iny
: sta PPU_DATA
  dex
  bne :-
  jmp Next

스프라이트 레이아웃 (적과 오브젝트)

별도로, 적과 오브젝트 (블록 ?, 파이프, goomba, koopa)는 완전히 별도의 구조에 저장됩니다. 각 스폰은 2바이트로 정의됩니다:

; Format sprite SMB1
; Byte 0 : position X (en colonnes)
; Byte 1 : type de sprite + bits de page Y
; Y est dérivé de l'index dans la séquence

Une séquence de sprites :
  $01 $4B    ; goomba à la colonne 1
  $09 $4B    ; goomba à la colonne 9
  $10 $61    ; bloc ? à la colonne 16 (contient pièce)
  $15 $54    ; koopa verte à la colonne 21
  $FF        ; fin de séquence

각 레벨은 최대 5개의 서로 다른 스프라이트 페이지를 참조할 수 있습니다 (즉, 16열짜리 5개 "스크린"). 하지만 실제로 대부분의 레벨은 2-3개만 사용합니다.

포인터 테이블

설계의 천재성은 포인터 테이블에 있습니다. 각 레벨은 쌍으로 된 ROM 주소로 저장됩니다:

// Structure interne (simplifiée) du World Map
struct LevelPointer {
    uint16_t tile_ptr;   // Adresse ROM des données tiles
    uint16_t sprite_ptr; // Adresse ROM des données sprites
};

// 4 tables séparées, une par AreaType :
// 0 = Water, 1 = Overworld, 2 = Underground, 3 = Castle
LevelPointer level_table[4][128];

테이블당 128개 항목. 4가지 영역 타입. 512가지 가능한 조합이 있지만 공식 게임에서는 일부만 사용됩니다. 나머지는 초기화되지 않은 RAM이거나 포인터로 해석되는 데이터입니다.

게임이 레벨을 로드할 때 다음과 같이 작동합니다:

; Chargement d'un niveau
; A = AreaType (0-3), X = LevelID (0-127)

LoadLevel:
  sta AREA_TYPE
  asl                  ; *2 pour offset dans table 16-bit
  tax
  lda LevelTable_TilePtr, x
  sta TILE_PTR
  lda LevelTable_TilePtr+1, x
  sta TILE_PTR+1       ; pointeur vers les tiles
  lda LevelTable_SpritePtr, x
  sta SPRITE_PTR
  lda LevelTable_SpritePtr+1, x
  sta SPRITE_PTR+1     ; pointeur vers les sprites
  jsr DecompressTiles

검증 없음. 포인터가 유효한지 확인 없음. 게임은 테이블에서 주소를 읽고 해당 주소의 내용을 압축 해제합니다, 끝.

34개 고유 레벨과 7비트 ID 시스템

SMB1에는 32개 레벨이 아니라 34개 고유 레벨이 있습니다. 많은 레벨은 "하드 모드" 플래그로 표시된 중복입니다 (5-3 = 1-3이지만 Bullet Bill 포함). 진짜 고유 레벨:

• 물 (타입 0): 3개 레벨 (2-2, 7-2, 보너스 영역 5-2/6-2)
• 오버월드 (타입 1): 22개 레벨 (구름 보너스 2개 방 포함)
• 지하 (타입 2): 3개 레벨 (지하 보너스 방 포함)
• 성 (타입 3): 6개 레벨
• + 1개 컷씬 방 (지하/수중 레벨 앞)
• + 4-2의 워프 존

각 레벨은 7비트 ID를 가지고 있습니다. 하위 5비트 = 서브그룹 내 번호, 상위 2비트 = 영역 타입:

; Encodage 7-bit du Level ID
; Bits 6-5 : Type (00=Water, 01=Overworld, 10=Underground, 11=Castle)
; Bits 4-0 : Numéro dans le sous-groupe
;
; Water IDs      : $00-$02  (types 00, numéros 0-2)
; Overworld IDs  : $20-$35  (types 01, numéros 0-21)
; Underground IDs: $40-$42  (types 10, numéros 0-2)
; Castle IDs     : $60-$65  (types 11, numéros 0-5)
;
; ID $25 = %0100101 → type 01 (Overworld), numéro 5 → 1-1
; ID $23 = %0100011 → type 01 (Overworld), numéro 3 → 6-2

128개 가능한 ID ($00-$7F), 실제 레벨에 할당된 것은 34개만. 사용되지 않은 ID는 아무 데나 가리킵니다.

포인터 테이블: 두 개의 목록, 두 개의 순서

타일 포인터와 스프라이트 포인터는 같은 순서로 저장되지 않습니다. 코드는 두 개의 별도 16비트 목록을 사용합니다 (하이 바이트 / 로우 바이트가 두 개의 별도 테이블에):

Ordre des pointeurs sprites :
  Index 0-5   : Castle (6 niveaux)
  Index 6-27  : Overworld (22 niveaux)
  Index 28-30 : Underground (3 niveaux)
  Index 31-33 : Water (3 niveaux)

Ordre des pointeurs tiles :
  Index 0-2   : Water (3 niveaux)
  Index 3-24  : Overworld (22 niveaux)
  Index 25-27 : Underground (3 niveaux)
  Index 28-33 : Castle (6 niveaux)

왜 서로 다른 순서일까요? 기술적 이유는 없습니다 -- 아마 개발 중에 데이터가 그렇게 정리되었을 것입니다. 하지만 이는 매혹적인 결과를 만듭니다: 레벨 ID가 유효하지 않으면 타일 포인터와 스프라이트 포인터가 서로 다른 레벨을 로드하여 프랑켄슈타인 레벨을 만듭니다.

이 두 목록 사이를 탐색하기 위해, 게임은 작은 오프셋 테이블 (목차와 같은)을 사용합니다:

; Tables d'offset par type (Water, Overworld, Underground, Castle)
; Chaque entrée = index de début dans la liste correspondante

SpriteOffsetTable:
  .byte $1F, $06, $1C, $00    ; Water=31, Overworld=6, Underground=28, Castle=0

TileOffsetTable:
  .byte $00, $03, $19, $1C    ; Water=0, Overworld=3, Underground=25, Castle=28

6-2 레벨 (ID $23, 오버월드 번호 3)을 로드하려면:

; 1. Type = 01 (Overworld) → index dans table d'offset = 1
; 2. Sprite offset = SpriteOffsetTable[1] = 6
;    Index final = 6 + 3 (numéro de niveau) = 9 → 10ème pointeur sprites
; 3. Tile offset = TileOffsetTable[1] = 3
;    Index final = 3 + 3 = 6 → 7ème pointeur tiles
; 4. Résultat : pointeur tiles $A619 + pointeur sprites $9ED0 = 6-2 ✓

이제, $43 (지하 번호 3, 존재하지 않음) 같은 유효하지 않은 ID로는 어떻게 될까요?

; ID $43, Type = 10 (Underground), numéro = 3
; Sprite offset = SpriteOffsetTable[2] = $1C = 28
;   Index = 28 + 3 = 31 → 32ème pointeur sprites = eau bonus 5-2 !
; Tile offset = TileOffsetTable[2] = $19 = 25
;   Index = 25 + 3 = 28 → 29ème pointeur tiles = 1-4 (Castle) !
;
; Résultat : un niveau souterrain avec les tiles de 1-4
; et les Bloopers de la zone eau de 5-2. Un vrai Frankenstein.

월드 인덱스 테이블: 왜 world 9가 오버플로우되는가

각 월드의 첫 번째 레벨 인덱스를 제공하는 8바이트 ROM 테이블이 있습니다. 그리고 바로 뒤에, 게임 순서대로 모든 36개 레벨의 Level ID 테이블이 있습니다.

; WorldIndexTable (8 bytes)
  .byte 0, 5, 10, 15, 20, 25, 28, 33
;   -> Monde 1 commence au niveau 0
;   -> Monde 2 commence au niveau 5
;   -> Monde 8 commence au niveau 33

; LevelIDTable (36 bytes)
  .byte $25, $28, $29, $26, $24, ... ; les 36 Level IDs

world 9를 로드하려고 하면, 게임은 WorldIndexTable의 9번째 바이트를 읽습니다... 하지만 존재하지 않습니다. 1바이트가 LevelIDTable로 오버플로우하여 $25 값을 읽고, $25를 LevelIDTable의 인덱스로 사용합니다 (37번째 항목) -- 이는 SpriteOffsetTable로 다시 2바이트 오버플로우하여 값 6을 읽습니다.

; World 9 :
;   1. WorldIndexTable[8] (overflow) → lit $25 dans LevelIDTable
;   2. LevelIDTable[37] (overflow) → lit le 2ème byte de SpriteOffsetTable = 6
;   3. ID = 6 → Water level number 6 (qui n'existe pas)
;   4. Tile pointer = pointeur water numéro 6 = tiles de 6-2
;   5. Sprite pointer = index 31+6 = 37 > 33 → pointeur invalide
;   6. Résultat : 6-2 sous l'eau avec des sprites glitchés
;      → world 9-1 !

world G (16)의 경우, 오버플로우가 더 멀어져 Level ID $01에 떨어지는데, 이것이 1-2 앞의 컷씬 레벨입니다:

; World G (16) :
;   WorldIndexTable[15] → lit $01 dans LevelIDTable
;   LevelIDTable[1] = $29 (cutscene 1-2)
;   → world G-1 = la cutscene d'entrée de 1-2

왜 글리치 월드가 존재하는가

게임에는 32개의 "합법적인" 레벨 (8월드 × 4레벨)이 있습니다. 하지만 포인터 테이블은 영역 타입당 128개 항목을 가지고 있습니다. 32번째 레벨 이후의 항목에는 해당 주소의 ROM 내용이 들어 있습니다 -- 때로는 다른 레벨, 때로는 사운드 데이터, 때로는 RAM, 때로는 아무거나.

Level ID $01 + AreaType 0 = Minus World

가장 유명한 글리치 월드. Level ID $01은 AreaType 0 (물)에서 다음을 가리킵니다:

• 타일 포인터: $AE45 → 2-2/7-2의 수중 영역
• 스프라이트 포인터: $A171 → 2-2/7-2의 스프라이트

결과: 2-2와 비슷한 수중 레벨이지만 깃발 기둥이 존재하지 않아 무한히 반복됩니다. 레벨 끝 없음, 출구 없음.

이것이 레벨 36-1 (또는 월드 $-1의 36-1)입니다.

; Pourquoi le flagpole manque dans le Minus World :
; Les sprites de 2-2/7-2 ($A171) n'ont pas de flagpole
; dans leur séquence. Le jeu cherche le sprite $FD (flagpole)
; mais ne le trouve jamais → boucle infinie
;
; Le jeu continue de générer le niveau à l'infini
; jusqu'à ce que le timer atteigne zéro.

RAM을 가리키는 포인터

타일 포인터나 스프라이트 포인터가 ROM이 아닌 RAM 주소 ($00-$7F)를 가리킬 때, 게임은 RAM의 지속적인 변화를 타일로 해석하려 합니다:

; Exemple : Level ID $03 en Water
; Tile Pointer : $A46B (3-3 - valide)
; Sprite Pointer : $009D (pointe vers la RAM page zéro !)
;
; La RAM page zéro contient les registres du jeu,
; la position de Mario, l'état des compteurs...
; Le jeu décompresse ça comme une séquence de sprites,
; et le résultat c'est un niveau avec des ennemis
; qui sont en fait des valeurs de registres.

제로 페이지가 변경되면 (마리오가 움직이거나 타이머가 돌아가는 등), 레벨의 "스프라이트"도 바뀝니다. 이것이 일부 글리치 월드에서 적이 깜빡이고 지속적으로 변하는 이유입니다.

Level ID $36: 빈 레벨 (Overworld)

Level ID $36은 Overworld:

• 타일 포인터: $AC35 (1-2)
• 스프라이트 포인터: $A0D8 (1-2)

결과: 없음. 게임은 레벨을 로드하지만 RGMechEx 카탈로그에서 "레벨 없음"으로 표시됩니다. 타일은 유효할 수 있지만 스프라이트가 빈 레벨이나 작동하지 않는 레벨을 만드는 곳을 가리킵니다.

Level ID $1D (성): 크래시 챔피언

Level ID $1D은 성:

• 타일 포인터: $A210 (4-4)
• 스프라이트 포인터: $7EA0 (RAM!)

스프라이트 포인터가 RAM에 있으면 미정의 스프라이트가 됩니다. 게임은 첫 번째 타일 행에 Spiny ball이나 Bullet Bill 발사기를 표시하려 합니다. 즉시 크래시됩니다.

; Quand le sprite pointer pointe vers la RAM,
; le jeu décompresse des bytes qui changent tout le temps
; comme des instructions "spawn". Le résultat :
; - Apparition d'objets inexistants (valeur undefined)
; - Crash PPU quand le sprite NES essaie d'afficher un tile invalide
; - Freeze complet de la console

256개 글리치 월드 카탈로그

RGMechEx는 4가지 영역 타입과 각각의 128개 ID에 대해 모든 레벨의 맵을 생성하는 스크립트를 작성했습니다.

월드 카운터는 8비트 (0-255)입니다. 월드 1-8은 합법적입니다. 잠재적으로 248개 글리치 월드가 남습니다. 각 글리치 월드는 해당 월드의 첫 번째 레벨에 해당하며, Level ID는 WorldIndexTable의 오버플로우 메커니즘으로 계산됩니다.

128개 가능한 ID 중 68개만이 월드의 "첫 번째 레벨" (글리치 월드 번호를 통해 접근 가능). 나머지 60개는 2+ 레벨이거나 접근 불가능합니다.

타입	유효한 고유 ID	크래시되는 ID	빈 ID
Water (0)	~20	~60	~48
Overworld (1)	~30	~55	~43
Underground (2)	~15	~65	~48
Castle (3)	~25	~58	~45

많은 ID가 같은 주소에 떨어지는 포인터 때문에 같은 레벨로 이어집니다. 예를 들어 Level ID $28 (Overworld) -- 타일 포인터 $A7CD (2-1) -- 은 38개 서로 다른 글리치 월드에 나타납니다. 스프라이트 포인터 $9F51이 많은 ID에 의해 재사용되는 패딩/사운드 데이터 영역의 ROM을 가리키기 때문입니다.

정말 고유한 6개 글리치 레벨

19개 접근 가능한 글리치 레벨 ID 중 6개만이 로드 시 즉시 크래시되지 않습니다:

월드	Level ID	설명
E-1 (224)	$50	절벽 위에 ? 블록 하나. 마리오가 즉시 죽음.
W	$57	마리오가 스폰되어 막힘, 움직일 수 없음.
42 (133)	$50	구름 터널. 충분히 멀리 가면 마리오를 가둠.
62 (131, 240)	$4D	얼어붙은 성: 마리오가 위에서 스폰되며 떨어질 수 없음 → 막힘.
127	$4B	지하 터널. 너무 멀리 가면 크래시됨.
137	$4B	컷씬의 자동 스크롤을 활성화. 마리오가 영원히 막는 단일 벽돌 블록을 만남.

248개 중 6개 글리치 월드만 정말 새로운 것을 만듭니다. 나머지는 잘못된 영역 타입을 가진 일반 레벨이거나 검은 화면입니다.

레벨 포맷 상세 분석

글리치 레벨이 왜 성립하는지 (또는 그렇지 않은지) 이해하기 위해 정확한 레벨 데이터 포맷으로 넘어가겠습니다.

레벨 헤더: 2바이트, 6가지 속성

각 레벨은 6가지 속성을 제어하는 2바이트 헤더로 시작합니다:

; Byte 0 : timer + Y start + modifier
;   Bits 7-6 : timer (00=inchangé, 01=200, 10=300, 11=400)
;   Bits 5-3 : Y start Mario (111/110 = autowalk)
;   Bits 2-0 : level type modifier
;              000=default, 001=waves, 010=brick wall,
;              011=water bottom, 100=night, 101=snow,
;              110=snow night, 111=gray night

; Byte 1 : platform + background + floor pattern
;   Bits 7-6 : special platform (00=tree, 01=mushroom,
;                                 10=Bullet Bill, 11=cloud)
;   Bits 5-4 : background (00=none, 01=clouds,
;                           10=montains, 11=fences)
;   Bits 3-0 : floor pattern initial (0-15)

타입 수정자는 시각적 변형을 제어합니다: 수중 레벨 상단의 파도, 8-3의 벽돌 배경, 4-3의 야간 팔레트, 6-2의 눈 등.

타일 오브젝트: 2바이트, Next Screen Flag, 3슬롯 큐

헤더 뒤에 타일 오브젝트 목록이 오며, 각 오브젝트는 2바이트입니다. 바이트 $FD는 목록의 끝을 표시합니다.

; Format objet tile (16 bits) :
; Byte 0 :
;   Bits 7-4 : X position (colonne 0-15)
;   Bits 3-0 : Y position
;     Y=0-11  : position Y normale
;     Y=12    : objets spéciaux (trous, ponts, rope, ? blocks)
;     Y=13    : screen skip / objets spéciaux 2
;     Y=14    : changement de modifier/scenery/floor
;     Y=15    : objets spéciaux 3 (château, escaliers, gros tuyau)

; Byte 1 :
;   Bit  7   : NEXT SCREEN FLAG
;   Bits 6-4 : type d'objet (0-7)
;   Bits 3-0 : largeur/hauteur / sous-type

"next screen" 비트가 설정되면 현재 작업 열이 1만큼 증가합니다. 이를 통해 처음 16열 너머에 오브젝트를 배치할 수 있습니다. 게임이 순차적으로 로드하기 때문에 오브젝트는 순서대로 (왼쪽에서 오른쪽) 나열해야 합니다:

; La routine de chargement a DEUX phases par colonne :
; Phase 1 : chercher les nouveaux objets qui commencent sur cette colonne
;            et les ajouter à la file d'attente (queue)
; Phase 2 : traiter chaque objet dans la queue en dessinant les tiles,
;            et retirer ceux qui finissent sur cette colonne

큐는 정확히 3슬롯입니다. 직접적인 결과: 같은 열에서 시작하는 오브젝트가 3개를 초과할 수 없습니다. 큐가 가득 차면 네 번째 오브젝트는 무시되고 로드되지 않습니다.

이것이 잘 설계된 레벨이 너무 많은 오브젝트를 쌓지 않는 이유입니다. 1-2의 예: 천장의 1up 블록이 있는 열과 옆의 벽돌은 3개 제한을 준수하기 위해 두 개의 별도 오브젝트로 분할됩니다.

특수 Y 위치: 12, 13, 14, 15

Y=12일 때, 오브젝트는 Y 위치가 없습니다 (타입별로 하드코딩됨):

; Y=12 : objets sans Y position
;   Type 0 : trou (supprime le sol)
;   Type 1 : rope de plateforme mobile
;   Types 2-4 : ponts à Y fixe
;   Type 5 : trou avec eau/lave
;   Types 6-7 : rangées de ? blocks

Y=13일 때, 두 개의 서브그룹. 바이트 1의 비트 6이 1이면:

; Y=13, bit6=1 : objets spéciaux
;   0 = L-pipe (cutscene), 1 = flagpole, 2-3 = pont/axe/hamer (fin château)
;   4 = stop screen, 5 = random enemies, 6 = loop level, 7+ = crash possible

비트6=0이면, 하위 5비트가 스크린 스킵 (하나씩 next screen flag를 거치지 않고 N 스크린으로 직접 건너뛰기)를 인코딩합니다.

Y=14일 때: 비트6=1이면 타입 수정자를 변경하고, 비트6=0이면 배경 + 바닥 패턴을 변경하는 같은 원리입니다.

바닥 패턴: 16개 바닥 모양

레벨의 바닥은 개별 오브젝트로 만들어지지 않습니다. SMB1은 바닥 패턴을 사용하며, 다음 변경까지 모든 열에 적용되는 배경 모양입니다:

; Floor patterns (4 bits = 16 possibilités)
;   0 = vide total
;   1 = sol 2 tiles haut
;   2 = sol 1 tile haut
;   3 = sol + bottom
;   4 = sol + bottom 2
;   5 = sol 1/2 tile
;   6 = 3/4 sol
;   ... jusqu'à 15 = rempli total (sol + plafond)

구멍이 오브젝트인 이유: 특정 열에서 바닥 패턴을 오버라이드하여 나머지 패턴을 변경하지 않고도 구멍을 만들 수 있기 때문입니다.

256바이트 제한과 반복

각 레벨의 모든 타일 데이터는 최대 256바이트에 들어갑니다. 6502의 Y 레지스터는 인덱스로 사용되며 8비트입니다. 게임이 $FD 바이트를 찾지 못한 채 데이터 끝에 도달하면 처음으로 돌아가 256바이트를 무한히 반복합니다:

; Index Y = 8 bits → max 256 bytes de données tiles
; Si Y overflow (255 → 0) sans rencontrer $FD → repeat
; Même chose pour les sprites, mais les objets pipe (3 bytes)
; décalent la parité de l'index à chaque chargement.

일부 글리치 레벨은 이 반복을 활용하여 "무한히" 지속되는 레벨을 생성합니다.

스프라이트 시스템: 2바이트 + 파이프 전환

스프라이트는 유사한 포맷을 따르지만 헤더가 없고 몇 가지 핵심 차이가 있습니다. 바이트 $FF는 목록의 끝을 표시합니다.

; Format sprite (2 bytes) :
; Byte 0 : position X (colonne)
; Byte 1 :
;   Bit 7 : NEXT SCREEN FLAG
;   Bits 6-0 : type de sprite
;       Certains types incluent : goomba, koopa, Blooper,
;       Bullet Bill, Lakitu, Spiny, plateformes,
;       commande warp zone, toad/princesse,
;       commandes de spawn de groupes d'ennemis

바이트 1의 최하위 비트는 하드 레벨 플래그입니다: 1로 설정하면 해당 스프라이트는 5-3 이상의 레벨에만 나타납니다. 이것이 "하드 모드" 레벨이 만들어지는 방식입니다.

Y 위치 15 = 스크린 스킵 (타일과 동일). Y 위치 14 = 파이프 전환 (3바이트):

; Sprite Y=14 : pipe/vine transition (3 bytes !)
;   Byte 0 : position X
;   Byte 1 : bits 6-0 = Level ID 7-bit (destination)
;   Byte 2 : bits 4-0 = screen de destination
;            bits 7-5 = world où cette transition est valide
;
; Pourquoi un world ? Les bonus rooms sont réutilisées entre mondes.
; Exemple : la salle bonus de 1-1 est aussi utilisée par 2-1 et 7-1.
; Cette salle a 3 transitions, une par monde, pour que Mario
; réapparaisse au bon endroit.

스프라이트에는 큐 시스템이 없습니다. 유일한 제한은 스폰 영역 (오른쪽 화면 밖)에서 동시에 로드된 스프라이트가 4개를 초과할 수 없다는 것입니다. 그 이상은 스프라이트가 무시됩니다.

글리치 월드에 접근하는 방법

두 가지 주요 방법이 있습니다.

클래식 방법: 월 클립

월 클립 (벽 통과)은 일반 레벨 밖으로 나와 숨겨진 워프 존까지 걸어갈 수 있게 합니다. RAM을 통해 월드 카운터를 조작하면 어떤 Level ID든 로드할 수 있습니다.

기술:

1. World 1-2: 숨겨진 끝 파이프로 이동
2. 오른쪽 벽에서 월 클립 수행
3. 빈 공간을 걸어 워프 영역까지 이동
4. 게임이 값을 월드로 해석

하지만 이 방법은 글리치 월드의 일부에만 접근할 수 있습니다.

극단적 방법: NES 테니스 카트 스왑

전체 세부 사항은 위의 "웜 스타트" 섹션을 참조하세요. 요약: 테니스의 발걸음 카운터가 SMB1의 시작 월드와 같은 RAM 바이트에 기록하고, 웜 스타트 감지가 이 값을 보존합니다.

해커들을 위한 코너: 모두 탐험하기 위한 코드

에뮬레이터에서 모든 글리치를 직접 탐험하고 싶다면, Level ID를 직접 패치할 수 있습니다:

; Patch pour FCEUX / Mesen :
; Adresse RAM $075F = Level ID actuel
; Adresse RAM $0760 = Area Type (0=Water, 1=Overworld, 2=Underground, 3=Castle)

; Exemple : charger le Level 57 (0x39) en Overworld
; Dans l'émulateur, ouvrir le traceur mémoire et écrire :
; $075F = 0x39
; $0760 = 0x01
; Puis entrer dans un tuyau de warp ou mourir et recommencer
; → Le jeu charge le niveau ID $39 en Overworld

RGMechEx는 자동 생성된 맵과 함께 128개 레벨 × 4가지 타입의 전체 목록을 rgmechex.com에 게시했습니다. 각 항목은 타일 포인터, 스프라이트 포인터, 레벨의 시각적 맵을 보여줍니다.

가장 황당한 레벨들

Level ID $1F (Water): 15개 글리치 월드가 하나에

타일 포인터 $A302 (3-4)와 스프라이트 포인터 $02A0의 조합으로 15개 서로 다른 글리치 월드 (D-1, J-1, Y-1, Z-1, 55-1, 73-1...)가 나옵니다. 설명: 스프라이트 포인터가 유효한 스프라이트에 충분히 가까운 데이터가 포함된 ROM 영역을 가리켜 플레이 가능한 결과를 만들지만, 3-4의 성 타일과 오버월드 스프라이트의 조합이 엉뚱한 렌더링을 만듭니다.

Level ID $28 (Overworld): 38개 글리치 월드 = 기록

절대 기록. 38개 글리치 월드 항목이 같은 레벨 (2-1 타일 + $9F51 스프라이트)을 가리킵니다. 왜? 스프라이트 포인터 $9F51이 많은 ID에 의해 재사용되는 패딩/사운드 데이터 영역의 ROM에 떨어지기 때문입니다.

Level ID $49 (Underground): FDS 레벨

타일 포인터 $76AE + 스프라이트 포인터 $1C9D. 타일 포인터가 패미컴 디스크 시스템 버전에 예약된 ROM 영역을 가리킵니다. 결과: 표준 카트리지에 존재하지 않는 타일을 가진 레벨. 이것이 레벨 52-1과 196-1을 만드는 레벨입니다.

Level ID $00-$02: 진짜 보너스 레벨

이 ID들은 게임의 합법적인 서브레벨에 사용됩니다:

• $00: 5-2/6-2의 수중 영역 (H-1, 39-1에서 사용)
• $01: 2-2/7-2의 수중 (Minus World, 36-1)
• $02: 8-4의 서브레벨 (136-1, 151-1, 215-1)

일반적으로 접근 가능한 "보너스" 레벨과 글리치 월드의 차이점은 워프 존이 현재 월드를 확인한다는 것입니다:

; Vérification warp zone (simplifié)
; Le jeu vérifie que le monde cible est entre 1 et 8
CheckWarp:
  lda TARGET_WORLD
  cmp #1
  bcc InvalidWarp       ; < 1 → refusé
  cmp #9
  bcs InvalidWarp       ; > 8 → refusé
  ; world valide entre 1 et 8 uniquement
  jmp DoWarp

번호가 8 초과 또는 0인 글리치 월드는 일반 파이프로 도달할 수 없습니다. 월 클립이나 카트 스왑이 필요합니다.

왜 일부 레벨이 크래시되는가: 점프 테이블

게임이 타일 오브젝트를 로드할 때, 타입을 점프 테이블의 인덱스로 사용합니다:

; Jump table des objets tiles standards (types 0-11)
JumpTable_TileObjects:
  .word Obj_Special       ; type 0 : bloc ?, hidden, flagpole...
  .word Obj_Platform      ; type 1 : plateforme spéciale
  .word Obj_BrickRow      ; type 2 : rangée de briques
  .word Obj_BlockRow      ; type 3 : rangée de blocks
  .word Obj_CoinRow       ; type 4 : rangée de pièces
  .word Obj_BrickCol      ; type 5 : colonne de briques
  .word Obj_BlockCol      ; type 6 : colonne de blocks
  .word Obj_Pipe          ; type 7 : tuyau
  .word Obj_8             ; type 8
  .word Obj_9             ; type 9
  .word Obj_10            ; type 10
  .word Obj_11            ; type 11

오브젝트가 유효하지 않은 타입 (≥12)을 가지면, 게임은 이 테이블에 존재하지 않는 포인터로 점프합니다. 4가지 가능한 결과:

1. 유효한 포인터 → 오브젝트가 일반적으로 로드됨
2. 다른 점프 테이블로의 포인터 (겹침) → 다른 오브젝트가 나타남. 예: 타입 12가 Y=13 테이블을 가리켜 L-pipe가 됨
3. 실행 가능한 코드로의 포인터 → 무작위 코드 실행 (크래시 가능성 높음)
4. 명시적 NOP → 오브젝트가 아무것도 하지 않음 (일부 스프라이트가 이렇게 하여 적이 제자리에서 날아다니지만 움직이지 않음)

글리치 레벨 ID $58 (크래시되는 터널): 스프라이트 포인터가 ROM 매핑 NES에 존재하지 않는 메모리 영역을 가리킵니다. 게임은 (0,0) 위치에 같은 Koopa를 프레임당 5번 로드하려 하여 PPU를 포화시키고 프리즈를 일으킵니다.

; Pourquoi ID $58 crashe :
; Sprite pointer → adresse invalide (hors espace NES standard)
; → Le jeu lit des bytes indéterminés comme des types de sprite
; → Le Koopa $00 (type invalide sans handler) boucle en appel récursif
; → Stack overflow 6502 → freeze

파이프 워프의 역설

target_world BETWEEN 1 AND 8 체크를 기억하세요. 글리치 월드에서 파이프를 찾아도 게임은 대상 월드가 1과 8 사이인지 확인합니다. 글리치 월드는 번호가 8 초과 (36-1, 255-1...)이므로 워프가 실패합니다.

Minus World에 끝이 없는 이유도 같습니다: 깃발 기둥이 스프라이트에 없고, 파이프가 아무 데도 연결되지 않습니다.

한 열에 5개 오브젝트 트릭

한 열에 3개 오브젝트 제한을 우회할 수 있는 엣지 케이스가 있습니다. 큐가 막히면 (슬롯 가득 + 다음 next screen flag 없는 오브젝트), 게임은 next screen flag가 있는 오브젝트를 찾을 때까지 현재 열을 "사전 처리"로 반복합니다. 각 사전 처리에서:

; Pendant le prétraitement de colonne :
; 1. Les objets dans la queue voient leur largeur restante
;    décrémentée à chaque "fausse avancée" de colonne
; 2. Si un objet atteint largeur=0, il quitte la queue
; 3. Un slot libéré peut être rempli par un nouvel objet
;    ajouté dans la même colonne

; Résultat : jusqu'à 5 objets peuvent être traités sur la même colonne.
; Technique : placer 2 objets qui traversent la screen boundary
; (slots 1 et 2), 1 objet dummy en X < précédent (bloque la queue),
; puis 3 objets à X=0 de l'écran suivant (dont un avec next screen flag).

이것이 "큐 스킵"이라고 불리며 일부 롬해커가 포맷이 허용하는 것보다 더 조밀한 레벨을 만드는 데 사용됩니다.

버전 간 차이점

패미컴 디스크 시스템

SMB1의 FDS 버전은 메모리 맵이 다릅니다. 모든 레벨 포인터가 이동되지만 데이터는 동일합니다. 달라지는 점: 글리치 월드의 인덱스가 완전히 다릅니다:

FDS World 36 → Level ID $09 (eau version de 5-3)
  → Le flagpole est présent ! On peut finir le niveau.
  → Ensuite : $27 (7-3 normal) → $44 (4-4 underground)
  → $44 est finissable → la hache fonctionne → fin du jeu !
  
Le Minus World FDS est donc un "bonus world" qui peut mener
à la complétion du jeu, contrairement à la version NES.

가장 좋아하는 FDS 레벨: ID $5F, 낮은 터널의 3-3 두 번째 절반의 지하 버전 (자동 스크롤러인 것이 안타까움).

The Lost Levels (Super Mario Bros. 2 일본 버전)

Lost Levels는 많은 것을 변경합니다:

1. 타일/스프라이트 동일 순서: 더 이상 프랑켄슈타인 레벨 없음 (유효하지 않은 ID에서도 타일과 스프라이트가 같은 레벨을 로드)
2. 단일 16비트 포인터 테이블 대신 두 개의 별도 하이/로우 테이블
3. 4개 디스크 파일: FDS용으로 ROM이 분할됨:
   • 파일 1: worlds 1-4
   • 파일 2: worlds 5-8
   • 파일 3: world 9 + 사운드 엔진
   • 파일 4: worlds A-D (완전히 다른 포인터 테이블)
4. 같은 Level ID = 4가지 가능한 레벨 로드된 파일에 따라
5. 테니스 글리치 없음: 컨티뉴 옵션 (게임 오버 후 같은 월드에서 계속)이 웜 스타트를 불필요하게 만들고, world > 9이면 게임이 즉시 리셋됨
6. 새 오브젝트: 독 버섯, 보이지 않는 블록, 보이지 않는 파이어 플라워 블록, 거꾸로 된 파이프, 바람 -- 기존 목록 중간에 삽입됨 → SMB1과의 하위 호환성 없음
7. Piranha Plants world 4 이후 항상 빨강, 스프링보드는 worlds 2/B/3/C/7에서만 초록

Super Mario All-Stars (SNES)

동일한 6502 루틴을 사용하는 직접 포팅 (SNES는 호환 모드에서 NES 코드를 실행):

• 워프 존 수정: Minus World 없음 (텍스트 왼쪽 파이프에 입력하면 올바른 월드로 이동)
• 플랜트: 대부분의 글리치 레벨 크래시 (ID $6A과 9-1 제외)
• 성 오브젝트 추가: 더 고유하게 렌더링
• 하지만: 4-2 잘못된 워프가 여전히 작동 (패치되지 않음!)

4-2 잘못된 워프: 오브젝트 배치 버그

4-2에는 두 개의 파이프 전환 오브젝트가 있습니다: 덩굴 (워프 존)과 파이프 (코인 캐시 방). 첫 번째 전환 오브젝트 (덩굴의 것)는 덩굴이 화면에 나타나기 전에 훨씬 먼저 배치됩니다. 두 번째 (파이프)는 레벨에서 너무 늦게 배치됩니다.

; Timing des transitions dans 4-2 :
; Objet transition 1 (vigne → warp zone) : placé 3 écrans avant la vigne
; Objet transition 2 (tuyau → coin cash) : placé 1 écran après le tuyau
;
; Normalement le premier objet est désactivé avant que Mario
; n'atteigne le tuyau. Mais si Mario va vite (ou utilise
; le raccourci du bloc B+right), la transition de la vigne
; est toujours active quand il touche le tuyau !
; → Le jeu charge la warp zone au lieu du coin cash.
;
; Si l'objet avait été placé juste après la vigne mais avant
; le tuyau, le bug n'existerait pas.

반복 레벨

반복 (8-4, 7-4)은 어떻게 작동하나요? 레벨은 하드코딩된 스크린 번호와 Y 위치를 가진 체크포인트를 가지고 있습니다:

; Checkpoint : {screen_number, vertical_position}
; Si Mario passe ce checkpoint à la bonne hauteur → niveau continue
; Sinon → warp back de 4 écrans (64 blocks)
;
; Pour faire une boucle infinie : vertical_position = $F0
; (en dessous du bas de l'écran) → impossible de valider.
;
; Les checkpoints sont simples (un seul flag) sauf pour world 7
; qui utilise des triplets (3 flags, il faut en échouer au moins 1)
;
; Le warp back est rude : offset de tile data réglé à une valeur
; hardcodée, offset de sprite data remis à 0. Les ennemis présents
; sont déchargés instantanément → les firebars disparaissent.

포맷을 바꾸지 않고 코드를 바꾸지 않음

이 아키텍처에서 가장 매혹적인 교훈 중 하나는 SMB1 개발자들이 6502 렌더링 코드를 건드리지 않고도 매우 표현적인 레벨 시스템을 만들었다는 것입니다. 레벨 간의 모든 변형은 코드가 아닌 데이터 (포인터, 오브젝트, 스프라이트, 바닥 패턴)에서 나옵니다.

248개 글리치 월드가 존재하는 이유는 포인터 테이블이 128개 항목 × 4가지 타입으로 설계되었고, 게임이 읽는 값을 결코 검증하지 않기 때문입니다. 포인터가 RAM에 떨어지면, 게임은 마리오의 레지스터를 타일로 해석합니다. 포인터가 사운드 데이터에 떨어지면, 게임은 음악을 레벨 디자인으로 재생합니다. 그리고 점프 테이블이 오버플로우하면, 게임은 크래시까지 아무거나 실행합니다.

이것에서 배울 수 있는 것

1. 타일/스프라이트 분리: 두 레이어의 완전한 독립성, 서로 다른 저장 순서가 고유한 프랑켄슈타인 레벨을 만듦
2. RLE 압축 + 오브젝트 시스템: 레벨은 비트맵이 아니라 배치된 오브젝트 목록이며, 바닥용 바닥 패턴이 있음
3. 3슬롯 큐: 하드웨어 (및 레벨 디자인)의 엄격한 제한
4. 검증 없음: 게임이 포인터와 점프 테이블을 신뢰하여, 플레이 가능한 글리치 또는 크래시를 만듦
5. 최대 256바이트: 6502 Y 레지스터의 제한으로 너무 멀리 가면 데이터가 반복됨
6. 웜 스타트 / 콜드 스타트: "계속" 시스템이 테니스 카트 스왑 → 마리오의 문을 열어줌

가장 아름다운 점: 이것 모두는 40KB에 들어가는 6502 코드입니다. 추상화 계층 없음, 메모리 접근 검증 없음, 예외 처리기 없음. 포인터가 나쁘면 게임이 크래시됩니다. 그리고 크래시를 우리는 글리치 월드라고 부릅니다.

기억해야 할 3가지

1. 글리치 월드는 잘못 떨어지는 포인터입니다 -- 게임에는 128개 ID × 4가지 영역 타입이 있지만 고유 레벨은 34개뿐입니다. 월드 번호가 손상되면 (테니스나 월 클립), 게임은 다른 레벨을 위해 설계된 포인터를 로드하고, 512가지 가능한 조합이 예측할 수 없는 결과를 만듭니다.

2. Minus World는 워프 버그와 손상의 조합입니다 -- 1-2의 왼쪽 파이프가 텍스트가 나타나기 전에 활성화되면 world 36 (0x24)을 로드합니다. 이 월드는 Level ID $01 (2-2의 수중), 깃발 기둥이 없는 레벨을 가리킵니다. 그리고 world 36에 파이프 전환가 없기 때문에 레벨은 무한히 반복됩니다. 검증의 부재가 이 아이콘을 만듭니다.

3. 테니스 → 마리오, OoT → Paper Mario보다 15년 앞서 -- NES의 RAM은 커패시터와 SMB1의 웜 스타트 / 콜드 스타트 시스템 덕분에 카트리지 스왑에서 살아남습니다. 테니스의 발걸음 카운터 (플레이할 때 발걸음 소리를 재생하며 RAM 바이트를 증가시키는)가 월드 번호의 주소에 정확히 떨어집니다. 탑 스코어의 자릿수가 0으로 유지되어야 하고, 바이트 $A5가 온전해야 하며, 게임이 웜 스타트를 감지해야 합니다 -- 테니스에서만 작동한 완벽한 상황의 우연입니다.

Retro Game Mechanics Explained의 원래 영상은 정말 대단한 노력입니다 -- 6502 디스어셈블리, 모든 레벨의 자동 생성 맵, 카트 스왑과 웜 스타트에 대한 설명의 수준이. 시리즈를 보지 않았다면, 짧지만 매 분밀도 밀도 있는 영상을 꼭 보세요.

맵의 소스 코드는 rgmechex.com에서 사용 가능하고, SMB1의 전체 디스어셈블리는 많은 리포지토리에서 오픈 소스입니다. 40년 전, 일본 프로그래머들이 단위 테스트도 버그 트래커도 없이 6502로 이 레벨 시스템을 작성했고, 오늘날에도 그들의 코드를 열어보면 여전히 새로운 것을 배울 수 있습니다.

Giriş

Super Mario Bros., 40 kilobyte ROM. Sekiz dünya, 32 level, düşmanlar, müzik, güçlendirmeler, hepsi bunun içinde.

Ama eğer bir emülatör açıp doğru byte'ları kurcalarsan, 36-1 levelini yükleyebilirsin. Veya 255-1'i. Veya her yerin Bowser sprite'larından ve hiçbir yere götürmeyen borulardan oluştuğu bir world'e düşebilirsin.

Bu glitch world'ler basit bir nedenden dolayı var: SMB1'in level depolama sistemi 8-bit optimizasyonu mucizesidir ve oyunu olmaması gereken yeri okumaya zorladığında, büyüleyici sonuçlar ortaya çıkar.

Retro Game Mechanics Explained bu konuda 4 videoluk bir seri yaptı -- bunları dönemin en çok satan oyununun 6502 kodunda tek bir dalışa derleyeceğiz.

Warm start: Tennis'in RAM'i SMB1'de neden hayatta kalıyor

Level depolamadan bahsetmeden önce, SMB1'in nasıl başladığını anlamamız gerekir. Çünkü NES Tennis kart değişimi glitch'i tamamen oyunun warm start / cold start tespit sistemine bağlıdır.

Korunan 41 byte

SMB1 bir cold start tespit ettiğinde (ilk kez açma veya kapatma-açma), tüm RAM'i siler. Ama bir warm start tespit ettiğinde (düğme sıfırlama, güç kesintisi yok), 41 byte'lık bir bellek alanını korur:

; Les 41 bytes préservés en RAM lors d'un warm start
; Adresses $075F-$0787
;
; $075F : byte de démarrage (world - 1)    [1 byte]
; $0760 : flag de sélection de monde (B button) [1 byte]
; $0761-$0762 : inutilisé                    [2 bytes]
; $0763-$0768 : timer (6 digits, 3 affichés) [6 bytes]
; $0769-$076E : coins Luigi                   [6 bytes]
; $076F-$0774 : coins Mario                   [6 bytes]
; $0775-$077A : score Luigi                   [6 bytes]
; $077B-$0780 : score Mario                   [6 bytes]
; $0781-$0786 : top score (6 digits, 1 caché) [6 bytes]
; $0787 : le byte magique $A5                 [1 byte]

Bu 41 byte tek bir işlev için kullanılır: oyuncunun game over'dan sonra aynı dünyada devam etmesine izin vermek. 6-3'te ölürsen, oyun world 6'yı başlangıç byte'ına yazar ve açılış ekranında A + Start'a basılı tutarsan, 6-1'den başlarsın.

Warm start'un çift kontrolü

SMB1 açıldığında, tek bir kriter değil ikisini kontrol eder:

CheckWarmStart:
  ; 1. Vérifier le byte magique $A5 à $0787
  lda $0787
  cmp #$A5
  bne ColdStart        ; pas $A5 → cold start

  ; 2. Vérifier les 6 digits du top score ($0781-$0786)
  ;    Chaque digit doit être entre 0 et 9
  ldx #0
CheckLoop:
  lda $0781,x
  cmp #$0A
  bcs ColdStart        ; digit >= 10 → cold start
  inx
  cpx #6
  bne CheckLoop

  ; Si les deux conditions passent → warm start
  ; La RAM n'est pas effacée, le monde de départ est préservé
  jmp WarmStartBoot

Neden çift kontrol? Çünkü byte $A5 rastgele olabilir (başka bir oyunun bu değeri bırakması veya RAM çipinin varsayılan dinlenme durumu). Top score'un basamaklarının geçerli (0-9) olduğunu kontrol ederek, verilerin tutarlı olduğundan emin oluruz.

Neden Tennis tek çalışan oyun

SMB1'i ilk kez taktığımızda (cold start), oyun:

1. Tüm RAM'i siler → top score = 0, world byte = 0
2. $0787 adresine $A5 yazar

Sonra konsolu kapatmadan Tennis'e geçeriz. Tennis:

• Başlangıçta RAM'i temizlemez (az sayıda NES oyunu bunu yapar)
• Top score byte'larına yazmaz → 0'da kalırlar (geçerli)
• $A5 byte'ına dokunmaz → mevcut kalır
• $075F adresini oyuncu adım sayacı için kullanır

; Le footstep increment dans Tennis :
; À chaque pas du joueur sur le court, Tennis incrémente le byte à $075F.
; Ce même byte est utilisé par SMB1 comme "world number - 1".
;
; 0 pas  → world 0 → SMB1 = world 1
; 1-7 pas → world 1-7 → worlds normaux
; 8+ pas → world 8+ → glitch worlds !
;
; Le compteur ne s'incrémente que quand la musique s'arrête
; (les footstep sounds ne jouent pas pendant la musique).

SMB1'i geri taktığımızda:

1. $A5 byte'ı hala orada (Tennis dokunmadı)
2. Top score basamakları hala 0 (geçerli)
3. World byte'ı artık 8+ (Tennis adımlarıyla arttı)
4. SMB1 warm start tespit eder → bozulmuş world byte'ını korur
5. A + Start'a basılı tut → world 9-1, world A-1, world 36-1, vb.

Neden önce Mario sonra Tennis başlatılmalı

Bir incelik: önce SMB1'i, sonra Tennis'i, sonra tekrar SMB1'i başlatmalısın. Doğrudan Tennis ile başlasaydın, $A5 byte'ı hiç yazılmazdı (Tennis $A5 yazmaz), bu yüzden warm start tespiti başarısız olurdu ve RAM silinirdi.

SMB1 level'larını 40KB'a nasıl depolar

Nintendo R&D4, dışarıdan basit görünen bir sorunu çözmek zorundaydı: yatay kayan level'ları tile'lar, düşmanlar, nesnelerle temsil etmek, hepsini aşırı sıkı bir ROM bütçesinde.

Çözüm, tamamen bağımsız iki veri katmanına ayrılmadır:

Tile düzeni (level haritası)

Her level, ROM'da sıkıştırılmış bir tile yapısına işaret eden bir göstergeç ile tanımlanır. Sıkıştırma ilkel ama zekice: bir "kontrol" byte'ı ve ardından 1-3 byte veri.

Tile formatı bir çalıştırma (RLE benzeri) sistemi kullanır:

; Format tile SMB1 (simplifié)
; Chaque "commande" est un byte contrôle :
;
; $00-$7F : pose une tile, avance d'1 colonne
; $80-$BF : pose une tile répétée N fois (N = byte - $80 + 1)
; $C0-$FF : commande spéciale (fin de ligne, saut, changement de palette)

Exemple : pour dessiner 3 briques consécutives :
  $82 $01    ; répète la tile $01 (brick) 3 fois

Her level 16 sütundan oluşan 13 satır tile içerir (13×16 = 208 görünür tile). Ama sıkıştırılmış format çok daha aşağı inebilir -- örneğin, gökyüzü ve boş sütunlar neredeyse hiç yer kaplamaz.

6502'deki işleme döngüsü:

; Décompression tile - loop principale
; Entrée : pointeur tile_data en $XX
; Sortie : tilemap niveau dans la RAM PPU

DecompressTile:
  lda (tile_ptr),y      ; lire byte contrôle
  iny
  cmp #$80
  bcc SingleTile        ; $00-$7F : tile unique
  cmp #$C0
  bcc RunLength         ; $80-$BF : run-length
  jmp SpecialCommand    ; $C0-$FF : commande spéciale

SingleTile:
  sta PPU_DATA          ; écrire la tile directement
  jmp Next

RunLength:
  sec
  sbc #$7E              ; N = control - $7E
  tax
  lda (tile_ptr),y      ; lire la tile à répéter
  iny
: sta PPU_DATA
  dex
  bne :-
  jmp Next

Sprite düzeni (düşmanlar ve nesneler)

Paralel olarak, düşmanlar ve nesneler (soru blokları, borular, goombas, koopas) tamamen ayrı bir yapıda depolanır. Her spawn 2 byte ile tanımlanır:

; Format sprite SMB1
; Byte 0 : position X (en colonnes)
; Byte 1 : type de sprite + bits de page Y
; Y est dérivé de l'index dans la séquence

Une séquence de sprites :
  $01 $4B    ; goomba à la colonne 1
  $09 $4B    ; goomba à la colonne 9
  $10 $61    ; bloc ? à la colonne 16 (contient pièce)
  $15 $54    ; koopa verte à la colonne 21
  $FF        ; fin de séquence

Her level, farklı 5 sprite sayfasına kadar (yani, 16 sütundan oluşan 5 "ekran") başvurabilir, ama pratikte çoğu level sadece 2-3 tane kullanır.

Göstergeç tablosu

Tasarım dehası göstergeç tablosudur. Her level bir ROM adresi çifti olarak depolanır:

// Structure interne (simplifiée) du World Map
struct LevelPointer {
    uint16_t tile_ptr;   // Adresse ROM des données tiles
    uint16_t sprite_ptr; // Adresse ROM des données sprites
};

// 4 tables séparées, une par AreaType :
// 0 = Water, 1 = Overworld, 2 = Underground, 3 = Castle
LevelPointer level_table[4][128];

Tablo başına 128 giriş. 4 alan türü. 512 olası kombinasyon, ama sadece bir kısmı resmi oyun tarafından kullanılır. Geri kalanı, başlatılmamış RAM veya göstergeç olarak yorumlanan verilerdir.

Oyun bir level yüklediğinde şunu yapar:

; Chargement d'un niveau
; A = AreaType (0-3), X = LevelID (0-127)

LoadLevel:
  sta AREA_TYPE
  asl                  ; *2 pour offset dans table 16-bit
  tax
  lda LevelTable_TilePtr, x
  sta TILE_PTR
  lda LevelTable_TilePtr+1, x
  sta TILE_PTR+1       ; pointeur vers les tiles
  lda LevelTable_SpritePtr, x
  sta SPRITE_PTR
  lda LevelTable_SpritePtr+1, x
  sta SPRITE_PTR+1     ; pointeur vers les sprites
  jsr DecompressTiles

Doğrulama yok. Göstergeçin geçerli olup olmadığını kontrol etme yok. Oyun tablodaki adresi okur ve o adreste bulunanı sıkıştırır, nokta.

34 benzersiz level ve 7-bit ID sistemi

SMB1'de 32 level değil, 34 benzersiz level vardır. Birçok level tekrardır (5-3 = 1-3 ama Bullet Bill'lerle) "hard mode" bayrağıyla işaretlenmiştir. Gerçek benzersiz level'lar:

• Su (Tür 0): 3 level (2-2, 7-2, bonus alanı 5-2/6-2)
• Overworld (Tür 1): 22 level (bulut bonus odaları dahil)
• Underground (Tür 2): 3 level (yeraltı bonus odaları dahil)
• Castle (Tür 3): 6 level
• + 1 kesme sahnesi odası (yeraltı/su level'larından önce)
• + 1 warp bölgesi 4-2'den

Her level 7 bit'lik bir ID'ye sahiptir. 5 alt bit = alt grup içindeki numara, 2 üst bit = alan türü:

; Encodage 7-bit du Level ID
; Bits 6-5 : Type (00=Water, 01=Overworld, 10=Underground, 11=Castle)
; Bits 4-0 : Numéro dans le sous-groupe
;
; Water IDs      : $00-$02  (types 00, numéros 0-2)
; Overworld IDs  : $20-$35  (types 01, numéros 0-21)
; Underground IDs: $40-$42  (types 10, numéros 0-2)
; Castle IDs     : $60-$65  (types 11, numéros 0-5)
;
; ID $25 = %0100101 → type 01 (Overworld), numéro 5 → 1-1
; ID $23 = %0100011 → type 01 (Overworld), numéro 3 → 6-2

128 olası ID ($00-$7F), sadece 34'ü gerçek level'lara atanmış. Kullanılmayan ID'ler herhangi bir şeye işaret eder.

Göstergeç tabloları: iki liste, iki sıra

Tile ve sprite göstergeçleri aynı sırayla depolanmaz. Kod, ayrı iki 16-bit liste kullanır (iki farklı tabloda high byte / low byte):

Sprite göstergeçlerinin sırası:
  Index 0-5   : Castle (6 level)
  Index 6-27  : Overworld (22 level)
  Index 28-30 : Underground (3 level)
  Index 31-33 : Water (3 level)

Tile göstergeçlerinin sırası:
  Index 0-2   : Water (3 level)
  Index 3-24  : Overworld (22 level)
  Index 25-27 : Underground (3 level)
  Index 28-33 : Castle (6 level)

Neden farklı sıralar? Teknik bir neden yok -- muhtemelen veriler geliştirme sırasında böyle düzenlendi. Ama bu büyüleyici bir sonuca yol açar: bir level ID'si geçersiz olduğunda, tile ve sprite göstergeçleri farklı level'lar yükler ve Frankenstein level'lar oluşturur.

Bu iki liste arasında gezinmek için oyun küçük offset tabloları kullanır (bir içindekiler tablosu gibi):

; Tables d'offset par type (Water, Overworld, Underground, Castle)
; Chaque entrée = index de début dans la liste correspondante

SpriteOffsetTable:
  .byte $1F, $06, $1C, $00    ; Water=31, Overworld=6, Underground=28, Castle=0

TileOffsetTable:
  .byte $00, $03, $19, $1C    ; Water=0, Overworld=3, Underground=25, Castle=28

6-2 level'ını (ID $23, Overworld numara 3) yüklemek için:

; 1. Type = 01 (Overworld) → index dans table d'offset = 1
; 2. Sprite offset = SpriteOffsetTable[1] = 6
;    Index final = 6 + 3 (numéro de niveau) = 9 → 10ème pointeur sprites
; 3. Tile offset = TileOffsetTable[1] = 3
;    Index final = 3 + 3 = 6 → 7ème pointeur tiles
; 4. Résultat : pointeur tiles $A619 + pointeur sprites $9ED0 = 6-2 ✓

Şimdi, $43 (Underground numara 3, var olmayan) gibi geçersiz bir ID ile ne olur?

; ID $43, Type = 10 (Underground), numéro = 3
; Sprite offset = SpriteOffsetTable[2] = $1C = 28
;   Index = 28 + 3 = 31 → 32ème pointeur sprites = eau bonus 5-2 !
; Tile offset = TileOffsetTable[2] = $19 = 25
;   Index = 25 + 3 = 28 → 29ème pointeur tiles = 1-4 (Castle) !
;
; Résultat : un niveau souterrain avec les tiles de 1-4
; et les Bloopers de la zone eau de 5-2. Un vrai Frankenstein.

World index tablosu: world 9 neden taşar

Her world'ün (1-8) ilk level'ının indexini veren 8 byte'lık bir ROM tablosu vardır. Ve hemen ardından, tüm level'ların oyun sırasına göre 36 Level ID tablosu.

; WorldIndexTable (8 bytes)
  .byte 0, 5, 10, 15, 20, 25, 28, 33
;   -> Monde 1 commence au niveau 0
;   -> Monde 2 commence au niveau 5
;   -> Monde 8 commence au niveau 33

; LevelIDTable (36 bytes)
  .byte $25, $28, $29, $26, $24, ... ; les 36 Level IDs

World 9'u yüklemeye çalıştığımızda, oyun WorldIndexTable'ın 9. byte'ını okur... bu mevcut değildir. LevelIDTable'a 1 byte taşar, $25 değerini okur, sonra LevelIDTable'da indeks olarak $25 kullanır (37. giriş) -- bu SpriteOffsetTable'a 2 byte taşar ve 6 değerini okur.

; World 9 :
;   1. WorldIndexTable[8] (overflow) → lit $25 dans LevelIDTable
;   2. LevelIDTable[37] (overflow) → lit le 2ème byte de SpriteOffsetTable = 6
;   3. ID = 6 → Water level number 6 (qui n'existe pas)
;   4. Tile pointer = pointeur water numéro 6 = tiles de 6-2
;   5. Sprite pointer = index 31+6 = 37 > 33 → pointeur invalide
;   6. Résultat : 6-2 sous l'eau avec des sprites glitchés
;      → world 9-1 !

World G (16) için, taşma daha da ileri gidip 1-2'den önceki kesme sahnesi olan Level ID $01'e düşer:

; World G (16) :
;   WorldIndexTable[15] → lit $01 dans LevelIDTable
;   LevelIDTable[1] = $29 (cutscene 1-2)
;   → world G-1 = la cutscene d'entrée de 1-2

Glitch world'ler neden var

Oyunun 32 "meşru" level'ı var (8 dünya × 4 level). Ama göstergeç tablosu alan türü başına 128 giriş yapıyor. 32. level'ın ötesindeki girişler, bu adreslerde ROM'da bulunanı içerir -- bazen başka bir level, bazen ses verileri, bazen RAM, bazen de herhangi bir şey.

Level ID $01 + AreaType 0 = Minus World

Glitch world'lerin en ünlüsü. AreaType 0 (su) içindeki Level ID $01 şunlara işaret eder:

• Tile göstergeci: $AE45 → 2-2/7-2'nin sualtı bölgesi
• Sprite göstergeci: $A171 → 2-2/7-2'nin sprite'ları

Sonuç: 2-2'ye benzeyen ama sonsuza kadar dönen bir su level'ı çünkü flagpole mevcut değil. Level sonu yok, çıkış yok.

Bu 36-1 level'ıdır (veya $-1 dünyasında 36-1).

; Pourquoi le flagpole manque dans le Minus World :
; Les sprites de 2-2/7-2 ($A171) n'ont pas de flagpole
; dans leur séquence. Le jeu cherche le sprite $FD (flagpole)
; mais ne le trouve jamais → boucle infinie
;
; Le jeu continue de générer le niveau à l'infini
; jusqu'à ce que le timer atteigne zéro.

RAM'a işaret eden göstergeçler

Tile göstergeci veya sprite göstergeci ROM yerine RAM'daki ($00-$7F) bir adrese işaret ettiğinde, oyun RAM'deki sürekli değişimleri tile olarak yorumlamaya çalışır:

; Exemple : Level ID $03 en Water
; Tile Pointer : $A46B (3-3 - valide)
; Sprite Pointer : $009D (pointe vers la RAM page zéro !)
;
; La RAM page zéro contient les registres du jeu,
; la position de Mario, l'état des compteurs...
; Le jeu décompresse ça comme une séquence de sprites,
; et le résultat c'est un niveau avec des ennemis
; qui sont en fait des valeurs de registres.

Sıfır sayfası değiştiğinde (Mario hareket ettiğinde, zamanlayıcı döndüğünde vb.), level'ın "sprite'ları" da değişir. Bu yüzden bazı glitch world'lerde titreyen ve sürekli dönüşen düşmanlar bulunur.

Level ID $36: boş level (Overworld)

Overworld'de Level ID $36:

• Tile göstergeci: $AC35 (1-2)
• Sprite göstergeci: $A0D8 (1-2)

Sonuç: hiçbir şey. Oyun level'ı yükler ama RGMechEx kataloğunda "levelsiz" olarak işaretlenmiştir. Tile'lar belki geçerlidir ama sprite'lar boş veya çalışmayan bir level üreten bir yere işaret eder.

Level ID $1D (Castle): çökme şampiyonu

Castle'da Level ID $1D:

• Tile göstergeci: $A210 (4-4)
• Sprite göstergeci: $7EA0 (RAM!)

Sprite göstergeci RAM'de = tanımsız sprite'lar. Oyun tile'ların ilk satırında bir Spiny topu veya Bullet Bill blaster göstermeye çalışır. Hemen çöker.

; Quand le sprite pointer pointe vers la RAM,
; le jeu décompresse des bytes qui changent tout le temps
; comme des instructions "spawn". Le résultat :
; - Apparition d'objets inexistants (valeur undefined)
; - Crash PPU quand le sprite NES essaie d'afficher un tile invalide
; - Freeze complet de la console

Kataloglanan 256 glitch world

RGMechEx, tüm level'ların haritasını oluşturan bir script yazdı, 4 alan türü ve her biri 128 ID için.

World sayacı 8 bit (0-255) üzerindedir. World 1-8 meşrudur. Kalan 248 potansiyel glitch world vardır. Her glitch world bu world'ün ilk level'ına karşılık gelir ve Level ID'si WorldIndexTable taşma mekanizması tarafından hesaplanır.

128 olası ID'den sadece 68'i bir world'ün "ilk level"ıdır (glitch world numarası ile erişilebilir). Diğer 60'ı 2+ level veya erişilemez.

Tür	Oynanabilir benzersiz ID'ler	Çöken ID'ler	Boş ID'ler
Water (0)	~20	~60	~48
Overworld (1)	~30	~55	~43
Underground (2)	~15	~65	~48
Castle (3)	~25	~58	~45

Birçok ID aynı adrese düşen göstergeçler nedeniyle aynı level'a gider. Örneğin Level ID $28 (Overworld) -- tile göstergeci $A7CD (2-1) -- 38 farklı glitch world'de görünür, çünkü sprite göstergeci $9F51 ROM'un birçok ID tarafından yeniden kullanılan ses verileri/padding bölgesine işaret eder.

Gerçekten benzersiz 6 glitch level

Erişilebilir 19 glitch level ID'sinden sadece 6'sı yükleme sırasında hemen çökmüyor:

World	Level ID	Açıklama
E-1 (224)	$50	Bir uçurumun üzerinde tek bir ? bloğu. Mario anında ölür.
W	$57	Mario spawn'da kilitli, hareket edemiyor.
42 (133)	$50	Mario yeterince ileri giderse tuzağa düşüren bulut tüneli.
62 (131, 240)	$4D	Donmuş kale: Mario yukarıda spawn olur, düşemez → kilitli.
127	$4B	Yeraltı tüneli, ama çok ileri gidersen çöker.
137	$4B	Kesme sahnelerinin otomatik kaydırmayı etkinleştirir. Mario'yu ebediyen bloklayan tek bir tuğla blokla karşılaşır.

248'den sadece 6 glitch world gerçekten yeni bir şey üretiyor. Geri kalanı, yanlış alan türüne sahip normal level'lar veya siyah ekranlar.

Level formatı detaylı olarak

Level verilerinin kesin formatına bir göz atalım, glitch level'ların neden ayakta durduğunu (ya da durmadığını) anlamak için.

Level başlığı: 2 byte, 6 özellik

Her level, 6 özelliği kontrol eden 2 byte'lık bir başlıkla başlar:

; Byte 0 : timer + Y start + modifier
;   Bits 7-6 : timer (00=inchangé, 01=200, 10=300, 11=400)
;   Bits 5-3 : Y start Mario (111/110 = autowalk)
;   Bits 2-0 : level type modifier
;              000=default, 001=waves, 010=brick wall,
;              011=water bottom, 100=night, 101=snow,
;              110=snow night, 111=gray night

; Byte 1 : platform + background + floor pattern
;   Bits 7-6 : special platform (00=tree, 01=mushroom,
;                                 10=Bullet Bill, 11=cloud)
;   Bits 5-4 : background (00=none, 01=clouds,
;                           10=montains, 11=fences)
;   Bits 3-0 : floor pattern initial (0-15)

Tür değiştirici görsel varyasyonları kontrol eder: su level'larının üstündeki dalgalar, 8-3'ün tuğla arka planı, 4-3'ün gece paleti, 6-2'nin karı vb.

Tile nesneleri: 2 byte, Next Screen Flag, 3 slot'luk kuyruk

Başlıktan sonra bir tile nesnesi listesi gelir, her nesne 2 byte. $FD byte'ı listenin sonunu işaret eder.

; Format objet tile (16 bits) :
; Byte 0 :
;   Bits 7-4 : X position (colonne 0-15)
;   Bits 3-0 : Y position
;     Y=0-11  : position Y normale
;     Y=12    : objets spéciaux (trous, ponts, rope, ? blocks)
;     Y=13    : screen skip / objets spéciaux 2
;     Y=14    : changement de modifier/scenery/floor
;     Y=15    : objets spéciaux 3 (château, escaliers, gros tuyau)

; Byte 1 :
;   Bit  7   : NEXT SCREEN FLAG
;   Bits 6-4 : type d'objet (0-7)
;   Bits 3-0 : largeur/hauteur / sous-type

"Next screen" biti ayarlandığında, mevcut çalışma sütunu 1 artırılır. Bu, ilk 16 sütunun ötesine nesneler yerleştirmeye olanak tanır. Nesneler sırayla (soldan sağa) listelenmelidir çünkü oyun bunları sıralı olarak yükler:

; La routine de chargement a DEUX phases par colonne :
; Phase 1 : chercher les nouveaux objets qui commencent sur cette colonne
;            et les ajouter à la file d'attente (queue)
; Phase 2 : traiter chaque objet dans la queue en dessinant les tiles,
;            et retirer ceux qui finissent sur cette colonne

Kuyruk tam olarak 3 slot yapar. Doğrudan sonuç: aynı sütunda başlayan 3'ten fazla nesne olamaz. Kuyruk doluysa, 4. nesne yok sayılır ve hiç yüklenmez.

Bu yüzden iyi tasarlanmış level'lar çok fazla nesne yığmaktan kaçınır. 1-2'deki örnek: tavan içindeki 1up bloğu ile yanındaki tuğlalar, 3 limitine uymak için iki ayrı nesneye bölünmüştür.

Özel Y pozisyonu: 12, 13, 14, 15

Y=12 olduğunda, nesnenin Y pozisyonu yoktur (tür tarafından hardcoded):

; Y=12 : objets sans Y position
;   Type 0 : trou (supprime le sol)
;   Type 1 : rope de plateforme mobile
;   Types 2-4 : ponts à Y fixe
;   Type 5 : trou avec eau/lave
;   Types 6-7 : rangées de ? blocks

Y=13 olduğunda, iki alt grup vardır. Byte 1'in 6. biti 1 ise:

; Y=13, bit6=1 : objets spéciaux
;   0 = L-pipe (cutscene), 1 = flagpole, 2-3 = pont/axe/hamer (fin château)
;   4 = stop screen, 5 = random enemies, 6 = loop level, 7+ = crash possible

bit6=0 ise, en düşük 5 bit bir ekran atlama (next screen flag ile tek tek geçmek yerine doğrudan N ekranına atlamak) kodlar.

Y=14 olduğunda: bit6=1 ile tür değiştiriciyi, bit6=0 ile arka planı + zemin desenini değiştirmek için aynı prensip.

Zemin desenleri: 16 zemin deseni

Level'ların zemini tek tek nesnelerden yapılmamıştır. SMB1 zemin desenleri kullanır, bir sonraki değişikliğe kadar tüm sütunlara uygulanan bir arka plan deseni:

; Floor patterns (4 bits = 16 possibilités)
;   0 = vide total
;   1 = sol 2 tiles haut
;   2 = sol 1 tile haut
;   3 = sol + bottom
;   4 = sol + bottom 2
;   5 = sol 1/2 tile
;   6 = 3/4 sol
;   ... jusqu'à 15 = rempli total (sol + plafond)

Bu yüzden delikler nesnedir: belirli bir sütunda zemin desenini override eder, geri kalanını değiştirmeye gerek kalmaz.

256 byte limiti ve tekrar

Bir level'ın tüm tile verileri en fazla 256 byte'a sığar. 6502'nin Y register'ı indeks olarak kullanılır ve 8 bit yapar. Oyun verilerin sonuna $FD byte'ı bulamadan ulaşırsa, başa döner ve 256 byte'ı sonsuza kadar tekrarlar:

; Index Y = 8 bits → max 256 bytes de données tiles
; Si Y overflow (255 → 0) sans rencontrer $FD → repeat
; Même chose pour les sprites, mais les objets pipe (3 bytes)
; décalent la parité de l'index à chaque chargement.

Bazı glitch level'lar bu tekrarı, level'ları "sonsuza kadar" sürecek şekilde üretmek için kullanır.

Sprite sistemi: 2 byte + boru geçişleri

Sprite'lar benzer bir format izler, ama başlıksız ve birkaç temel farkla. $FF byte'ı listenin sonunu işaret eder.

; Format sprite (2 bytes) :
; Byte 0 : position X (colonne)
; Byte 1 :
;   Bit 7 : NEXT SCREEN FLAG
;   Bits 6-0 : type de sprite
;       Certains types incluent : goomba, koopa, Blooper,
;       Bullet Bill, Lakitu, Spiny, plateformes,
;       commande warp zone, toad/princesse,
;       commandes de spawn de groupes d'ennemis

Byte 1'in en düşük biti hard level flag'idir: 1'e ayarlanırsa, sprite sadece 5-3 ve üzeri level'larda görünür. "Hard mode" level'ları böyle oluşturulur.

Y pozisyonu 15 = ekran atlama (tile'lar ile aynı). Y pozisyonu 14 = boru geçişi (3 byte):

; Sprite Y=14 : pipe/vine transition (3 bytes !)
;   Byte 0 : position X
;   Byte 1 : bits 6-0 = Level ID 7-bit (destination)
;   Byte 2 : bits 4-0 = screen de destination
;            bits 7-5 = world où cette transition est valide
;
; Pourquoi un world ? Les bonus rooms sont réutilisées entre mondes.
; Exemple : la salle bonus de 1-1 est aussi utilisée par 2-1 et 7-1.
; Cette salle a 3 transitions, une par monde, pour que Mario
; réapparaisse au bon endroit.

Sprite'ların kuyruk sistemi yoktur. Tek sınırlama, spawn bölgesinde (sağda ekranda) aynı anda 4'ten fazla sprite'ın yüklenememesidir. Aksi takdirde sprite'lar yok sayılır.

Glitch world'lere nasıl erişilir

İki ana yöntem vardır.

Klasik yöntem: wall clip

Wall clip (duvarlardan geçme), normal level'dan çıkıp gizli warp bölgesine yürümemizi sağlar. RAM üzerinden world sayacını manipüle ederek, herhangi bir Level ID yükleyebiliriz.

Teknik:

1. World 1-2: gizli bitiş borusuna git
2. Sağdaki duvarda wall clip yap
3. Warp bölgesine kadar boşlukta yürü
4. Oyun değerleri world olarak yorumlar

Ama bu yöntem sadece bir kısmına erişim sağlar.

Extreme yöntem: NES Tennis kart değişimi

Ayrıntılar için yukarıdaki "Warm start" bölümüne bakın. Özetle: Tennis'in adım sayacı, SMB1'in world byte'ına aynı RAM byte'ına yazar ve warm start tespiti bu değeri korur.

Hackçiler köşesi: keşfetmek için kod

Tüm glitch world'leri bir emülatörde kendin keşfetmek istersen, Level ID'sini doğrudan yamalayabilirsin:

; Patch pour FCEUX / Mesen :
; Adresse RAM $075F = Level ID actuel
; Adresse RAM $0760 = Area Type (0=Water, 1=Overworld, 2=Underground, 3=Castle)

; Exemple : charger le Level 57 (0x39) en Overworld
; Dans l'émulateur, ouvrir le traceur mémoire et écrire :
; $075F = 0x39
; $0760 = 0x01
; Puis entrer dans un tuyau de warp ou mourir et recommencer
; → Le jeu charge le niveau ID $39 en Overworld

RGMechEx, 128 level × 4 türün otomatik oluşturulmuş haritalarla tam listesini rgmechex.com adresinde yayınladı. Her giriş tile göstergecini, sprite göstergecini ve level'ın görsel haritasını gösterir.

En çok wtf dedirten level'lar

Level ID $1F (Water): 15 glitch world tek çatı altında

Tile göstergeci $A302 (3-4) ile sprite göstergeci $02A0 kombinasyonu 15 farklı glitch world verir (D-1, J-1, Y-1, Z-1, 55-1, 73-1...). Açıklama: sprite göstergeci, geçerli sprite'lara yeterince yakın veriler içeren bir ROM alanına işaret eder, ama 3-4 kale tile'larının overworld sprite'larıyla kombinasyonu saçma bir render üretir.

Level ID $28 (Overworld): 38 glitch world = rekor

Mutlak rekor. 38 glitch world girişi aynı level'a (2-1 tile + $9F51 sprite) işaret eder. Neden? Çünkü sprite göstergeci $9F51, birçok ID tarafından yeniden kullanılan ses verileri/padding bölgesine düşen bir ROM alanına işaret eder.

Level ID $49 (Underground): FDS level'ı

Tile göstergeci $76AE + sprite göstergeci $1C9D. Tile göstergeci, Famicom Disk System sürümüne ayrılmış ROM alanına işaret eder. Sonuç: standart kartta mevcut olmayan tile'lara sahip level. Bu level 52-1 ve 196-1 level'larını görünür kılar.

Level ID $00-$02: gerçek bonus level'ları

Bu ID'ler oyunun meşru alt level'ları tarafından kullanılır:

• $00: 5-2/6-2 sualtı bölgesi (H-1, 39-1 tarafından kullanılır)
• $01: 2-2/7-2 suyu (Minus World, 36-1)
• $02: 8-4 alt level'ı (136-1, 151-1, 215-1)

Normalde erişilebilir bir "bonus" level ile glitch world arasındaki fark, warp bölgelerinin mevcut world'ü kontrol etmesidir:

; Vérification warp zone (simplifié)
; Le jeu vérifie que le monde cible est entre 1 et 8
CheckWarp:
  lda TARGET_WORLD
  cmp #1
  bcc InvalidWarp       ; < 1 → refusé
  cmp #9
  bcs InvalidWarp       ; > 8 → refusé
  ; world valide entre 1 et 8 uniquement
  jmp DoWarp

8'den büyük veya 0 numaralı glitch world'ler normal borularla ulaşılamaz. Wall clip veya kart değişimi gerekir.

Bazı level'lar neden çöker: jump tabloları

Oyun bir tile nesnesi yüklediğinde, türünü bir jump tablosunda indeks olarak kullanır:

; Jump table des objets tiles standards (types 0-11)
JumpTable_TileObjects:
  .word Obj_Special       ; type 0 : bloc ?, hidden, flagpole...
  .word Obj_Platform      ; type 1 : plateforme spéciale
  .word Obj_BrickRow      ; type 2 : rangée de briques
  .word Obj_BlockRow      ; type 3 : rangée de blocks
  .word Obj_CoinRow       ; type 4 : rangée de pièces
  .word Obj_BrickCol      ; type 5 : colonne de briques
  .word Obj_BlockCol      ; type 6 : colonne de blocks
  .word Obj_Pipe          ; type 7 : tuyau
  .word Obj_8             ; type 8
  .word Obj_9             ; type 9
  .word Obj_10            ; type 10
  .word Obj_11            ; type 11

Bir nesnenin geçersiz türü varsa (≥12), oyun tabloda olmayan bir göstergeçe atlar. 4 olası sonuç:

1. Geçerli göstergeç → nesne normal yüklenir
2. Başka bir jump tablosuna göstergeç (çakışma) → farklı bir nesne görünür. Örnek: tür 12, Y=13 tablosuna işaret eder, bu bir L-pipe verir.
3. Çalıştırılabilir koda göstergeç → rastgele kod çalıştırma (muhtemelen çökme)
4. Açık NOP yer tutucusu → nesne hiçbir şey yapmaz (bazı sprite'lar böyledir, yerinde uçan ama hareket etmeyen düşmanlar üretir)

Glitch level ID $58 (çöken tünel): sprite göstergeci, ROM mapper'ı olmayan NES'te mevcut olmayan bir bellek bölgesine işaret eder. Oyun aynı Koopa'yı (0,0) konumunda kare başına 5 kez yüklemeye çalışır, bu PPU'yu doyurur ve donmaya neden olur.

; Pourquoi ID $58 crashe :
; Sprite pointer → adresse invalide (hors espace NES standard)
; → Le jeu lit des bytes indéterminés comme des types de sprite
; → Le Koopa $00 (type invalide sans handler) boucle en appel récursif
; → Stack overflow 6502 → freeze

Boru warp paradoksu

target_world BETWEEN 1 AND 8 kontrolünü hatırla. Bir glitch world'de bir boru bulsan bile, oyun hedef world'ün 1 ile 8 arasında olduğunu kontrol eder. Glitch world'lerin numaraları 8'den büyüktür (36-1, 255-1...), bu yüzden warp başarısız olur.

Bu yüzden Minus World'ün sonu yoktur: flagpole sprite'larda mevcut değildir ve borular hiçbir yere götürmez.

Sütunda 5 nesne hilesi

Sütun başına 3 nesme limitini aşmaya izin veren bir köşe durumu vardır. Kuyruk dolduğunda (slot'lar dolu + sonraki nesnede next screen flag eksik), oyun mevcut sütunu bir next screen flag'li nesne bulana kadar döngü içinde "ön işler". Her ön işlem sırasında:

; Pendant le prétraitement de colonne :
; 1. Les objets dans la queue voient leur largeur restante
;    décrémentée à chaque "fausse avancée" de colonne
; 2. Si un objet atteint largeur=0, il quitte la queue
; 3. Un slot libéré peut être rempli par un nouvel objet
;    ajouté dans la même colonne

; Résultat : jusqu'à 5 objets peuvent être traités sur la même colonne.
; Technique : placer 2 objets qui traversent la screen boundary
; (slots 1 et 2), 1 objet dummy en X < précédent (bloque la queue),
; puis 3 objets à X=0 de l'écran suivant (dont un avec next screen flag).

Buna "queue skip" denir ve bazı romhacker'lar tarafından formatın normalde izin verdiğinden daha yoğun level'lar oluşturmak için kullanılır.

Sürümler arasındaki farklar

Famicom Disk System

SMB1'in FDS sürümü farklı bir bellek haritasına sahiptir. Tüm level göstergeçleri kaydırılmıştır ama veriler aynıdır. Değişen şey: glitch world endeksleri tamamen farklıdır:

FDS World 36 → Level ID $09 (eau version de 5-3)
  → Le flagpole est présent ! On peut finir le niveau.
  → Ensuite : $27 (7-3 normal) → $44 (4-4 underground)
  → $44 est finissable → la hache fonctionne → fin du jeu !
  
Le Minus World FDS est donc un "bonus world" qui peut mener
à la complétion du jeu, contrairement à la version NES.

Favori FDS level'ım: ID $5F, 3-3'ün ikinci yarısının yeraltı versiyonu alçak tünelde (otomatik kaydırıcı olduğu için yazık).

The Lost Levels (Super Mario Bros. 2 Japon)

Lost Levels birçok şeyi değiştirir:

1. Tile/sprite sırası aynı: Artık Frankenstein level'lar yok (tile'lar ve sprite'lar geçersiz ID ile bile aynı level'ı yükler)
2. Tek 16-bit göstergeç tablosu ayrı high/low tabloları yerine
3. 4 disk dosyası: ROM FDS için bölünmüş:
   • Dosya 1: world 1-4
   • Dosya 2: world 5-8
   • Dosya 3: world 9 + ses motoru
   • Dosya 4: world A-D (tamamen farklı göstergeç tablosu)
4. Aynı Level ID = 4 olası level yüklenen dosyaya göre
5. Artık Tennis glitch'i yok: continue seçeneği (game over'dan sonra aynı world'de devam) warm start'ı gereksiz yapar ve oyun hemen sıfırlar world > 9 ise
6. Yeni nesneler: zehir mantarı, görünmeyen blok, görünmeyen ateş çiçeği bloğu, ters borular, rüzgar -- ama mevcut listelerin ortasına eklendi → SMB1 ile geriye uyumluluk sorunu
7. Piranha Plant'lar world 4'ten sonra her zaman kırmızı, çengeller sadece world 2/B/3/C/7'de yeşil

Super Mario All-Stars (SNES)

Aynı 6502 rutinleriyle doğrudan port (SNES, NES kodunu uyumlu modda çalıştırır):

• Warp bölgesi düzeltildi: Artık Minus World yok (soldaki boruya metinden önce girmek doğru world'e götürür)
• Çökme: Çoğu glitch level çöker (ID $6A ve 9-1 hariç)
• Kale nesneleri eklendi: Daha benzersiz render'lar
• Ama: 4-2 wrong warp hala çalışıyor (yamalanmamış!)

4-2 wrong warp: bir nesne yerleştirme hatası

4-2'de iki boru geçiş nesnesi vardır: asma ipi (warp bölgesi) ve boru (para odası). İlk geçiş nesnesi (asma ipi olan), asma ipi ekranda görmeden çok önce yerleştirilmiştir. İkinci (boru), level'da çok geç yerleştirilmiştir.

; Timing des transitions dans 4-2 :
; Objet transition 1 (vigne → warp zone) : placé 3 écrans avant la vigne
; Objet transition 2 (tuyau → coin cash) : placé 1 écran après le tuyau
;
; Normalement le premier objet est désactivé avant que Mario
; n'atteigne le tuyau. Mais si Mario va vite (ou utilise
; le raccourci du bloc B+right), la transition de la vigne
; est toujours active quand il touche le tuyau !
; → Le jeu charge la warp zone au lieu du coin cash.
;
; Si l'objet avait été placé juste après la vigne mais avant
; le tuyau, le bug n'existerait pas.

Döngü level'ları

Döngüler (8-4, 7-4) nasıl çalışır? Level, hardcoded ekran numaraları ve Y pozisyonlarına sahip kontrol noktalarına sahiptir:

; Checkpoint : {screen_number, vertical_position}
; Si Mario passe ce checkpoint à la bonne hauteur → niveau continue
; Sinon → warp back de 4 écrans (64 blocks)
;
; Pour faire une boucle infinie : vertical_position = $F0
; (en dessous du bas de l'écran) → impossible de valider.
;
; Les checkpoints sont simples (un seul flag) sauf pour world 7
; qui utilise des triplets (3 flags, il faut en échouer au moins 1)
;
; Le warp back est rude : offset de tile data réglé à une valeur
; hardcodée, offset de sprite data remis à 0. Les ennemis présents
; sont déchargés instantanément → les firebars disparaissent.

Formatı değiştir, kodu değil

Bu mimarinin en büyüleyici derslerinden biri, SMB1 geliştiricilerinin 6502 işleme koduna hiç dokunmadan son derece expresif bir level sistemi oluşturmayı başarmış olmasıdır. Level'lar arasındaki tüm çeşitlilik verilerden (göstergeçler, nesneler, sprite'lar, zemin desenleri) gelir, koddan değil.

248 glitch world, göstergeç tablolarının 128 giriş × 4 tür için boyutlandırılmış olmasından ve oyunun okuduğu değerleri hiç doğrulamamasından dolayı var. Bir göstergeç RAM'e düştüğünde, oyun Mario'nun register'larını tile olarak yorumlar. Bir göstergeç ses verilerine düştüğünde, oyun müziği level tasarımı olarak çalar. Ve jump tabloları taştığında, oyun çökene kadar her şeyi çalıştırır.

Tüm bunlardan neler öğrenebiliriz

1. Tile/sprite ayrımı: iki katmanın toplam bağımsızlığı, benzersiz Frankenstein level'lar oluşturan farklı depolama sıralarıyla
2. RLE sıkıştırması + nesne sistemi: level'lar bitmap'ler değil, yerleştirilmiş nesne listeleridir, zemin için zemin desenleriyle
3. 3 slot'luk kuyruk: donanımın (ve level tasarımının) katı limiti
4. Doğrulama yok: oyun göstergeçlere ve jump tablolarına güvenir, bu da ya oynanabilir glitch'ler ya da çökme üretir
5. Maksimum 256 byte: 6502 Y register limiti, verilerin çok ileri gidildiğinde tekrar etmesine neden olur
6. Warm start / cold start: "devam etme" sistemi, Tennis kart değişimi → Mario'nun kapısını açtı

En güzeli: tüm bunlar 40KB'a sığan 6502 kodudur. Soyutlama katmanı yok, bellek erişim doğrulaması yok, istisna yöneticisi yok. Göstergeç bozuksa, oyun çöker. Ve çökmelere glitch world diyoruz.

3 şey

1. Glitch world'ler yanlış yere düşen göstergeçlerdir -- Oyunun 128 ID × 4 alan türü var ama sadece 34 benzersiz level. World numarası bozulduğunda (Tennis veya wall clip ile), oyun başka bir level için tasarlanmış bir göstergeç yükler ve 512 olası kombinasyon öngörülemeyen sonuçlar üretir.

2. Minus World, warp hatasının bozulmayla birleşimidir -- 1-2'deki soldaki boru, metin appearing'den önce etkinleştirilirse, 36 (0x24) world'ünü yükler. Bu world, Level ID $01'e (2-2 suyu) işaret eder, flagpole'siz bir level. Ve world 36 için boru geçişi olmadığından, level sonsuza kadar döner. Doğrulama eksikliği ikonu yaratır.

3. Tennis → Mario, OoT → Paper Mario'dan 15 yıl önce -- NES'in RAM'i, kondansatörler ve SMB1'in warm start / cold start sistemi sayesinde kart değişiminden hayatta kalır. Tennis'in adım sayacı (adım sesini çalarken bir RAM byte'ını artıran), world numarasının tam adresine düşer. Top score'un basamaklarının 0'da kalması, $A5 byte'ının sağlam olması ve oyunun warm start tespit etmesi gerekir -- sadece Tennis ile çalışan mükemmel bir koşullar birleşimi.

Orijinal videolar Retro Game Mechanics Explained tarafından yapılmıştır -- 6502 deassembly, tüm level'ların otomatik haritaları, kart değişimi ve warm start açıklamaları üzerindeki detay seviyesi mükemmel. Seriyi görmediysen, izle, kısa ve her dakikası yoğun.

Map'lerin kaynak kodu rgmechex.com adresinde mevcut ve SMB1'in tam deassembly'si birçok repo'da açık kaynak. 40 yıl önce, Japon programcılar bu level sistemini 6502'de sıfır birim testi ve sıfır hata izleyici ile yazdı ve bugün hala kodlarını açarak yeni şeyler öğreniyoruz.

Introduzione

Super Mario Bros. sono 40 kilobyte di ROM. Otto mondi, 32 livelli, nemici, musica, power-up, tutto ci sta dentro.

Ma se apri un emulatore e modifichi i byte giusti, puoi caricare il livello 36-1. Oppure il 255-1. O atterrare in un mondo dove tutto è fatto di sprite di Bowser e tubi che non portano da nessuna parte.

Questi glitch worlds esistono per una ragione semplice: il sistema di archiviazione dei livelli di SMB1 è una meraviglia di ottimizzazione a 8 bit, e quando si costringe il gioco a leggere dove non dovrebbe, i risultati sono affascinanti.

Retro Game Mechanics Explained ha fatto una serie di 4 video a riguardo -- li compileremo in un'unica immersione nel codice 6502 del gioco più venduto della sua epoca.

Il warm start: perché la RAM di Tennis sopravvive in SMB1

Prima di parlare di archiviazione dei livelli, bisogna capire come SMB1 si avvia. Perché il glitch del cart swap NES Tennis si basa interamente sul sistema di rilevamento warm start / cold start del gioco.

I 41 byte preservati

Quando SMB1 rileva un cold start (prima accensione o power off/on), cancella tutta la RAM. Ma quando rileva un warm start (reset pulsante, senza interruzione dell'alimentazione), preserva un'area di memoria di 41 byte:

; I 41 byte preservati in RAM durante un warm start
; Indirizzi $075F-$0787
;
; $075F : byte di avvio (world - 1)    [1 byte]
; $0760 : flag selezione mondo (B button) [1 byte]
; $0761-$0762 : inutilizzato              [2 byte]
; $0763-$0768 : timer (6 cifre, 3 mostrate) [6 byte]
; $0769-$076E : monete Luigi               [6 byte]
; $076F-$0774 : monete Mario               [6 byte]
; $0775-$077A : punteggio Luigi            [6 byte]
; $077B-$0780 : punteggio Mario            [6 byte]
; $0781-$0786 : high score (6 cifre, 1 nascosta) [6 byte]
; $0787 : il byte magico $A5              [1 byte]

Questi 41 byte servono a una sola funzionalità: permettere al giocatore di continuare nello stesso mondo dopo un game over. Se muori in 6-3, il gioco scrive il mondo 6 nel byte di avvio, e nella schermata titolo, se tieni premuto A + Start, ricominci in 6-1.

La doppia verifica del warm start

Quando SMB1 si avvia, non verifica un solo criterio ma due:

CheckWarmStart:
  ; 1. Verificare il byte magico $A5 a $0787
  lda $0787
  cmp #$A5
  bne ColdStart        ; non è $A5 → cold start

  ; 2. Verificare le 6 cifre dell'high score ($0781-$0786)
  ;    Ogni cifra deve essere tra 0 e 9
  ldx #0
CheckLoop:
  lda $0781,x
  cmp #$0A
  bcs ColdStart        ; cifra >= 10 → cold start
  inx
  cpx #6
  bne CheckLoop

  ; Se entrambe le condizioni passano → warm start
  ; La RAM non viene cancellata, il mondo di partenza è preservato
  jmp WarmStartBoot

Perché una doppia verifica? Perché il byte $A5 potrebbe essere presente per caso (un altro gioco che lascia questo valore, o lo stato di default del chip RAM). Verificando che le cifre dell'high score siano valide (0-9), ci si assicura che i dati siano coerenti.

Perché Tennis è l'unico gioco che funziona

Quando si inserisce SMB1 per la prima volta (cold start), il gioco:

1. Cancella tutta la RAM → high score = 0, world byte = 0
2. Scrive $A5 all'indirizzo $0787

Poi si passa a Tennis senza spegnere la console. Tennis:

• Non pulisce la RAM all'avvio (pochi giochi NES lo fanno)
• Non scrive sui byte dell'high score → rimangono a 0 (validi)
• Non tocca il byte $A5 → rimane presente
• Usa l'indirizzo $075F per il contatore dei passi del giocatore

; Il footstep increment in Tennis:
; A ogni passo del giocatore sul campo, Tennis incrementa il byte a $075F.
; Questo stesso byte è usato da SMB1 come "world number - 1".
;
; 0 passi  → world 0 → SMB1 = world 1
; 1-7 passi → world 1-7 → mondi normali
; 8+ passi → world 8+ → glitch worlds !
;
; Il contore si incrementa solo quando la musica si ferma
; (i suoni dei passi non suonano durante la musica).

Quando si rimette SMB1:

1. Il byte $A5 è ancora lì (Tennis non lo ha toccato)
2. Le cifre dell'high score sono ancora 0 (valide)
3. Il world byte vale ora 8+ (incrementato dai passi di Tennis)
4. SMB1 rileva un warm start → preserva il world byte corrotto
5. Mantenere A + Start → world 9-1, world A-1, world 36-1, ecc.

Perché bisogna avviare Mario prima di Tennis

Una sfumatura: bisogna prima avviare SMB1, poi Tennis, poi di nuovo SMB1. Se iniziassi direttamente con Tennis, il byte $A5 non sarebbe mai scritto (Tennis non scrive $A5), quindi il rilevamento warm start fallirebbe e la RAM sarebbe cancellata.

Come SMB1 archivia i suoi livelli in 40KB

Nintendo R&D4 ha dovuto risolvere un problema semplice in apparenza: rappresentare livelli che scrollano orizzontalmente con tile, nemici, oggetti, il tutto in un budget ROM ultra-stretto.

La soluzione è una separazione in due livelli di dati completamente indipendenti:

Il tile layout (la mappa del livello)

Ogni livello è definito da un puntatore verso una struttura di tile compressa in ROM. La compressione è rudimentale ma geniale: un byte "controllo" seguito da 1-3 byte di dati.

Il formato tile utilizza un sistema di run (simile all'RLE):

; Formato tile SMB1 (semplificato)
; Ogni "comando" è un byte controllo:
;
; $00-$7F : posiziona una tile, avanza di 1 colonna
; $80-$BF : posiziona una tile ripetuta N volte (N = byte - $80 + 1)
; $C0-$FF : comando speciale (fine riga, salto, cambio palette)

Esempio: per disegnare 3 mattoni consecutivi:
  $82 $01    ; ripete la tile $01 (brick) 3 volte

Ogni livello contiene 13 righe di 16 colonne di tile (13×16 = 208 tile visibili). Ma il formato compressato permette di scendere molto più in basso -- per esempio, il cielo e le colonne vuote non occupano quasi spazio.

Il loop di rendering in 6502:

; Decompressione tile - loop principale
; Ingresso: puntatore tile_data in $XX
; Uscita: tilemap livello nella RAM PPU

DecompressTile:
  lda (tile_ptr),y      ; leggi byte controllo
  iny
  cmp #$80
  bcc SingleTile        ; $00-$7F: tile singola
  cmp #$C0
  bcc RunLength         ; $80-$BF: run-length
  jmp SpecialCommand    ; $C0-$FF: comando speciale

SingleTile:
  sta PPU_DATA          ; scrivi la tile direttamente
  jmp Next

RunLength:
  sec
  sbc #$7E              ; N = control - $7E
  tax
  lda (tile_ptr),y      ; leggi la tile da ripetere
  iny
: sta PPU_DATA
  dex
  bne :-
  jmp Next

Il sprite layout (nemici e oggetti)

In parallelo, i nemici e gli oggetti (blocchi ?, tubi, goombas, koopas) sono archiviati in una struttura completamente separata. Ogni spawn è definito da 2 byte:

; Formato sprite SMB1
; Byte 0: posizione X (in colonne)
; Byte 1: tipo sprite + bit pagina Y
; Y è derivato dall'indice nella sequenza

Una sequenza di sprite:
  $01 $4B    ; goomba alla colonna 1
  $09 $4B    ; goomba alla colonna 9
  $10 $61    ; blocco ? alla colonna 16 (contiene moneta)
  $15 $54    ; koopa verde alla colonna 21
  $FF        ; fine sequenza

Ogni livello può fare riferimento fino a 5 pagine di sprite diverse (beh, 5 "schermate" da 16 colonne), ma in pratica la maggior parte dei livelli ne usa solo 2-3.

La tabella dei puntatori

Il genio del design è la tabella dei puntatori. Ogni livello è archiviato come una coppia di indirizzi ROM:

// Struttura interna (semplificata) della World Map
struct LevelPointer {
    uint16_t tile_ptr;   // Indirizzo ROM dei dati tile
    uint16_t sprite_ptr; // Indirizzo ROM dei dati sprite
};

// 4 tabelle separate, una per AreaType:
// 0 = Water, 1 = Overworld, 2 = Underground, 3 = Castle
LevelPointer level_table[4][128];

128 voci per tabella. 4 tipi di zona. 512 combinazioni possibili, ma solo una frazione è usata dal gioco ufficiale. Il resto è RAM non inizializzata o dati che vengono interpretati come puntatori.

Quando il gioco carica un livello, fa questo:

; Caricamento di un livello
; A = AreaType (0-3), X = LevelID (0-127)

LoadLevel:
  sta AREA_TYPE
  asl                  ; *2 per offset nella tabella 16-bit
  tax
  lda LevelTable_TilePtr, x
  sta TILE_PTR
  lda LevelTable_TilePtr+1, x
  sta TILE_PTR+1       ; puntatore verso le tile
  lda LevelTable_SpritePtr, x
  sta SPRITE_PTR
  lda LevelTable_SpritePtr+1, x
  sta SPRITE_PTR+1     ; puntatore verso gli sprite
  jsr DecompressTiles

Nessuna validazione. Nessuna verifica che il puntatore sia valido. Il gioco legge l'indirizzo nella tabella e decomprime ciò che si trova a quell'indirizzo, punto.

I 34 livelli unici e il sistema di ID a 7 bit

SMB1 non ha 32 livelli, ma 34 livelli unici. Molti livelli sono duplicati (5-3 = 1-3 ma con dei Bullet Bills) contrassegnati da una flag "hard mode". I veri livelli unici:

• Acqua (Tipo 0): 3 livelli (2-2, 7-2, zona bonus 5-2/6-2)
• Overworld (Tipo 1): 22 livelli (inclusi i 2 locali nuvola bonus)
• Underground (Tipo 2): 3 livelli (inclusi i locali bonus sotterranei)
• Castello (Tipo 3): 6 livelli
• + 1 local cutscene (prima dei livelli sotterranei/acqua)
• + 1 warp zone di 4-2

Ogni livello ha un ID su 7 bit. I 5 bit meno significativi = numero nel sottogruppo, i 2 bit più significativi = tipo di zona:

; Codifica 7-bit del Level ID
; Bit 6-5: Tipo (00=Water, 01=Overworld, 10=Underground, 11=Castle)
; Bit 4-0: Numero nel sottogruppo
;
; Water ID       : $00-$02  (tipi 00, numeri 0-2)
; Overworld ID   : $20-$35  (tipi 01, numeri 0-21)
; Underground ID : $40-$42  (tipi 10, numeri 0-2)
; Castle ID      : $60-$65  (tipi 11, numeri 0-5)
;
; ID $25 = %0100101 → tipo 01 (Overworld), numero 5 → 1-1
; ID $23 = %0100011 → tipo 01 (Overworld), numero 3 → 6-2

128 ID possibili ($00-$7F), solo 34 assegnati a veri livelli. Gli ID inutilizzati puntano verso qualsiasi cosa.

Le tabelle dei puntatori: due liste, due ordini

I puntatori tile e sprite non sono archiviati nello stesso ordine. Il codice usa due liste 16-bit separate (high byte / low byte in due tabelle distinte):

Ordine dei puntatori sprite:
  Indice 0-5   : Castello (6 livelli)
  Indice 6-27  : Overworld (22 livelli)
  Indice 28-30 : Underground (3 livelli)
  Indice 31-33 : Acqua (3 livelli)

Ordine dei puntatori tile:
  Indice 0-2   : Acqua (3 livelli)
  Indice 3-24  : Overworld (22 livelli)
  Indice 25-27 : Underground (3 livelli)
  Indice 28-33 : Castello (6 livelli)

Perché ordini diversi? Nessuna ragione tecnica -- probabilmente è così che i dati sono stati organizzati durante lo sviluppo. Ma crea una conseguenza affascinante: quando un ID livello non è valido, i puntatori tile e sprite caricano livelli diversi, creando dei Frankenstein levels.

Per navigare tra queste due liste, il gioco usa delle piccole tabelle di offset (come un indice):

; Tabelle di offset per tipo (Water, Overworld, Underground, Castle)
; Ogni voce = indice di inizio nella lista corrispondente

SpriteOffsetTable:
  .byte $1F, $06, $1C, $00    ; Water=31, Overworld=6, Underground=28, Castle=0

TileOffsetTable:
  .byte $00, $03, $19, $1C    ; Water=0, Overworld=3, Underground=25, Castle=28

Per caricare il livello 6-2 (ID $23, Overworld numero 3):

; 1. Tipo = 01 (Overworld) → indice nella tabella di offset = 1
; 2. Sprite offset = SpriteOffsetTable[1] = 6
;    Indice finale = 6 + 3 (numero livello) = 9 → 10° puntatore sprite
; 3. Tile offset = TileOffsetTable[1] = 3
;    Indice finale = 3 + 3 = 6 → 7° puntatore tile
; 4. Risultato: puntatore tile $A619 + puntatore sprite $9ED0 = 6-2 ✓

Ora, cosa succede con un ID non valido come $43 (Underground numero 3, che non esiste)?

; ID $43, Tipo = 10 (Underground), numero = 3
; Sprite offset = SpriteOffsetTable[2] = $1C = 28
;   Indice = 28 + 3 = 31 → 32° puntatore sprite = acqua bonus 5-2 !
; Tile offset = TileOffsetTable[2] = $19 = 25
;   Indice = 25 + 3 = 28 → 29° puntatore tile = 1-4 (Castle) !
;
; Risultato: un livello sotterraneo con le tile di 1-4
; e i Bloopers della zona acqua di 5-2. Un vero Frankenstein.

La world index table: perché world 9 fa overflow

C'è una tabella ROM di 8 byte che dà l'indice del primo livello di ogni mondo (1-8). E subito dopo, la tabella dei 36 Level ID di tutti i livelli nell'ordine di gioco.

; WorldIndexTable (8 byte)
  .byte 0, 5, 10, 15, 20, 25, 28, 33
;   -> Il Mondo 1 inizia al livello 0
;   -> Il Mondo 2 inizia al livello 5
;   -> Il Mondo 8 inizia al livello 33

; LevelIDTable (36 byte)
  .byte $25, $28, $29, $26, $24, ... ; i 36 Level ID

Quando si prova a caricare world 9, il gioco legge il 9° byte di WorldIndexTable... che non esiste. Fa overflow di 1 byte in LevelIDTable, legge il valore $25, poi usa $25 come indice in LevelIDTable (37° voce) -- il che fa overflow di 2 byte in SpriteOffsetTable, e legge il valore 6.

; World 9:
;   1. WorldIndexTable[8] (overflow) → legge $25 in LevelIDTable
;   2. LevelIDTable[37] (overflow) → legge il 2° byte di SpriteOffsetTable = 6
;   3. ID = 6 → livello Water numero 6 (che non esiste)
;   4. Tile pointer = puntatore water numero 6 = tile di 6-2
;   5. Sprite pointer = indice 31+6 = 37 > 33 → puntatore non valido
;   6. Risultato: 6-2 sott'acqua con sprite corrotti
;      → world 9-1 !

Per world G (16), l'overflow va ancora più in là e cade sul Level ID $01, che è il livello cutscene che precede 1-2:

; World G (16):
;   WorldIndexTable[15] → legge $01 in LevelIDTable
;   LevelIDTable[1] = $29 (cutscene 1-2)
;   → world G-1 = la cutscene di ingresso di 1-2

Perché i glitch worlds esistono

Il gioco ha 32 livalli "legittimi" (8 mondi × 4 livelli). Ma la tabella dei puntatori ha 128 voci per tipo di zona. Le voci oltre il livello 32 contengono ciò che si trova in ROM a quegli indirizzi -- a volte un altro livello, a volte dati sonori, a volte RAM, a volte qualsiasi cosa.

Level ID $01 + AreaType 0 = Minus World

Il più famoso tra i glitch worlds. Il Level ID $01 in AreaType 0 (acqua) punta verso:

• Tile pointer: $AE45 → la zona sottomarina di 2-2/7-2
• Sprite pointer: $A171 → gli sprite di 2-2/7-2

Il risultato: un livello acqua che sembra 2-2, ma che si ripete all'infinito perché l'asta non esiste. Nessuna fine livello, nessuna uscita.

È il livello 36-1 (o 36-1 nel mondo $-1).

; Perché manca l'asta nel Minus World:
; Gli sprite di 2-2/7-2 ($A171) non hanno un'asta
; nella loro sequenza. Il gioco cerca lo sprite $FD (flagpole)
; ma non lo trova mai → loop infinito
;
; Il gioco continua a generare il livello all'infinito
; finché il timer raggiunge zero.

I puntatori che puntano verso la RAM

Quando il tile pointer o lo sprite pointer punta verso un indirizzo in RAM ($00-$7F) piuttosto che in ROM, il gioco cerca di interpretare i costanti cambiamenti della RAM come tile:

; Esempio: Level ID $03 in Water
; Tile Pointer: $A46B (3-3 - valido)
; Sprite Pointer: $009D (punta verso la RAM pagina zero!)
;
; La RAM pagina zero contiene i registri del gioco,
; la posizione di Mario, lo stato dei contatori...
; Il gioco decomprime tutto questo come una sequenza di sprite,
; e il risultato è un livello con nemici
; che in realtà sono valori di registro.

Quando la pagina zero cambia (perché Mario si muove, il timer scorre, ecc.), gli "sprite" del livello cambiano anche. Ecco perché certi glitch worlds hanno nemici che lampeggiano e si trasformano costantemente.

Level ID $36: il livello vuoto (Overworld)

Level ID $36 in Overworld:

• Tile pointer: $AC35 (1-2)
• Sprite pointer: $A0D8 (1-2)

Risultato: niente. Il gioco carica il livello ma è contrassegnato "senza livello" nel catalogo di RGMechEx. Le tile potrebbero essere valide ma gli sprite puntano verso un posto che produce un livello vuoto o non funzionante.

Level ID $1D (Castello): il campione dei crash

Level ID $1D in Castello:

• Tile pointer: $A210 (4-4)
• Sprite pointer: $7EA0 (RAM!)

Sprite pointer in RAM = sprite indefiniti. Il gioco cerca di visualizzare una Spiny ball o un Bullet Bill blaster nella prima riga di tile. Causo un crash immediato.

; Quando lo sprite pointer punta verso la RAM,
; il gioco decomprime byte che cambiano costantemente
; come istruzioni "spawn". Il risultato:
; - Apparizione di oggetti inesistenti (valore indefinito)
; - Crash PPU quando lo sprite NES cerca di visualizzare una tile non valida
; - Freeze completo della console

I 256 glitch worlds catalogati

RGMechEx ha scritto uno script che genera le mappe di tutti i livelli, per i 4 tipi di zona, e i 128 ID ciascuno.

Il contatore dei mondi è a 8 bit (0-255). I mondi 1-8 sono legittimi. Restano 248 glitch worlds potenziali. Ogni glitch world corrisponde al primo livello di quel mondo, e il suo Level ID è calcolato dal meccanismo di overflow della WorldIndexTable.

Dei 128 ID possibili, solo 68 sono "primo livello" di un mondo (accessibili tramite il numero del glitch world). I restanti 60 sono livelli 2+ o inaccessibili.

Tipo	ID unici giocabili	ID che crashano	ID vuoti
Water (0)	~20	~60	~48
Overworld (1)	~30	~55	~43
Underground (2)	~15	~65	~48
Castle (3)	~25	~58	~45

Molti ID portano allo stesso livello a causa dei puntatori che cadono sugli stessi indirizzi ROM. Il Level ID $28 (Overworld) per esempio -- tile pointer $A7CD (2-1) -- appare in 38 glitch worlds diversi, perché il suo sprite pointer $9F51 punta verso una zona della ROM che è usata come padding/dati sonori riutilizzato da molti ID.

I 6 glitch levels davvero unici

Tra i 19 ID di glitch level accessibili, solo 6 non crashano immediatamente al caricamento:

World	Level ID	Descrizione
E-1 (224)	$50	Un solo blocco ? sopra un baratro. Mario muore istantaneamente.
W	$57	Mario spawna bloccato, incapace di muoversi.
42 (133)	$50	Tunnel nuvola che intrappola Mario se va troppo avanti.
62 (131, 240)	$4D	Castello ghiacciato: Mario spawna in alto, non può cadere → bloccato.
127	$4B	Tunnel sotterraneo, ma crasha se si va troppo avanti.
137	$4B	Attiva lo scorrimento automatico delle cutscene. Mario incontra un unico blocco mattoni che lo blocca per sempre.

Sei glitch worlds su 248 che producono qualcosa di davvero nuovo. Il resto sono livelli normali con il tipo di zona sbagliato, o schermate nere.

Il formato dei livelli nel dettaglio

Al via sul formato esatto dei dati di livello, per capire perché i glitch levels reggono (o no).

L'header livello: 2 byte, 6 proprietà

Ogni livello inizia con un header di 2 byte che controlla 6 proprietà:

; Byte 0: timer + Y start + modificatore
;   Bit 7-6: timer (00=invariato, 01=200, 10=300, 11=400)
;   Bit 5-3: Y start Mario (111/110 = autowalk)
;   Bit 2-0: modificatore tipo livello
;              000=default, 001=onde, 002=muro mattoni,
;              011=fondo acqua, 100=notte, 101=neve,
;              110=neve notte, 111=notte grigia

; Byte 1: piattaforma + sfondo + modello pavimento
;   Bit 7-6: piattaforma speciale (00=albero, 01=fungo,
;                                 10=Bullet Bill, 11=nuvola)
;   Bit 5-4: sfondo (00=nessuno, 01=nuvole,
;                     10=montagne, 11=recinzioni)
;   Bit 3-0: modello pavimento iniziale (0-15)

Il modificatore tipo controlla variazioni visive: le onde in cima ai livelli acqua, il fondo mattoni di 8-3, la palette notte di 4-3, la neve di 6-2, ecc.

Gli oggetti tile: 2 byte, flag Next Screen, coda 3 slot

Dopo lheader viene una lista di oggetti tile, ogni oggetto fa 2 byte. Il byte $FD segna la fine della lista.

; Formato oggetto tile (16 bit):
; Byte 0:
;   Bit 7-4: posizione X (colonna 0-15)
;   Bit 3-0: posizione Y
;     Y=0-11  : posizione Y normale
;     Y=12    : oggetti speciali (buchi, ponti, corda, blocchi ?)
;     Y=13    : salto schermata / oggetti speciali 2
;     Y=14    : cambio modificatore/paesaggio/pavimento
;     Y=15    : oggetti speciali 3 (castello, scale, tubo grosso)

; Byte 1:
;   Bit  7   : FLAG NEXT SCREEN
;   Bit 6-4  : tipo oggetto (0-7)
;   Bit 3-0  : larghezza/altezza / sottotipo

Quando il bit "next screen" è impostato, la colonna di lavoro corrente viene incrementata di 1. Questo permette di posizionare oggetti oltre le prime 16 colonne. Gli oggetti devono essere elencati in ordine (da sinistra a destra) perché il li carica sequenzialmente:

; La routine di caricamento ha DUE fasi per colonna:
; Fase 1: cercare i nuovi oggetti che iniziano su questa colonna
;          e aggiungerli alla coda (queue)
; Fase 2: processare ogni oggetto nella coda disegnando le tile,
;          e rimuovere quelli che finiscono su questa colonna

La coda ha esattamente 3 slot. Conseguenza diretta: non si possono avere più di 3 oggetti che iniziano sulla stessa colonna. Se la coda è piena, il 4° oggetto viene ignorato e non sarà mai caricato.

Ecco perché i livelli ben progettati evitano di impilare troppi oggetti. Esempio in 1-2: la colonna con il blocco 1up nel soffitto + i mattoni accanto sono divisi in due oggetti distinti per rispettare il limite di 3.

Posizione Y speciale: 12, 13, 14, 15

Quando Y=12, l'oggetto non ha una posizione Y (è hardcodata per tipo):

; Y=12: oggetti senza posizione Y
;   Tipo 0: buco (rimuove il pavimento)
;   Tipo 1: corda piattaforma mobile
;   Tipi 2-4: ponti a Y fissa
;   Tipo 5: buco con acqua/lava
;   Tipi 6-7: file di blocchi ?

Quando Y=13, due sottogruppi. Se il bit 6 del byte 1 è a 1:

; Y=13, bit6=1: oggetti speciali
;   0 = L-pipe (cutscene), 1 = flagpole, 2-3 = ponte/ascia/martello (fine castello)
;   4 = stop screen, 5 = nemici casuali, 6 = loop level, 7+ = crash possibile

Se bit6=0, i 5 bit meno significativi codificano un salto schermata (saltare direttamente a uno schermo N, senza passare per la flag next screen una per una).

Quando Y=14: stesso principio con bit6=1 per cambiare il modificatore tipo, bit6=0 per cambiare lo sfondo + modello pavimento.

I floor patterns: 16 motivi di pavimento

Il pavimento dei livelli non è fatto di oggetti singolari. SMB1 usa dei floor patterns, un motivo di sfondo che si applica a tutte le colonne fino al prossimo cambio:

; Floor patterns (4 bit = 16 possibilità)
;   0 = vuoto totale
;   1 = pavimento 2 tile alto
;   2 = pavimento 1 tile alto
;   3 = pavimento + fondo
;   4 = pavimento + fondo 2
;   5 = pavimento 1/2 tile
;   6 = 3/4 pavimento
;   ... fino a 15 = riempito totale (pavimento + soffitto)

Ecco perché i buchi sono oggetti: override il floor pattern su una colonna specifica, senza dover cambiare il pattern per tutto il resto.

Il limite dei 256 byte e il repeat

Tutti i dati tile di un livello stanno in 256 byte massimo. Il registro Y del 6502 è usato come indice, ed è a 8 bit. Se il gioco arriva alla fine dei dati senza trovare il byte $FD, ricomincia da capo e ripete i 256 byte all'infinito:

; Indice Y = 8 bit → max 256 byte di dati tile
; Se Y overflow (255 → 0) senza incontrare $FD → repeat
; Stessa cosa per gli sprite, ma gli oggetti pipe (3 byte)
; spostano la parità dell'indice a ogni caricamento.

Certi glitch levels sfruttano questo repeat per generare livelli che durano "all'infinito".

Il sistema di sprite: 2 byte + transizioni pipe

Gli sprite seguono un formato simile, ma senza header e con alcune differenze chiave. Il byte $FF segna la fine della lista.

; Formato sprite (2 byte):
; Byte 0: posizione X (colonna)
; Byte 1:
;   Bit 7: FLAG NEXT SCREEN
;   Bit 6-0: tipo sprite
;       Alcuni tipi includono: goomba, koopa, Blooper,
;       Bullet Bill, Lakitu, Spiny, piattaforme,
;       comando warp zone, toad/principessa,
;       comandi di spawn di gruppi di nemici

Il bit meno significativo del byte 1 è la flag hard level: se impostato a 1, lo sprite appare solo nei livelli ≥ 5-3. È così che vengono creati i livelli "hard mode".

Posizione Y 15 = salto schermata (identica alle tile). Posizione Y 14 = transizione pipe (3 byte):

; Sprite Y=14: transizione pipe/vite (3 byte!)
;   Byte 0: posizione X
;   Byte 1: bit 6-0 = Level ID 7-bit (destinazione)
;   Byte 2: bit 4-0 = schermo di destinazione
;            bit 7-5 = mondo dove questa transizione è valida
;
; Perché un mondo? Le stanze bonus vengono riutilizzate tra i mondi.
; Esempio: la stanza bonus di 1-1 è usata anche da 2-1 e 7-1.
; Questa stanza ha 3 transizioni, una per mondo, perché Mario
; riappariva nel posto giusto.

Gli sprite non hanno un sistema di coda. L'unica limite è che non possono esserci più di 4 sprite caricati simultaneamente nella zona di spawn (appena fuori schermo a destra). Oltre, gli sprite vengono ignorati.

Come accedere ai glitch worlds

Ci sono due metodi principali.

Il metodo classico: il wall clip

Il wall clip (passaggio attraverso i muri) permette di uscire dal livello normale e camminare fino alla warp zone nascosta. Manipolando il contatore dei mondi tramite la RAM, si può caricare qualsiasi Level ID.

La tecnica:

1. World 1-2: andare nel tubo finale nascosto
2. Fare il wall clip sul muro di destra
3. Camminare nel vuoto fino alla zona warp
4. Il gioco interpreta i valori come mondi

Ma questo metodo dà accesso solo a una piccola parte dei glitch worlds.

Il metodo estremo: NES Tennis cart swap

Vedi la sezione "Il warm start" sopra per il dettaglio completo. In sintesi: il contatore dei passi di Tennis scrive sullo stesso byte RAM del mondo di partenza di SMB1, e il rilevamento warm start preserva quel valore.

L'angolo dei hacker: il codice per esplorare tutto

Se vuoi esplorare tutti i glitch tu stesso in un emulatore, puoi modificare il Level ID direttamente:

; Patch per FCEUX / Mesen:
; Indirizzo RAM $075F = Level ID attuale
; Indirizzo RAM $0760 = Area Type (0=Water, 1=Overworld, 2=Underground, 3=Castle)

; Esempio: caricare il Level 57 (0x39) in Overworld
; Nell'emulatore, aprire il traceur memoria e scrivere:
; $075F = 0x39
; $0760 = 0x01
; Poi entrare in un tubo di warp o morire e ricominciare
; → Il gioco carica il livello ID $39 in Overworld

RGMechEx ha pubblicato la lista completa dei 128 livelli × 4 tipi con mappe generate automaticamente su rgmechex.com. Ogni voce mostra il tile pointer, lo sprite pointer, e una mappa visiva del livello.

I livelli più assurdi

Level ID $1F (Water): 15 glitch worlds in uno

Il tile pointer $A302 (3-4) combinato allo sprite pointer $02A0 dà 15 glitch worlds diversi (D-1, J-1, Y-1, Z-1, 55-1, 73-1...). Spiegazione: lo sprite pointer punta verso una zona della ROM che contiene dati sufficientemente vicini a sprite validi per produrre risultati giocabili, ma la combinazione delle tile del castello 3-4 con sprite di overworld crea un rendering assurdo.

Level ID $28 (Overworld): 38 glitch worlds = record

Il record assoluto. 38 voci di glitch world puntano verso lo stesso livello (tile di 2-1 + sprite $9F51). Perché? Perché lo sprite pointer $9F51 cade in una zona della ROM che è usata come padding/dati sonori riutilizzato da molti ID.

Level ID $49 (Underground): il livello FDS

Tile pointer $76AE + sprite pointer $1C9D. Il tile pointer punta verso la zona della ROM riservata alla versione Famicom Disk System. Risultato: un livello con tile che non esistono nella cartuccia standard. È il livello che fa apparire il livello 52-1 e 196-1.

Level ID $00-$02: i veri livelli bonus

Questi ID sono usati da sotto-livelli legittimi del gioco:

• $00: zona sottomarina di 5-2/6-2 (usato da H-1, 39-1)
• $01: l'acqua di 2-2/7-2 (il Minus World, 36-1)
• $02: sotto-livello di 8-4 (136-1, 151-1, 215-1)

La differenza tra un livello "bonus" accessibile normalmente e un glitch world è che le warp zone verificano il mondo corrente:

; Verifica warp zone (semplificata)
; Il gioco verifica che il mondo target sia tra 1 e 8
CheckWarp:
  lda TARGET_WORLD
  cmp #1
  bcc InvalidWarp       ; < 1 → rifiutato
  cmp #9
  bcs InvalidWarp       ; > 8 → rifiutato
  ; mondo valido solo tra 1 e 8
  jmp DoWarp

I glitch worlds con numeri > 8 o 0 non possono essere raggiunti da tubi normali. Serve il wall clip o il cart swap.

Perché certi livelli crashano: le jump table

Quando il gioco carica un oggetto tile, usa il suo tipo come indice in una jump table:

; Jump table degli oggetti tile standard (tipi 0-11)
JumpTable_TileObjects:
  .word Obj_Special       ; tipo 0: blocco ?, nascosto, flagpole...
  .word Obj_Platform      ; tipo 1: piattaforma speciale
  .word Obj_BrickRow      ; tipo 2: riga di mattoni
  .word Obj_BlockRow      ; tipo 3: riga di blocchi
  .word Obj_CoinRow       ; tipo 4: riga di monete
  .word Obj_BrickCol      ; tipo 5: colonna di mattoni
  .word Obj_BlockCol      ; tipo 6: colonna di blocchi
  .word Obj_Pipe          ; tipo 7: tubo
  .word Obj_8             ; tipo 8
  .word Obj_9             ; tipo 9
  .word Obj_10            ; tipo 10
  .word Obj_11            ; tipo 11

Se un oggetto ha un tipo non valido (≥12), il gioco salta a un puntatore che non esiste in questa tabella. 4 risultati possibili:

1. Puntatore valido → l'oggetto si carica normalmente
2. Puntatore verso un'altra jump table (sovrapposizione) → appare un oggetto diverso. Esempio: tipo 12 punta alla tabella Y=13, che dà un L-pipe.
3. Puntatore verso codice eseguibile → esecuzione di codice casuale (crash probabile)
4. Placeholder esplicito (NOP) → l'oggetto non fa nulla (certi sprite sono così, producendo nemici che volano sul posto senza muoversi)

Il glitch level ID $58 (il tunnel che crasha): il suo sprite pointer punta verso una regione di memoria che non esiste su NES senza mapper ROM. Il gioco cerca di caricare lo stesso Koopa 5 volte per frame alla posizione (0,0), il che satura la PPU e provoca un freeze.

; Perché ID $58 crasha:
; Sprite pointer → indirizzo non valido (fuori spazio NES standard)
; → Il gioco legge byte indeterminati come tipi sprite
; → Il Koopa $00 (tipo non valido senza handler) fa un loop con chiamata ricorsiva
; → Stack overflow 6502 → freeze

Il paradosso pipe warp

Ricordati la verifica target_world BETWEEN 1 AND 8. Anche se trovi un tubo in un glitch world, il gioco verifica che il mondo di destinazione sia tra 1 e 8. I glitch worlds hanno numeri > 8 (36-1, 255-1...), quindi la warp fallisce.

È anche per questo che il Minus World non ha fine: l'asta non è presente negli sprite, e i tubi non portano da nessuna parte.

Il trucco degli 5 oggetti in una colonna

Esiste un edge case che permette di superare il limite di 3 oggetti per colonna. Quando la coda si blocca (slot pieni + oggetto successivo con flag next screen mancante), il gioco "pre-elabora" la colonna corrente in loop fino a trovare un oggetto con flag next screen. Durante ogni pre-elaborazione:

; Durante la pre-elaborazione della colonna:
; 1. Gli oggetti nella coda vedono la loro larghezza rimanente
;    decrementata ad ogni "falsa avanzata" di colonna
; 2. Se un oggetto raggiunge larghezza=0, esce dalla coda
; 3. Uno slot liberato può essere riempito da un nuovo oggetto
;    aggiunto nella stessa colonna

; Risultato: fino a 5 oggetti possono essere processati sulla stessa colonna.
; Tecnica: posizionare 2 oggetti che attraversano il confine schermo
; (slot 1 e 2), 1 oggetto dummy con X < precedente (blocca la coda),
; poi 3 oggetti a X=0 dello schermo successivo (di cui uno con flag next screen).

Questo è ciò che si chiama "queue skip" ed è usato da certi romhackers per creare livelli più densi di quanto il formato permetta normalmente.

Le differenze tra le versioni

Famicom Disk System

La versione FDS di SMB1 ha una memory map diversa. Tutti i puntatori di livello sono spostati, ma i dati sono gli stessi. Ciò che cambia: gli indici dei glitch worlds sono completamente diversi:

FDS World 36 → Level ID $09 (versione acqua di 5-3)
  → L'asta è presente! Si può finire il livello.
  → Poi: $27 (7-3 normale) → $44 (4-4 underground)
  → $44 è finibile → l'ascia funziona → fine del gioco!
  
Il Minus World FDS è quindi un "bonus world" che può portare
al completamento del gioco, a differenza della versione NES.

Il mio livello FDS preferito: ID $5F, una versione sotterranea della seconda metà di 3-3 in tunnel basso (peccato che sia un autoscroller).

The Lost Levels (Super Mario Bros. 2 giapponese)

Lost Levels cambia molte cose:

1. Ordine identico tile/sprite: niente più Frankenstein levels (tile e sprite caricano lo stesso livello anche con un ID non valido)
2. Una sola tabella puntatori 16-bit invece di due tabelle separate high/low
3. 4 file disco: la ROM è stata suddivisa per il FDS:
   • File 1: mondi 1-4
   • File 2: mondi 5-8
   • File 3: world 9 + sound engine
   • File 4: mondi A-D (tabella puntatori completamente diversa)
4. Stesso Level ID = 4 livelli possibili a seconda del file caricato
5. Niente più glitch Tennis: l'opzione continue (continuare nello stesso mondo dopo game over) rende il warm start inutile, e il gioco resetta immediatamente se world > 9
6. Nuovi oggetti: fungo velenoso, blocco invisibile, fiore di fuoco invisibile, tubi capovolti, vento -- ma inseriti nel mezzo delle liste esistenti → incompatibilità retroattiva con SMB1
7. Piranha Plants sempre rosse dopo world 4, trampolini verdi solo nei mondi 2/B/3/C/7

Super Mario All-Stars (SNES)

Porting diretto con le stesse routine 6502 (il SNES esegue il codice NES in modalità compatibile):

• Warp zone corretta: niente più Minus World (entrare nel tubo sinistro prima del testo porta al mondo giusto)
• Crash: la maggior parte dei glitch levels crashano (tranne ID $6A e 9-1)
• Oggetti castello aggiunti: resi più unici
• Ma: il 4-2 wrong warp funziona ancora (non corretto!)

Il 4-2 wrong warp: un bug di posizionamento oggetti

In 4-2, ci sono due oggetti di transizione pipe: la vite (warp zone) e il tubo (stanza coin cash). Il primo oggetto di transizione (quello della vite) è posizionato ben prima che la vite appaia sullo schermo. Il secondo (il tubo) è posizionato troppo tardi nel livello.

; Timing delle transizioni in 4-2:
; Oggetto transizione 1 (vite → warp zone): posizionato 3 schermate prima della vite
; Oggetto transizione 2 (tuyau → coin cash): posizionato 1 schermata dopo il tubo
;
; Normalmente il primo oggetto è disattivato prima che Mario
; raggiunga il tubo. Ma se Mario va veloce (o usa
; la scorciatoia del blocco B+destra), la transizione della vite
; è ancora attiva quando tocca il tubo!
; → Il gioco carica la warp zone invece del coin cash.
;
; Se l'oggetto fosse stato posizionato subito dopo la vite ma prima
; del tubo, il bug non esisterebbe.

I livelli a loop

Come funzionano i loop (8-4, 7-4)? Il livello ha dei checkpoints con numeri di schermo e posizioni Y hardcodati:

; Checkpoint: {schermo_numero, posizione_verticale}
; Se Mario passa questo checkpoint alla giusta altezza → il livello continua
; Altrimenti → warp indietro di 4 schermate (64 blocchi)
;
; Per fare un loop infinito: posizione_verticale = $F0
; (sotto il fondo dello schermo) → impossibile validare.
;
; I checkpoints sono semplici (una sola flag) tranne per world 7
; che usa tripletti (3 flag, bisogna fallirne almeno 1)
;
; Il warp indietro è brutale: offset di tile data impostato a un valore
; hardcodato, offset di sprite data rimesso a 0. I nemici presenti
; vengono scaricati istantaneamente → le firebars scompaiono.

Cambiare il formato, non il codice

Una delle lezioni più affascinanti di questa architettura è che gli sviluppatori di SMB1 sono riusciti a creare un sistema di livelli molto espressivo senza mai toccare il codice di rendering 6502. Tutta la variazione tra i livelli viene dai dati (puntatori, oggetti, sprite, floor patterns), non dal codice.

I 256 glitch worlds esistono perché le tabelle dei puntatori sono dimensionate per 128 voci × 4 tipi, e il gioco non valida mai i valori che legge. Quando un puntatore cade in RAM, il gioco interpreta i registri di Mario come tile. Quando un puntatore cade nei dati sonori, il gioco suona musica sotto forma di level design. E quando le jump table fanno overflow, il gioco esegue qualsiasi cosa fino al crash.

Cosa si può imparare da tutto questo

1. Separazione tile/sprite: indipendenza totale dei due livelli, con ordini di archiviazione diversi che creano Frankenstein levels unici
2. Compressione RLE + sistema di oggetti: i livelli non sono bitmap ma liste di oggetti posizionati, con floor patterns per il pavimento
3. Coda 3 slot: limite rigido dell'hardware (e del design del livello)
4. Nessuna validazione: il gioco si fida dei puntatori e delle jump table, il che produce o glitch giocabili o crash
5. 256 byte max: il limite del registro Y del 6502, che fa sì che i dati si ripetano se si va troppo avanti
6. Warm start / cold start: un sistema di "continuare" che ha aperto la porta al cart swap Tennis → Mario

Il più bello: tutto questo è codice 6502 che sta in 40KB. Nessun livello di astrazione, nessuna validazione degli accessi di memoria, nessun gestore eccezioni. Se il puntatore è marcio, il gioco crasha. E i crash li chiamiamo glitch worlds.

Le 3 cose da ricordare

1. I glitch worlds sono puntatori che cadono male -- Il gioco ha 128 ID × 4 tipi di zona, ma solo 34 livelli unici. Quando il world number è corrotto (da Tennis o wall clip), il gioco carica un puntatore progettato per un altro livello, e le 512 combinazioni possibili producono risultati imprevedibili.

2. Il Minus World è un bug di warp combinato a corruzione -- Il tubo sinistro in 1-2, se attivato prima che il testo appaia, carica world 36 (0x24). Questo world punta al Level ID $01 (acqua di 2-2), un livello senza asta. E come non c'è una transizione pipe per world 36, il livello si ripete all'infinito. L'assenza di verifica crea l'icona.

3. Tennis → Mario, 15 anni prima di OoT → Paper Mario -- La RAM della NES sopravvive a uno swap di cartuccia grazie ai condensatori e al sistema di warm start / cold start di SMB1. Il contatore dei passi di Tennis ( che incrementa un byte RAM suonando il suono dei passi) cade esattamente sull'indirizzo del world number. Bisogna che le cifre dell'high score rimangano a 0, che il byte $A5 sia intatto, e che il gioco rilevi un warm start -- una coincidenza perfetta che ha funzionato solo con Tennis.

I video originali di Retro Game Mechanics Explained sono un lavoro immane -- il livello di dettaglio sulla disassembla 6502, le mappe automatiche di tutti i livelli, le spiegazioni del cart swap e del warm start. Se non hai visto la serie, guardala, è breve e ogni minuto è denso.

Il codice sorgente delle mappe è disponibile su rgmechex.com, e la disassembla completa di SMB1 è open source su tanti repository. 40 anni fa, dei programmatori giapponesi hanno scritto questo sistema di livelli in 6502 con zero test unitari e zero bug tracker, e continuiamo a imparare cose aprendo il loro codice oggi.

Einführung

Super Mario Bros. – das sind 40 Kilobyte ROM. Acht Welten, 32 Levels, Gegner, Musik, Power-ups, alles passt da rein.

Aber wenn du einen Emulator öffnest und die richtigen Bytes herumwurstelst, kannst du den Level 36-1 laden. Oder den 255-1. Oder in einer Welt landen, die komplett aus Bowser-Sprites und Rohren besteht, die nirgendwo hinführen.

Diese Glitch Worlds existieren aus einem einfachen Grund: Das Level-Speichersystem von SMB1 ist ein Meisterwerk der 8-Bit-Optimierung, und wenn man das Spiel zwingt, dort zu lesen, wo es nicht sollte, kommt man zu faszinierenden Ergebnissen.

Retro Game Mechanics Explained hat eine 4-teilige Videoserie darüber gemacht -- wir kompilieren das hier zu einem einzigen Deep Dive in den 6502-Code des meistverkauften Spiels seiner Zeit.

Der Warm Start: Warum die RAM von Tennis in SMB1 überlebt

Bevor wir über Level-Speicherung reden, müssen wir verstehen, wie SMB1 startet. Denn der Glitch des NES-Tennis-Kart-Tauschs basiert vollständig auf dem Warm-Start / Cold-Start-Erkennungssystem des Spiels.

Die 41 Bytes, die erhalten bleiben

Wenn SMB1 einen Cold Start erkennt (erstes Einschalten oder Power Off/On), löscht es die gesamte RAM. Aber wenn es einen Warm Start erkennt (Reset-Knopf, kein Stromausfall), bleibt ein Speicherbereich von 41 Bytes erhalten:

; Les 41 bytes préservés en RAM lors d'un warm start
; Adresses $075F-$0787
;
; $075F : byte de démarrage (world - 1)    [1 byte]
; $0760 : flag de sélection de monde (B button) [1 byte]
; $0761-$0762 : inutilisé                    [2 bytes]
; $0763-$0768 : timer (6 digits, 3 affichés) [6 bytes]
; $0769-$076E : coins Luigi                   [6 bytes]
; $076F-$0774 : coins Mario                   [6 bytes]
; $0775-$077A : score Luigi                   [6 bytes]
; $077B-$0780 : score Mario                   [6 bytes]
; $0781-$0786 : top score (6 digits, 1 caché) [6 bytes]
; $0787 : le byte magique $A5                 [1 byte]

Diese 41 Bytes dienen nur einer einzigen Funktion: Es soll dem Spieler ermöglichen, nach einem Game Over in derselben Welt weiterzuspielen. Wenn du in 6-3 stirbst, schreibt das Spiel die Welt 6 in den Start-Byte, und am Titelbildschirm, wenn du A + Start gedrückt hältst, startest du in 6-1.

Die doppelte Überprüfung des Warm Start

Wenn SMB1 hochfährt, überprüft es nicht nur ein Kriterium, sondern zwei:

CheckWarmStart:
  ; 1. Vérifier le byte magique $A5 à $0787
  lda $0787
  cmp #$A5
  bne ColdStart        ; pas $A5 → cold start

  ; 2. Vérifier les 6 digits du top score ($0781-$0786)
  ;    Chaque digit doit être entre 0 et 9
  ldx #0
CheckLoop:
  lda $0781,x
  cmp #$0A
  bcs ColdStart        ; digit >= 10 → cold start
  inx
  cpx #6
  bne CheckLoop

  ; Si les deux conditions passent → warm start
  ; La RAM n'est pas effacée, le monde de départ est préservé
  jmp WarmStartBoot

Warum eine doppelte Überprüfung? Weil das $A5-Byte zufällig vorhanden sein könnte (ein anderes Spiel, das diesen Wert lässt, oder der Ruhezustand des RAM-Chips). Indem man überprüft, dass die Top-Score-Ziffern gültig sind (0-9), stellt man sicher, dass die Daten konsistent sind.

Warum Tennis das einzige Spiel ist, das funktioniert

Wenn man SMB1 zum ersten Mal einlegt (Cold Start), tut das Spiel:

1. Löscht die gesamte RAM → Top Score = 0, World-Byte = 0
2. Schreibt $A5 an die Adresse $0787

Dann tauscht man auf Tennis, ohne die Konsole auszuschalten. Tennis:

• Löscht die RAM beim Start nicht (wenige NES-Spiele tun das)
• Schreibt nicht auf die Top-Score-Bytes → sie bleiben bei 0 (gültig)
• Berührt das $A5-Byte nicht → es bleibt vorhanden
• Verwendet die Adresse $075F für den Schrittzähler des Spielers

; Le footstep increment dans Tennis :
; À chaque pas du joueur sur le court, Tennis incrémente le byte à $075F.
; Ce même byte est utilisé par SMB1 comme "world number - 1".
;
; 0 pas  → world 0 → SMB1 = world 1
; 1-7 pas → world 1-7 → worlds normaux
; 8+ pas → world 8+ → glitch worlds !
;
; Le compteur ne s'incrémente que quand la musique s'arrête
; (les footstep sounds ne jouent pas pendant la musique).

Wenn man SMB1 wieder einlegt:

1. Das $A5-Byte ist immer noch da (Tennis hat es nicht berührt)
2. Die Top-Score-Ziffern sind immer noch 0 (gültig)
3. Das World-Byte hat jetzt 8+ (erhöht durch die Schritte von Tennis)
4. SMB1 erkennt einen Warm Start → bewahrt das korrupte World-Byte auf
5. A + Start gedrückt halten → World 9-1, World A-1, World 36-1, usw.

Warum man Mario vor Tennis starten muss

Eine Kleinigkeit: Man muss zuerst SMB1 starten, dann Tennis, dann wieder SMB1. Wenn man direkt mit Tennis beginnen würde, würde das $A5-Byte nie geschrieben (Tennis schreibt kein $A5), und die Warm-Start-Erkennung würde fehlschlagen und die RAM würde gelöscht.

Wie SMB1 seine Levels in 40KB speichert

Nintendo R&D4 musste ein scheinbar einfaches Problem lösen: Horizontale scrollende Levels mit Tiles, Gegnern und Items darstellen, und das alles in einem extrem knappen ROM-Budget.

Die Lösung: Eine Trennung in zwei komplett unabhängige Datenebenen:

Das Tile-Layout (die Levelkarte)

Jedes Level wird durch einen Zeiger auf eine komprimierte Tile-Struktur in der ROM definiert. Die Kompression ist simpel aber genial: Ein "Kontroll"-Byte gefolgt von 1-3 Datenbytes.

Das Tile-Format verwendet ein System von Runs (RLE-ähnlich):

; Format tile SMB1 (simplifié)
; Chaque "commande" est un byte contrôle :
;
; $00-$7F : pose une tile, avance d'1 colonne
; $80-$BF : pose une tile répétée N fois (N = byte - $80 + 1)
; $C0-$FF : commande spéciale (fin de ligne, saut, changement de palette)

Exemple : pour dessiner 3 briques consécutives :
  $82 $01    ; répète la tile $01 (brick) 3 fois

Jedes Level enthält 13 Zeilen mit 16 Spalten Tiles (13×16 = 208 sichtbare Tiles). Aber das komprimierte Format erlaubt es, viel weiter unten zu starten -- zum Beispiel der Himmel und leere Spalten nehmen fast keinen Platz ein.

Die Render-Schleife in 6502:

; Décompression tile - loop principale
; Entrée : pointeur tile_data en $XX
; Sortie : tilemap niveau dans la RAM PPU

DecompressTile:
  lda (tile_ptr),y      ; lire byte contrôle
  iny
  cmp #$80
  bcc SingleTile        ; $00-$7F : tile unique
  cmp #$C0
  bcc RunLength         ; $80-$BF : run-length
  jmp SpecialCommand    ; $C0-$FF : commande spéciale

SingleTile:
  sta PPU_DATA          ; écrire la tile directement
  jmp Next

RunLength:
  sec
  sbc #$7E              ; N = control - $7E
  tax
  lda (tile_ptr),y      ; lire la tile à répéter
  iny
: sta PPU_DATA
  dex
  bne :-
  jmp Next

Das Sprite-Layout (Gegner und Objekte)

Parallel dazu werden Gegner und Objekte (Blöcke ?, Rohren, Goombas, Koopas) in einer komplett separaten Struktur gespeichert. Jeder Spawn ist durch 2 Bytes definiert:

; Format sprite SMB1
; Byte 0 : position X (en colonnes)
; Byte 1 : type de sprite + bits de page Y
; Y est dérivé de l'index dans la séquence

Une séquence de sprites :
  $01 $4B    ; goomba à la colonne 1
  $09 $4B    ; goomba à la colonne 9
  $10 $61    ; bloc ? à la colonne 16 (contient pièce)
  $15 $54    ; koopa verte à la colonne 21
  $FF        ; fin de séquence

Jedes Level kann bis zu 5 verschiedene Sprite-Seiten referenzieren (also 5 "Screens" mit 16 Spalten), aber in der Praxis verwenden die meisten Level nur 2-3.

Die Zeigertabelle

Das Genie des Designs ist die Zeigertabelle. Jedes Level wird als Paar von ROM-Adressen gespeichert:

// Structure interne (simplifiée) du World Map
struct LevelPointer {
    uint16_t tile_ptr;   // Adresse ROM des données tiles
    uint16_t sprite_ptr; // Adresse ROM des données sprites
};

// 4 tables séparées, une par AreaType :
// 0 = Water, 1 = Overworld, 2 = Underground, 3 = Castle
LevelPointer level_table[4][128];

128 Einträge pro Tabelle. 4 Zonentypen. 512 mögliche Kombinationen, aber nur ein Bruchteil wird vom offiziellen Spiel genutzt. Der Rest ist nicht initialisierte RAM oder Daten, die als Zeiger interpretiert werden.

Wenn das Spiel ein Level lädt, macht es das:

; Chargement d'un niveau
; A = AreaType (0-3), X = LevelID (0-127)

LoadLevel:
  sta AREA_TYPE
  asl                  ; *2 pour offset dans table 16-bit
  tax
  lda LevelTable_TilePtr, x
  sta TILE_PTR
  lda LevelTable_TilePtr+1, x
  sta TILE_PTR+1       ; pointeur vers les tiles
  lda LevelTable_SpritePtr, x
  sta SPRITE_PTR
  lda LevelTable_SpritePtr+1, x
  sta SPRITE_PTR+1     ; pointeur vers les sprites
  jsr DecompressTiles

Keine Validierung. Keine Prüfung, ob der Zeiger gültig ist. Das Spiel liest die Adresse in der Tabelle und dekomprimiert, was sich an dieser Adresse befindet, Punkt.

Die 34 einzigartigen Levels und das 7-Bit-ID-System

SMB1 hat nicht 32 Levels, sondern 34 einzigartige Levels. Viele Levels sind Duplikate (5-3 = 1-3, aber mit Bullet Bills), die mit einem "Hard Mode"-Markierungs-Flag versehen sind. Die echten einzigartigen Levels:

• Wasser (Typ 0): 3 Levels (2-2, 7-2, Bonus-Zone 5-2/6-2)
• Overworld (Typ 1): 22 Levels (inklusive der 2 Wolken-Bonus-Räume)
• Underground (Typ 2): 3 Levels (inklusive der unterirdischen Bonusräume)
• Castle (Typ 3): 6 Levels
• + 1 Cutscene-Raum (vor den unterirdischen/Wasser-Levels)
• + 1 Warp-Zone von 4-2

Jedes Level hat eine ID auf 7 Bits. Die unteren 5 Bits = Nummer in der Untergruppe, die oberen 2 Bits = Zonentyp:

; Encodage 7-bit du Level ID
; Bits 6-5 : Type (00=Water, 01=Overworld, 10=Underground, 11=Castle)
; Bits 4-0 : Numéro dans le sous-groupe
;
; Water IDs      : $00-$02  (types 00, numéros 0-2)
; Overworld IDs  : $20-$35  (types 01, numéros 0-21)
; Underground IDs: $40-$42  (types 10, numéros 0-2)
; Castle IDs     : $60-$65  (types 11, numéros 0-5)
;
; ID $25 = %0100101 → type 01 (Overworld), numéro 5 → 1-1
; ID $23 = %0100011 → type 01 (Overworld), numéro 3 → 6-2

128 mögliche IDs ($00-$7F), nur 34 sind echten Levels zugewiesen. Die ungenutzten IDs zeigen auf irgendetwas.

Die Zeigertabellen: Zwei Listen, zwei Reihenfolgen

Die Tile- und Sprite-Zeiger werden nicht in derselben Reihenfolge gespeichert. Der Code verwendet zwei separate 16-Bit-Listen (High Byte / Low Byte in zwei unterschiedlichen Tabellen):

Ordre des pointeurs sprites :
  Index 0-5   : Castle (6 niveaux)
  Index 6-27  : Overworld (22 niveaux)
  Index 28-30 : Underground (3 niveaux)
  Index 31-33 : Water (3 niveaux)

Ordre des pointeurs tiles :
  Index 0-2   : Water (3 niveaux)
  Index 3-24  : Overworld (22 niveaux)
  Index 25-27 : Underground (3 niveaux)
  Index 28-33 : Castle (6 niveaux)

Warum unterschiedliche Reihenfolgen? Kein technischer Grund -- das war wahrscheinlich einfach so, wie die Daten während der Entwicklung organisiert wurden. Aber das erzeugt eine faszinierende Konsequenz: Wenn eine Level-ID ungültig ist, laden Tile- und Sprite-Zeiger unterschiedliche Levels und erzeugen so Frankenstein-Levels.

Um zwischen diesen beiden Listen zu navigieren, verwendet das Spiel kleine Offset-Tabellen (wie ein Inhaltsverzeichnis):

; Tables d'offset par type (Water, Overworld, Underground, Castle)
; Chaque entrée = index de début dans la liste correspondante

SpriteOffsetTable:
  .byte $1F, $06, $1C, $00    ; Water=31, Overworld=6, Underground=28, Castle=0

TileOffsetTable:
  .byte $00, $03, $19, $1C    ; Water=0, Overworld=3, Underground=25, Castle=28

Um Level 6-2 zu laden (ID $23, Overworld Nummer 3):

; 1. Type = 01 (Overworld) → index dans table d'offset = 1
; 2. Sprite offset = SpriteOffsetTable[1] = 6
;    Index final = 6 + 3 (numéro de niveau) = 9 → 10ème pointeur sprites
; 3. Tile offset = TileOffsetTable[1] = 3
;    Index final = 3 + 3 = 6 → 7ème pointeur tiles
; 4. Résultat : pointeur tiles $A619 + pointeur sprites $9ED0 = 6-2 ✓

Was passiert jetzt mit einer ungültigen ID wie $43 (Underground Nummer 3, die es nicht gibt)?

; ID $43, Type = 10 (Underground), numéro = 3
; Sprite offset = SpriteOffsetTable[2] = $1C = 28
;   Index = 28 + 3 = 31 → 32ème pointeur sprites = eau bonus 5-2 !
; Tile offset = TileOffsetTable[2] = $19 = 25
;   Index = 25 + 3 = 28 → 29ème pointeur tiles = 1-4 (Castle) !
;
; Résultat : un niveau souterrain avec les tiles de 1-4
; et les Bloopers de la zone eau de 5-2. Un vrai Frankenstein.

Die World-Index-Tabelle: Warum World 9 überläuft

Es gibt eine ROM-Tabelle mit 8 Bytes, die den Index des ersten Levels jeder Welt (1-8) angibt. Und direkt danach die Tabelle der 36 Level-IDs aller Levels in der Spielreihenfolge.

; WorldIndexTable (8 bytes)
  .byte 0, 5, 10, 15, 20, 25, 28, 33
;   -> Monde 1 commence au niveau 0
;   -> Monde 2 commence au niveau 5
;   -> Monde 8 commence au niveau 33

; LevelIDTable (36 bytes)
  .byte $25, $28, $29, $26, $24, ... ; les 36 Level IDs

Wenn man versucht, World 9 zu laden, liest das Spiel das 9. Byte der WorldIndexTable... das nicht existiert. Es überläuft um 1 Byte in die LevelIDTable, liest den Wert $25 und verwendet dann $25 als Index in der LevelIDTable (37. Eintrag) -- was wiederum um 2 Bytes in die SpriteOffsetTable überläuft und den Wert 6 liest.

; World 9 :
;   1. WorldIndexTable[8] (overflow) → lit $25 dans LevelIDTable
;   2. LevelIDTable[37] (overflow) → lit le 2ème byte de SpriteOffsetTable = 6
;   3. ID = 6 → Water level number 6 (qui n'existe pas)
;   4. Tile pointer = pointeur water numéro 6 = tiles de 6-2
;   5. Sprite pointer = index 31+6 = 37 > 33 → pointeur invalide
;   6. Résultat : 6-2 sous l'eau avec des sprites glitchés
;      → world 9-1 !

Für World G (16) geht der Overflow noch weiter und trifft auf Level ID $01, der der Cutscene-Raum ist, der 1-2 vorausgeht:

; World G (16) :
;   WorldIndexTable[15] → lit $01 dans LevelIDTable
;   LevelIDTable[1] = $29 (cutscene 1-2)
;   → world G-1 = la cutscene d'entrée de 1-2

Warum die Glitch Worlds existieren

Das Spiel hat 32 "legitime" Levels (8 Welten × 4 Levels). Aber die Zeigertabelle hat 128 Einträge pro Zonentyp. Die Einträge jenseits von Level 32 enthalten das, was sich in der ROM an diesen Adressen befindet -- manchmal ein anderes Level, manchmal Audiodaten, manchmal RAM, manchmal irgendetwas.

Level ID $01 + AreaType 0 = Minus World

Das berühmteste der Glitch Worlds. Die Level ID $01 in AreaType 0 (Wasser) zeigt auf:

• Tile-Zeiger: $AE45 → der Unterwasserbereich von 2-2/7-2
• Sprite-Zeiger: $A171 → die Sprites von 2-2/7-2

Das Ergebnis: Ein Wasserturn, der 2-2 ähnelt, aber endlos loopt, weil es die Flaggenstange nicht gibt. Kein Level-Ende, kein Ausgang.

Das ist Level 36-1 (oder 36-1 in der Welt $-1).

; Pourquoi le flagpole manque dans le Minus World :
; Les sprites de 2-2/7-2 ($A171) n'ont pas de flagpole
; dans leur séquence. Le jeu cherche le sprite $FD (flagpole)
; mais ne le trouve jamais → boucle infinie
;
; Le jeu continue de générer le niveau à l'infini
; jusqu'à ce que le timer atteigne zéro.

Die Zeiger, die auf die RAM zeigen

Wenn der Tile-Zeiger oder der Sprite-Zeiger auf eine Adresse in der RAM ($00-$7F) statt in der ROM zeigt, versucht das Spiel, die ständig wechselnden RAM-Werte als Tiles zu interpretieren:

; Exemple : Level ID $03 en Water
; Tile Pointer : $A46B (3-3 - valide)
; Sprite Pointer : $009D (pointe vers la RAM page zéro !)
;
; La RAM page zéro contient les registres du jeu,
; la position de Mario, l'état des compteurs...
; Le jeu décompresse ça comme une séquence de sprites,
; et le résultat c'est un niveau avec des ennemis
; qui sont en fait des valeurs de registres.

Wenn sich die Page Zero ändert (weil Mario sich bewegt, der Timer läuft, usw.), ändern sich auch die "Sprites" des Levels. Deshalb haben manche Glitch Worlds Gegner, die flackern und sich ständig verwandeln.

Level ID $36: Der leere Level (Overworld)

Level ID $36 in Overworld:

• Tile-Zeiger: $AC35 (1-2)
• Sprite-Zeiger: $A0D8 (1-2)

Ergebnis: Nichts. Das Spiel lädt das Level, aber es ist als "kein Level" im Katalog von RGMechEx markiert. Die Tiles sind vielleicht gültig, aber die Sprite zeigen auf eine Stelle, die ein leeres oder nicht funktionierendes Level erzeugt.

Level ID $1D (Castle): Der Champion der Abstürze

Level ID $1D in Castle:

• Tile-Zeiger: $A210 (4-4)
• Sprite-Zeiger: $7EA0 (RAM!)

Sprite-Zeiger in RAM = undefinierte Sprites. Das Spiel versucht, einen Spiny Ball oder einen Bullet Bill Blaster in der ersten Tile-Zeile anzuzeigen. Das crasht sofort.

; Quand le sprite pointer pointe vers la RAM,
; le jeu décompresse des bytes qui changent tout le temps
; comme des instructions "spawn". Le résultat :
; - Apparition d'objets inexistants (valeur undefined)
; - Crash PPU quand le sprite NES essaie d'afficher un tile invalide
; - Freeze complet de la console

Die 256 katalogisierten Glitch Worlds

RGMechEx hat ein Script geschrieben, das die Maps aller Levels für die 4 Zonentypen und je 128 IDs generiert.

Der Welt-Zähler ist 8 Bit breit (0-255). Welten 1-8 sind legitim. Es bleiben 248 potenzielle Glitch Worlds. Jede Glitch World entspricht dem ersten Level dieser Welt, und ihre Level-ID wird durch den Overflow-Mechanismus der WorldIndexTable berechnet.

Von den 128 möglichen IDs sind nur 68 das "erste Level" einer Welt (zugänglich über die Glitch-World-Nummer). Die restlichen 60 sind Level 2+ oder nicht erreichbar.

Typ	Einzigartig spielbare IDs	Crash-IDs	Leere IDs
Water (0)	~20	~60	~48
Overworld (1)	~30	~55	~43
Underground (2)	~15	~65	~48
Castle (3)	~25	~58	~45

Viele IDs führen auf dasselbe Level, weil die Zeiger auf dieselben ROM-Adressen treffen. Level ID $28 (Overworld) zum Beispiel -- Tile-Zeiger $A7CD (2-1) -- erscheint in 38 verschiedenen Glitch Worlds, weil sein Sprite-Zeiger $9F51 auf einen Bereich der ROM zeigt, der als Padding/Audiodaten wiederverwendet wird, der von vielen IDs genutzt wird.

Die 6 wirklich einzigartigen Glitch Levels

Von den 19 zugänglichen Glitch-Level-IDs crashten nur 6 nicht sofort beim Laden:

Welt	Level ID	Beschreibung
E-1 (224)	$50	Ein einzelner ? Block über einem Abgrund. Mario stirbt sofort.
W	$57	Mario spawnnt blockiert, kann sich nicht bewegen.
42 (133)	$50	Wolken-Tunnel, der Mario einfängt, wenn er weit genug geht.
62 (131, 240)	$4D	Eingefrorenes Schloss: Mario spawnnt oben, kann nicht fallen → blockiert.
127	$4B	Unterirdischer Tunnel, aber crasht, wenn man zu weit geht.
137	$4B	Aktiviert automatisches Scrollen der Cutscenes. Mario trifft auf einen einzigen Brick-Block, der ihn für immer blockiert.

Sechs Glitch Worlds von 248, die etwas wirklich Neues erzeugen. Der Rest sind normale Levels mit dem falschen Zonentyp oder schwarze Bildschirme.

Das Level-Format im Detail

Schauen wir uns das genaue Format der Level-Daten an, um zu verstehen, warum Glitch Levels funktionieren (oder nicht).

Der Level-Header: 2 Bytes, 6 Eigenschaften

Jedes Level beginnt mit einem 2-Byte-Header, der 6 Eigenschaften steuert:

; Byte 0 : timer + Y start + modifier
;   Bits 7-6 : timer (00=inchangé, 01=200, 10=300, 11=400)
;   Bits 5-3 : Y start Mario (111/110 = autowalk)
;   Bits 2-0 : level type modifier
;              000=default, 001=waves, 010=brick wall,
;              011=water bottom, 100=night, 101=snow,
;              110=snow night, 111=gray night

; Byte 1 : platform + background + floor pattern
;   Bits 7-6 : special platform (00=tree, 01=mushroom,
;                                 10=Bullet Bill, 11=cloud)
;   Bits 5-4 : background (00=none, 01=clouds,
;                           10=montains, 11=fences)
;   Bits 3-0 : floor pattern initial (0-15)

Der Modifier-Typ steuert visuelle Variationen: die Wellen oben in den Wasserturns, der Backstein-Hintergrund von 8-3, die Nacht-Palette von 4-3, der Schnee von 6-2, usw.

Die Tile-Objekte: 2 Bytes, Next-Screen-Flag, 3-Slot-Warteschlange

Nach dem Header folgt eine Liste von Tile-Objekten, jedes Objekt ist 2 Bytes groß. Das Byte $FD markiert das Ende der Liste.

; Format objet tile (16 bits) :
; Byte 0 :
;   Bits 7-4 : X position (colonne 0-15)
;   Bits 3-0 : Y position
;     Y=0-11  : position Y normale
;     Y=12    : objets spéciaux (trous, ponts, rope, ? blocks)
;     Y=13    : screen skip / objets spéciaux 2
;     Y=14    : changement de modifier/scenery/floor
;     Y=15    : objets spéciaux 3 (château, escaliers, gros tuyau)

; Byte 1 :
;   Bit  7   : NEXT SCREEN FLAG
;   Bits 6-4 : type d'objet (0-7)
;   Bits 3-0 : largeur/hauteur / sous-type

Wenn das "Next Screen"-Bit gesetzt ist, wird die aktuelle Arbeits-Spalte um 1 erhöht. Das erlaubt es, Objekte jenseits der ersten 16 Spalten zu platzieren. Die Objekte müssen in der Reihenfolge aufgelistet werden (links nach rechts), weil das Spiel sie sequenziell lädt:

; La routine de chargement a DEUX phases par colonne :
; Phase 1 : chercher les nouveaux objets qui commencent sur cette colonne
;            et les ajouter à la file d'attente (queue)
; Phase 2 : traiter chaque objet dans la queue en dessinant les tiles,
;            et retirer ceux qui finissent sur cette colonne

Die Warteschlange hat genau 3 Slots. Direkte Konsequenz: Es können nicht mehr als 3 Objekte auf derselben Spalte beginnen. Wenn die Warteschlange voll ist, wird das 4. Objekt ignoriert und nie geladen.

Deshalb vermeiden gut designte Levels, zu viele Objekte zu stapeln. Beispiel in 1-2: Die Spalte mit dem 1up-Block an der Decke + die Backsteine daneben sind in zwei separate Objekte aufgeteilt, um die 3er-Limit einzuhalten.

Spezielle Y-Positionen: 12, 13, 14, 15

Wenn Y=12, hat das Objekt keine Y-Position (sie ist je nach Typ hardcodiert):

; Y=12 : objets sans Y position
;   Type 0 : trou (supprime le sol)
;   Type 1 : rope de plateforme mobile
;   Types 2-4 : ponts à Y fixe
;   Type 5 : trou avec eau/lave
;   Types 6-7 : rangées de ? blocks

Wenn Y=13, gibt es zwei Untergruppen. Wenn Bit 6 von Byte 1 auf 1 steht:

; Y=13, bit6=1 : objets spéciaux
;   0 = L-pipe (cutscene), 1 = flagpole, 2-3 = pont/axe/hamer (fin château)
;   4 = stop screen, 5 = random enemies, 6 = loop level, 7+ = crash possible

Wenn bit6=0, kodieren die unteren 5 Bits einen Screen-Skip (direkt zu einem Screen N springen, ohne eins nach dem anderen über das Next-Screen-Flag zu gehen).

Wenn Y=14: Gleiches Prinzip mit bit6=1 zum Ändern des Modifier-Typs, bit6=0 zum Ändern des Hintergrunds + Bodenmusters.

Die Floor Patterns: 16 Bodenmuster

Der Boden der Levels besteht nicht aus einzelnen Objekten. SMB1 verwendet Floor Patterns, ein Hintergrundmuster, das für alle Spalten bis zur nächsten Änderung gilt:

; Floor patterns (4 bits = 16 possibilités)
;   0 = vide total
;   1 = sol 2 tiles haut
;   2 = sol 1 tile haut
;   3 = sol + bottom
;   4 = sol + bottom 2
;   5 = sol 1/2 tile
;   6 = 3/4 sol
;   ... jusqu'à 15 = rempli total (sol + plafond)

Deshalb sind Löcher Objekte: Sie überschreiben das Floor Pattern auf einer bestimmten Spalte, ohne das Muster für den Rest ändern zu müssen.

Die 256-Byte-Grenze und das Repeat

Alle Tile-Daten eines Levels passen in maximal 256 Bytes. Das Y-Register des 6502 wird als Index verwendet und hat 8 Bit. Wenn das Spiel am Ende der Daten angelangt, ohne das $FD-Byte zu finden, schlingt es zum Anfang zurück und wiederholt die 256 Bytes endlos:

; Index Y = 8 bits → max 256 bytes de données tiles
; Si Y overflow (255 → 0) sans rencontrer $FD → repeat
; Même chose pour les sprites, mais les objets pipe (3 bytes)
; décalent la parité de l'index à chaque chargement.

Manche Glitch Levels nutzen dieses Repeat, um Levels zu erzeugen, die "unendlich" dauern.

Das Sprite-System: 2 Bytes + Pipe-Übergänge

Die Sprites folgen einem ähnlichen Format, aber ohne Header und mit einigen Unterschieden. Das Byte $FF markiert das Ende der Liste.

; Format sprite (2 bytes) :
; Byte 0 : position X (colonne)
; Byte 1 :
;   Bit 7 : NEXT SCREEN FLAG
;   Bits 6-0 : type de sprite
;       Certains types incluent : goomba, koopa, Blooper,
;       Bullet Bill, Lakitu, Spiny, plateformes,
;       commande warp zone, toad/princesse,
;       commandes de spawn de groupes d'ennemis

Das niederwertigste Bit von Byte 1 ist das Hard-Level-Flag: Wenn es auf 1 gesetzt ist, erscheint das Sprite nur in Levels ≥ 5-3. So werden die "Hard Mode"-Levels erstellt.

Y-Position 15 = Screen-Skip (identisch mit Tiles). Y-Position 14 = Pipe-Übergang (3 Bytes!):

; Sprite Y=14 : pipe/vine transition (3 bytes !)
;   Byte 0 : position X
;   Byte 1 : bits 6-0 = Level ID 7-bit (destination)
;   Byte 2 : bits 4-0 = screen de destination
;            bits 7-5 = world où cette transition est valide
;
; Pourquoi un world ? Les bonus rooms sont réutilisées entre mondes.
; Exemple : la salle bonus de 1-1 est aussi utilisée par 2-1 et 7-1.
; Cette salle a 3 transitions, une par monde, pour que Mario
; réapparaisse au bon endroit.

Die Sprites haben kein Queue-System. Die einzige Grenze ist, dass nicht mehr als 4 Sprites gleichzeitig im Spawn-Bereich (genau rechts außerhalb des Bildschirms) geladen werden können. Darüber hinaus werden Sprites ignoriert.

Wie man auf die Glitch Worlds zugreift

Es gibt zwei Hauptmethoden.

Die klassische Methode: Der Wall Clip

Der Wall Clip (Durch Wände gehen) erlaubt es, aus dem normalen Level herauszukommen und zur versteckten Warp-Zone zu laufen. Indem man den Welt-Zähler über die RAM manipuliert, kann man jede beliebige Level-ID laden.

Die Technik:

1. World 1-2: In das versteckte Endrohr gehen
2. Den Wall Clip an der rechten Wand machen
3. Durch die Leere zur Warp-Zone laufen
4. Das Spiel interpretiert die Werte als Welten

Aber diese Methode gibt Zugriff nur auf einen kleinen Teil der Glitch Worlds.

Die extreme Methode: NES-Tennis-Kart-Tausch

Siehe den Abschnitt "Der Warm Start" oben für die vollständige Zusammenfassung. Kurz gefasst: Der Schrittzähler von Tennis schreibt auf dasselbe RAM-Byte wie die Startwelt von SMB1, und die Warm-Start-Erkennung bewahrt diesen Wert auf.

Für Bastler: Der Code zum Erkunden

Wenn du alle Glitch Worlds selbst in einem Emulator erkunden möchtest, kannst du die Level-ID direkt patchen:

; Patch pour FCEUX / Mesen :
; Adresse RAM $075F = Level ID actuel
; Adresse RAM $0760 = Area Type (0=Water, 1=Overworld, 2=Underground, 3=Castle)

; Exemple : charger le Level 57 (0x39) en Overworld
; Dans l'émulateur, ouvrir le traceur mémoire et écrire :
; $075F = 0x39
; $0760 = 0x01
; Puis entrer dans un tuyau de warp ou mourir et recommencer
; → Le jeu charge le niveau ID $39 en Overworld

RGMechEx hat die vollständige Liste aller 128 Levels × 4 Typen mit automatisch generierten Maps auf rgmechex.com veröffentlicht. Jeder Eintrag zeigt den Tile-Zeiger, den Sprite-Zeiger und eine visuelle Karte des Levels.

Die verrücktesten Levels

Level ID $1F (Water): 15 Glitch Worlds in einem

Der Tile-Zeiger $A302 (3-4) kombiniert mit dem Sprite-Zeiger $02A0 ergibt 15 verschiedene Glitch Worlds (D-1, J-1, Y-1, Z-1, 55-1, 73-1...). Erklärung: Der Sprite-Zeiger zeigt auf einen Bereich der ROM, der Daten enthält, die nahe genug an gültigen Sprites sind, um spielbare Ergebnisse zu erzeugen, aber die Kombination der Schloss-Tiles von 3-4 mit Overworld-Sprites erzeugt ein absurd erscheinendes Rendering.

Level ID $28 (Overworld): 38 Glitch Worlds = Rekord

Der absolute Rekord. 38 Glitch-World-Einträge zeigen auf dasselbe Level (2-1 Tiles + $9F51 Sprites). Warum? Weil der Sprite-Zeiger $9F51 in einen Bereich der ROM trifft, der als Padding/Audiodaten wiederverwendet wird, der von vielen IDs genutzt wird.

Level ID $49 (Underground): Der FDS-Level

Tile-Zeiger $76AE + Sprite-Zeiger $1C9D. Der Tile-Zeiger zeigt auf den Bereich der ROM, der für die Famicom-Disk-System-Version reserviert ist. Ergebnis: Ein Level mit Tiles, die in der Standard-Cartridge nicht existieren. Das ist das Level, das die Levels 52-1 und 196-1 erscheinen lässt.

Level ID $00-$02: Die echten Bonus-Level

Diese IDs werden von legitimen Unterlevels des Spiels verwendet:

• $00: Unterwasserbereich von 5-2/6-2 (verwendet von H-1, 39-1)
• $01: Das Wasser von 2-2/7-2 (die Minus World, 36-1)
• $02: Unterlevel von 8-4 (136-1, 151-1, 215-1)

Der Unterschied zwischen einem normalerweise zugänglichen "Bonus"-Level und einer Glitch World ist, dass die Warp-Zonen die aktuelle Welt überprüfen:

; Vérification warp zone (simplifié)
; Le jeu vérifie que le monde cible est entre 1 et 8
CheckWarp:
  lda TARGET_WORLD
  cmp #1
  bcc InvalidWarp       ; < 1 → refusé
  cmp #9
  bcs InvalidWarp       ; > 8 → refusé
  ; world valide entre 1 et 8 uniquement
  jmp DoWarp

Glitch Worlds mit Nummern > 8 oder 0 können nicht durch normale Rohren erreicht werden. Man braucht den Wall Clip oder den Kart-Tausch.

Warum manche Levels crashen: Die Jump-Tabellen

Wenn das Spiel ein Tile-Objekt lädt, verwendet es dessen Typ als Index in einer Jump-Tabelle:

; Jump table des objets tiles standards (types 0-11)
JumpTable_TileObjects:
  .word Obj_Special       ; type 0 : bloc ?, hidden, flagpole...
  .word Obj_Platform      ; type 1 : plateforme spéciale
  .word Obj_BrickRow      ; type 2 : rangée de briques
  .word Obj_BlockRow      ; type 3 : rangée de blocks
  .word Obj_CoinRow       ; type 4 : rangée de pièces
  .word Obj_BrickCol      ; type 5 : colonne de briques
  .word Obj_BlockCol      ; type 6 : colonne de blocks
  .word Obj_Pipe          ; type 7 : tuyau
  .word Obj_8             ; type 8
  .word Obj_9             ; type 9
  .word Obj_10            ; type 10
  .word Obj_11            ; type 11

Wenn ein Objekt einen ungültigen Typ hat (≥12), springt das Spiel zu einem Zeiger, der in dieser Tabelle nicht existiert. 4 mögliche Ergebnisse:

1. Gültiger Zeiger → das Objekt lädt normal
2. Zeiger auf eine andere Jump-Tabelle (Überlappung) → ein anderes Objekt erscheint. Beispiel: Typ 12 zeigt auf die Tabelle Y=13, was einen L-Pipe ergibt.
3. Zeiger auf ausführbaren Code → Ausführung von zufälligem Code (wahrscheinlicher Crash)
4. Expliziter Platzhalter (NOP) → das Objekt macht nichts (manche Sprites sind so und erzeugen Gegner, die an Ort und Stelle fliegen, ohne sich zu bewegen)

Das Glitch Level ID $58 (der Tunnel, der crasht): Sein Sprite-Zeiger zeigt auf einen Speicherbereich, der auf NES ohne ROM-Mapper nicht existiert. Das Spiel versucht, denselben Koopa 5 Mal pro Frame an der Position (0,0) zu laden, was die Sättigung der PPU und einen Freeze verursacht.

; Pourquoi ID $58 crashe :
; Sprite pointer → adresse invalide (hors espace NES standard)
; → Le jeu lit des bytes indéterminés comme des types de sprite
; → Le Koopa $00 (type invalide sans handler) boucle en appel récursif
; → Stack overflow 6502 → freeze

Das Pipe-Warp-Paradox

Erinnerst du dich an den Check target_world BETWEEN 1 AND 8? Selbst wenn du eine Rohr in einer Glitch World findest, überprüft das Spiel, ob die Zielswelt zwischen 1 und 8 liegt. Glitch Worlds haben Nummern > 8 (36-1, 255-1...), also schlägt die Warp fehl.

Deshalb hat auch die Minus World kein Ende: Die Flaggenstange ist in den Sprites nicht vorhanden, und die Rohren führen nirgendwo hin.

Der Trick mit den 5 Objekten in einer Spalte

Es gibt einen Edge Case, der es erlaubt, die Grenze von 3 Objekten pro Spalte zu umgehen. Wenn die Warteschlange blockiert (Slots voll + nächstes Objekt ohne Next-Screen-Flag), "vorverarbeitet" das Spiel die aktuelle Spalte in einer Schleife, bis es ein Objekt mit Next-Screen-Flag findet. Bei jeder Vorverarbeitung:

; Pendant le prétraitement de colonne :
; 1. Les objets dans la queue voient leur largeur restante
;    décrémentée à chaque "fausse avancée" de colonne
; 2. Si un objet atteint largeur=0, il quitte la queue
; 3. Un slot libéré peut être rempli par un nouvel objet
;    ajouté dans la même colonne

; Résultat : jusqu'à 5 objets peuvent être traités sur la même colonne.
; Technique : placer 2 objets qui traversent la screen boundary
; (slots 1 et 2), 1 objet dummy en X < précédent (bloque la queue),
; puis 3 objets à X=0 de l'écran suivant (dont un avec next screen flag).

Das nennt man einen "Queue Skip" und wird von manlichen Rom-Hackern verwendet, um dichtere Levels zu erstellen, als das Format normalerweise erlaubt.

Die Unterschiede zwischen Versionen

Famicom Disk System

Die FDS-Version von SMB1 hat eine andere Memory Map. Alle Level-Zeiger sind verschoben, aber die Daten sind dieselben. Was sich ändert: Die Indizes der Glitch Worlds sind völlig unterschiedlich:

FDS World 36 → Level ID $09 (eau version de 5-3)
  → Le flagpole est présent ! On peut finir le niveau.
  → Ensuite : $27 (7-3 normal) → $44 (4-4 underground)
  → $44 est finissable → la hache fonctionne → fin du jeu !
  
Le Minus World FDS est donc un "bonus world" qui peut mener
à la complétion du jeu, contrairement à la version NES.

Mein Lieblings-FDS-Level: ID $5F, eine unterirdische Version der zweiten Hälfte von 3-3 als tiefer Tunnel (schade, dass es ein Autoscroller ist).

The Lost Levels (Super Mario Bros. 2 japanische Version)

Lost Levels ändert viele Dinge:

1. Identische Tiles/Sprites-Reihenfolge: Keine Frankenstein-Levels mehr (Tiles und Sprites laden dasselbe Level, auch bei ungültiger ID)
2. Eine einzige 16-Bit-Zeigertabelle statt zwei separater High/Low-Tabellen
3. 4 Disk-Dateien: Die ROM wurde für das FDS aufgeteilt:
   • Datei 1: Welten 1-4
   • Datei 2: Welten 5-8
   • Datei 3: World 9 + Sound-Engine
   • Datei 4: Welten A-D (völlig andere Zeigertabelle)
4. Gleiche Level-ID = 4 mögliche Levels je nach geladener Datei
5. Kein Tennis-Glitch mehr: Die Continue-Option (im selben World nach Game Over weitermachen) macht den Warm Start überflüssig, und das Spiel resettet sofort wenn World > 9
6. Neue Objekte: Giftiger Pilz, unsichtbarer Block, unsichtbarer Feuerblumen-Block, umgedrehte Rohren, Wind -- aber mitten in bestehende Listen eingefügt → Abwärtsinkompatibilität mit SMB1
7. Piranha Plants immer rot nach World 4, grüne Springbrünne nur in Welten 2/B/3/C/7

Super Mario All-Stars (SNES)

Direkter Port mit denselben 6502-Routinen (der SNES führt den NES-Code im kompatiblen Modus aus):

• Warp-Zone gefixt: Keine Minus World mehr (Eingang in die linke Rohr vor dem Text führt zur richtigen Welt)
• Absturz: Die meisten Glitch Levels crashten (außer ID $6A und 9-1)
• Schloss-Objekte hinzugefügt: Machen die Levels einzigartiger
• Aber: Der 4-2 Wrong Warp funktioniert immer noch (nicht gepatcht!)

Der 4-2 Wrong Warp: Ein Bug bei der Objektplatzierung

In 4-2 gibt es zwei Pipe-Übergangsobjekte: Die Ranke (Warp-Zone) und das Rohr (Coin-Cash-Raum). Das erste Übergangsobjekt (das der Ranke) wird weit bevor die Ranke auf dem Bildschirm erscheint, platziert. Das zweite (das Rohr) wird zu spät im Level platziert.

; Timing des transitions dans 4-2 :
; Objet transition 1 (vigne → warp zone) : placé 3 écrans avant la vigne
; Objet transition 2 (tuyau → coin cash) : placé 1 écran après le tuyau
;
; Normalement le premier objet est désactivé avant que Mario
; n'atteigne le tuyau. Mais si Mario va vite (ou utilise
; le raccourci du bloc B+right), la transition de la vigne
; est toujours active quand il touche le tuyau !
; → Le jeu charge la warp zone au lieu du coin cash.
;
; Si l'objet avait été placé juste après la vigne mais avant
; le tuyau, le bug n'existerait pas.

Die Loop-Levels

Wie funktionieren die Loops (8-4, 7-4)? Das Level hat Checkpoints mit hardcodierten Screen-Nummern und Y-Positionen:

; Checkpoint : {screen_number, vertical_position}
; Si Mario passe ce checkpoint à la bonne hauteur → niveau continue
; Sinon → warp back de 4 écrans (64 blocks)
;
; Pour faire une boucle infinie : vertical_position = $F0
; (en dessous du bas de l'écran) → impossible de valider.
;
; Les checkpoints sont simples (un seul flag) sauf pour world 7
; qui utilise des triplets (3 flags, il faut en échouer au moins 1)
;
; Le warp back est rude : offset de tile data réglé à une valeur
; hardcodée, offset de sprite data remis à 0. Les ennemis présents
; sont déchargés instantanément → les firebars disparaissent.

Das Format ändern, nicht den Code

Eine der faszinierendsten Lektionen dieser Architektur ist, dass die Entwickler von SMB1 es geschafft haben, ein sehr ausdrucksstarkes Level-System zu schaffen, ohne jemals den 6502-Render-Code anzufassen. Die gesamte Variation zwischen den Levels kommt von den Daten (Zeiger, Objekte, Sprites, Floor Patterns), nicht vom Code.

Die 256 Glitch Worlds existieren, weil die Zeigertabellen für 128 Einträge × 4 Typen dimensioniert sind und das Spiel nie die Werte validiert, die es liest. Wenn ein Zeiger in die RAM trifft, interpretiert das Spiel die Register von Mario als Tiles. Wenn ein Zeiger in die Audiodaten trifft, spielt das Spiel Musik in Form von Level-Design. Und wenn die Jump-Tabellen überlaufen, führt das Spiel irgendeinen Code aus bis zum Crash.

Was man daraus lernen kann

1. Tiles/Sprites-Trennung: Volle Unabhängigkeit der beiden Ebenen, mit unterschiedlichen Speicherreihenfolgen, die einzigartige Frankenstein-Levels erzeugen
2. RLE-Kompression + Objekt-System: Levels sind keine Bitmaps, sondern Listen platzierter Objekte mit Floor Patterns für den Boden
3. 3-Slot-Warteschlange: Harte Grenze des Hardwares (und des Level-Designs)
4. Keine Validierung: Das Spiel vertraut den Zeigern und Jump-Tabellen, was entweder spielbare Glitchs oder Abstürze erzeugt
5. 256 Bytes max: Die Grenze des Y-Registers des 6502, wodurch sich Daten wiederholen, wenn man zu weit geht
6. Warm Start / Cold Start: Ein "Weiterspielen"-System, das die Tür für den Tennis-Kart-Tausch → Mario geöffnet hat

Das Schönste: All das ist 6502-Code, der in 40KB passt. Keine Abstraktionsschicht, keine Speicherzugriffsvalidierung, keine Ausnahmebehandlung. Wenn der Zeiger Mist ist, crasht das Spiel. Und Abstürze nennen wir Glitch Worlds.

Die 3 wichtigsten Punkte

1. Glitch Worlds sind Zeiger, die ins Leere treffen -- Das Spiel hat 128 IDs × 4 Zonentypen, aber nur 34 einzigartige Levels. Wenn die World-Nummer korrupt ist (durch Tennis oder Wall Clip), lädt das Spiel einen Zeiger, der für ein anderes Level gedacht war, und die 512 möglichen Kombinationen erzeugen unvorhersehbare Ergebnisse.

2. Die Minus World ist ein Warp-Bug kombiniert mit Korruption -- Die linke Rohr in 1-2, wenn sie aktiviert wird, bevor der Text erscheint, lädt World 36 (0x24). Diese Welt zeigt auf Level ID $01 (Wasser von 2-2), ein Level ohne Flaggenstange. Und da es keinen Pipe-Übergang für World 36 gibt, loopt das Level endlos. Das Fehlen der Überprüfung erschafft das Ikon.

3. Tennis → Mario, 15 Jahre vor OoT → Paper Mario -- Die RAM der NES überlebt einen Cartridge-Tausch dank der Kondensatoren und dem Warm-Start-/Cold-Start-System von SMB1. Der Schrittzähler von Tennis (der ein RAM-Byte erhöht, während er den Schritt-Sound abspielt) trifft genau auf die Adresse der World-Nummer. Die Top-Score-Ziffern müssen bei 0 bleiben, das $A5-Byte muss intakt sein und das Spiel muss einen Warm Start erkennen -- eine perfekte Koinzidenz, die nur mit Tennis funktioniert hat.

Die Originalvideos von Retro Game Mechanics Explained sind ein verdammt fleißiges Meisterwerk -- das Detailliveau bei der 6502-Dissassemble, die automatischen Maps aller Levels, die Erklärungen des Kart-Tauschs und des Warm Starts. Wenn du die Serie noch nicht gesehen hast, schau sie an, sie ist kurz und jede Minute ist dicht.

Der Quellcode der Maps ist auf rgmechex.com verfügbar, und die vollständige Dissassemble von SMB1 ist Open Source in vielen Repos. Vor 40 Jahren haben japanische Programmierer dieses Level-System in 6502 geschrieben, mit null Unit-Tests und null Bug-Tracker, und wir lernen immer noch Dinge, indem wir ihren Code heute öffnen.

Введение

Super Mario Bros. -- это 40 килобайт ROM. Восемь миров, 32 уровня, враги, музыка, пауэр-апы -- всё это влезает сюда.

Но если открыть эмулятор и поковыряться в нужных байтах, можно загрузить уровень 36-1. Или 255-1. Или попасть в мир, где всё сделано из спрайтов Боузера и труб, которые ведут в никуда.

Эти глитч-миры существуют по простой причине: система хранения уровней SMB1 -- это шедевр 8-битной оптимизации, и когда заставляешь игру читать не оттуда, получаешь результаты, от которых захватывает дух.

Retro Game Mechanics Explained снял об этом серию из 4 видео -- мы соберём всё в одну погружённую статью по коду 6502 самой продаваемой игры своего времени.

Тёплый старт: почему RAM тенниса выживает в SMB1

Прежде чем говорить о хранении уровней, надо понять, как стартует SMB1. Потому что глитч cart swap с NES Tennis целиком и полностью опирается на систему определения тёплого/холодного старта игры.

41 байт, который сохраняется

Когда SMB1 определяет холодный старт (первая включение или power off/on), он очищает всю RAM. Но когда определяет тёплый старт (сброс кнопкой, без отключения питания), он сохраняет область памяти в 41 байт:

; Les 41 bytes préservés en RAM lors d'un warm start
; Adresses $075F-$0787
;
; $075F : byte de démarrage (world - 1)    [1 byte]
; $0760 : flag de sélection de monde (B button) [1 byte]
; $0761-$0762 : inutilisé                    [2 bytes]
; $0763-$0768 : timer (6 digits, 3 affichés) [6 bytes]
; $0769-$076E : coins Luigi                   [6 bytes]
; $076F-$0774 : coins Mario                   [6 bytes]
; $0775-$077A : score Luigi                   [6 bytes]
; $077B-$0780 : score Mario                   [6 bytes]
; $0781-$0786 : top score (6 digits, 1 caché) [6 bytes]
; $0787 : le byte magique $A5                 [1 byte]

Эти 41 байт служат одной-единственной цели: дать игроку возможность продолжить с того же мира после game over. Если умереть на 6-3, игра записывает мир 6 в байт старта, и на титульном экране, если зажать A + Start, начнёшь с 6-1.

Двойная проверка тёплого старта

Когда SMB1 загружается, он проверяет не один критерий, а два:

CheckWarmStart:
  ; 1. Vérifier le byte magique $A5 à $0787
  lda $0787
  cmp #$A5
  bne ColdStart        ; pas $A5 → cold start

  ; 2. Vérifier les 6 digits du top score ($0781-$0786)
  ;    Chaque digit doit être entre 0 et 9
  ldx #0
CheckLoop:
  lda $0781,x
  cmp #$0A
  bcs ColdStart        ; digit >= 10 → cold start
  inx
  cpx #6
  bne CheckLoop

  ; Si les deux conditions passent → warm start
  ; La RAM n'est pas effacée, le monde de départ est préservé
  jmp WarmStartBoot

Зачем двойная проверка? Потому что байт $A5 может оказаться на месте случайно (другая игра, оставившая это значение, или состояние покоя по умолчанию чипа RAM). Проверяя, что цифры top score допустимы (0-9), игра убеждается, что данные согласованы.

Почему только теннис работает

Когда впервые вставляешь SMB1 (холодный старт), игра:

1. Очищает всю RAM → top score = 0, world byte = 0
2. Записывает $A5 по адресу $0787

Затем переключаешься на Tennis без выключения консоли. Tennis:

• Не чистит RAM при запуске (мало какие игры NES это делают)
• Не пишет в байты top score → они остаются 0 (валидные)
• Не трогает байт $A5 → он остаётся на месте
• Использует адрес $075F для счётчика шагов игрока

; Le footstep increment dans Tennis :
; À chaque pas du joueur sur le court, Tennis incrémente le byte à $075F.
; Ce même byte est utilisé par SMB1 comme "world number - 1".
;
; 0 pas  → world 0 → SMB1 = world 1
; 1-7 pas → world 1-7 → worlds normaux
; 8+ pas → world 8+ → glitch worlds !
;
; Le compteur ne s'incrémente que quand la musique s'arrête
; (les footstep sounds ne jouent pas pendant la musique).

Когда снова запускаешь SMB1:

1. Байт $A5 всё ещё на месте (Tennis его не трогал)
2. Цифры top score всё ещё 0 (валидные)
3. World byte теперь 8+ (увеличен шагами тенниса)
4. SMB1 определяет тёплый старт → сохраняет повреждённый world byte
5. Зажимаем A + Start → world 9-1, world A-1, world 36-1 и т.д.

Почему надо загружать Mario перед теннисом

Тонкость: сначала нужно загрузить SMB1, потом Tennis, потом снова SMB1. Если начать сразу с тенниса, байт $A5 никогда не будет записан (Tennis не пишет $A5), и определение тёплого старта не сработает -- RAM будет очищена.

Как SMB1 хранит свои уровни в 40КБ

Nintendo R&D4 пришлось решить задачу, которая на первый взгляд кажется простой: представить уровни с горизонтальным скроллингом, тайлами, врагами, предметами -- и всё это уместить в ультра-жёсткий бюджет ROM.

Решение -- разделение на два полностью независимых слоя данных:

Tile layout (карта уровня)

Каждый уровень определяется указателем на структуру тайлов, сжатую в ROM. Сжатие примитивное, но гениальное: байт "управления", за которым следуют 1-3 байта данных.

Формат тайлов использует систему run'ов (как RLE):

; Format tile SMB1 (simplifié)
; Chaque "commande" est un byte contrôle :
;
; $00-$7F : pose une tile, avance d'1 colonne
; $80-$BF : pose une tile répétée N fois (N = byte - $80 + 1)
; $C0-$FF : commande spéciale (fin de ligne, saut, changement de palette)

Exemple : pour dessiner 3 briques consécutives :
  $82 $01    ; répète la tile $01 (brick) 3 fois

Каждый уровень содержит 13 строк по 16 колонок тайлов (13×16 = 208 видимых тайлов). Но сжатый формат позволяет снизить размер значительно ниже -- например, небо и пустые колонки почти не занимают места.

Цикл рендеринга на 6502:

; Décompression tile - loop principale
; Entrée : pointeur tile_data en $XX
; Sortie : tilemap niveau dans la RAM PPU

DecompressTile:
  lda (tile_ptr),y      ; lire byte contrôle
  iny
  cmp #$80
  bcc SingleTile        ; $00-$7F : tile unique
  cmp #$C0
  bcc RunLength         ; $80-$BF : run-length
  jmp SpecialCommand    ; $C0-$FF : commande spéciale

SingleTile:
  sta PPU_DATA          ; écrire la tile directement
  jmp Next

RunLength:
  sec
  sbc #$7E              ; N = control - $7E
  tax
  lda (tile_ptr),y      ; lire la tile à répéter
  iny
: sta PPU_DATA
  dex
  bne :-
  jmp Next

Sprite layout (враги и объекты)

Параллельно враги и объекты (блоки ?, трубы, гумбы, купы) хранятся в полностью отдельной структуре. Каждый спавн определяется 2 байтами:

; Format sprite SMB1
; Byte 0 : position X (en colonnes)
; Byte 1 : type de sprite + bits de page Y
; Y est dérivé de l'index dans la séquence

Une séquence de sprites :
  $01 $4B    ; goomba à la colonne 1
  $09 $4B    ; goomba à la colonne 9
  $10 $61    ; bloc ? à la colonne 16 (contient pièce)
  $15 $54    ; koopa verte à la colonne 21
  $FF        ; fin de séquence

Каждый уровень может ссылаться до 5 страниц различных спрайтов (точнее, 5 "экранов" по 16 колонок), но на практике большинство уровней использует только 2-3.

Таблица указателей

Гениальность конструкции -- в таблице указателей. Каждый уровень хранится как пара адресов ROM:

// Structure interne (simplifiée) du World Map
struct LevelPointer {
    uint16_t tile_ptr;   // Adresse ROM des données tiles
    uint16_t sprite_ptr; // Adresse ROM des données sprites
};

// 4 tables séparées, une par AreaType :
// 0 = Water, 1 = Overworld, 2 = Underground, 3 = Castle
LevelPointer level_table[4][128];

128 записей на таблицу. 4 типа зон. 512 возможных комбинаций, но лишь дробь используется официальной игрой. Остальное -- неинициализированная RAM или данные, которые интерпретируются как указатели.

Когда игра загружает уровень, она делает вот это:

; Chargement d'un niveau
; A = AreaType (0-3), X = LevelID (0-127)

LoadLevel:
  sta AREA_TYPE
  asl                  ; *2 pour offset dans table 16-bit
  tax
  lda LevelTable_TilePtr, x
  sta TILE_PTR
  lda LevelTable_TilePtr+1, x
  sta TILE_PTR+1       ; pointeur vers les tiles
  lda LevelTable_SpritePtr, x
  sta SPRITE_PTR
  lda LevelTable_SpritePtr+1, x
  sta SPRITE_PTR+1     ; pointeur vers les sprites
  jsr DecompressTiles

Ни какой проверки. Ни проверки, что указатель валиден. Игра читает адрес из таблицы и распаковывает то, что лежит по этому адресу, точка.

34 уникальных уровня и 7-битная система ID

SMB1 имеет не 32, а 34 уникальных уровня. Многие уровни -- дубликаты (5-3 = 1-3, но с Bullet Bills), помеченные флагом "hard mode". Настоящие уникальные уровни:

• Вода (Тип 0): 3 уровня (2-2, 7-2, бонусная зона 5-2/6-2)
• Overworld (Тип 1): 22 уровня (включая 2 бонусных облачных комнаты)
• Underground (Тип 2): 3 уровня (включая подземные бонусные комнаты)
• Castle (Тип 3): 6 уровней
• + 1 комната кат-сцены (перед подземными/водными уровнями)
• + 1 warp-зона 4-2

Каждый уровень имеет ID на 7 битах. Младшие 5 бит = номер в подгруппе, старшие 2 бита = тип зоны:

; Encodage 7-bit du Level ID
; Bits 6-5 : Type (00=Water, 01=Overworld, 10=Underground, 11=Castle)
; Bits 4-0 : Numéro dans le sous-groupe
;
; Water IDs      : $00-$02  (types 00, numéros 0-2)
; Overworld IDs  : $20-$35  (types 01, numéros 0-21)
; Underground IDs: $40-$42  (types 10, numéros 0-2)
; Castle IDs     : $60-$65  (types 11, numéros 0-5)
;
; ID $25 = %0100101 → type 01 (Overworld), numéro 5 → 1-1
; ID $23 = %0100011 → type 01 (Overworld), numéro 3 → 6-2

128 возможных ID ($00-$7F), только 34 назначены реальным уровням. Неиспользуемые ID указывают на что угодно.

Таблицы указателей: два списка, два порядка

Указатели тайлов и спрайтов хранятся в разном порядке. Код использует две отдельные 16-битные таблицы (старший байт / младший байт в разных таблицах):

Ordre des pointeurs sprites :
  Index 0-5   : Castle (6 niveaux)
  Index 6-27  : Overworld (22 niveaux)
  Index 28-30 : Underground (3 niveaux)
  Index 31-33 : Water (3 niveaux)

Ordre des pointeurs tiles :
  Index 0-2   : Water (3 niveaux)
  Index 3-24  : Overworld (22 niveaux)
  Index 25-27 : Underground (3 niveaux)
  Index 28-33 : Castle (6 niveaux)

Почему разный порядок? Технических причин нет -- скорее всего, данные были организованы так в процессе разработки. Но это создаёт fascinating последствие: когда ID уровня невалиден, указатели тайлов и спрайтов загружают разные уровни, создавая Frankenstein levels.

Чтобы перемещаться между этими двумя списками, игра использует небольшие таблицы смещений (как оглавление):

; Tables d'offset par type (Water, Overworld, Underground, Castle)
; Chaque entrée = index de début dans la liste correspondante

SpriteOffsetTable:
  .byte $1F, $06, $1C, $00    ; Water=31, Overworld=6, Underground=28, Castle=0

TileOffsetTable:
  .byte $00, $03, $19, $1C    ; Water=0, Overworld=3, Underground=25, Castle=28

Чтобы загрузить уровень 6-2 (ID $23, Overworld номер 3):

; 1. Type = 01 (Overworld) → index dans table d'offset = 1
; 2. Sprite offset = SpriteOffsetTable[1] = 6
;    Index final = 6 + 3 (numéro de niveau) = 9 → 10ème pointeur sprites
; 3. Tile offset = TileOffsetTable[1] = 3
;    Index final = 3 + 3 = 6 → 7ème pointeur tiles
; 4. Résultat : pointeur tiles $A619 + pointeur sprites $9ED0 = 6-2 ✓

А что происходит с невалидным ID вроде $43 (Underground номер 3, которого не существует)?

; ID $43, Type = 10 (Underground), numéro = 3
; Sprite offset = SpriteOffsetTable[2] = $1C = 28
;   Index = 28 + 3 = 31 → 32ème pointeur sprites = eau bonus 5-2 !
; Tile offset = TileOffsetTable[2] = $19 = 25
;   Index = 25 + 3 = 28 → 29ème pointeur tiles = 1-4 (Castle) !
;
; Résultat : un niveau souterrain avec les tiles de 1-4
; et les Bloopers de la zone eau de 5-2. Un vrai Frankenstein.

World index table: почему world 9 переполняется

Есть ROM-таблица из 8 байтов, которая даёт индекс первого уровня каждого мира (1-8). И сразу за ней таблица из 36 Level IDs всех уровней в порядке игры.

; WorldIndexTable (8 bytes)
  .byte 0, 5, 10, 15, 20, 25, 28, 33
;   -> Monde 1 commence au niveau 0
;   -> Monde 2 commence au niveau 5
;   -> Monde 8 commence au niveau 33

; LevelIDTable (36 bytes)
  .byte $25, $28, $29, $26, $24, ... ; les 36 Level IDs

Когда пытаешься загрузить world 9, игра читает 9-й байт WorldIndexTable... которого не существует. Он переполняется на 1 байт в LevelIDTable, читает значение $25, затем использует $25 как индекс в LevelIDTable (37-я запись) -- что снова переполняется на 2 байта в SpriteOffsetTable, и читает значение 6.

; World 9 :
;   1. WorldIndexTable[8] (overflow) → lit $25 dans LevelIDTable
;   2. LevelIDTable[37] (overflow) → lit le 2ème byte de SpriteOffsetTable = 6
;   3. ID = 6 → Water level number 6 (qui n'existe pas)
;   4. Tile pointer = pointeur water numéro 6 = tiles de 6-2
;   5. Sprite pointer = index 31+6 = 37 > 33 → pointeur invalide
;   6. Résultat : 6-2 sous l'eau avec des sprites glitchés
;      → world 9-1 !

Для world G (16) переполнение идёт ещё дальше и попадает на Level ID $01 -- это кат-сцена перед 1-2:

; World G (16) :
;   WorldIndexTable[15] → lit $01 dans LevelIDTable
;   LevelIDTable[1] = $29 (cutscene 1-2)
;   → world G-1 = la cutscene d'entrée de 1-2

Почему существуют глитч-миры

У игры 32 "легитимных" уровня (8 миров × 4 уровня). Но таблица указателей содержит 128 записей на тип зоны. Записи за пределами 32-го уровня содержат то, что лежит в ROM по этим адресам -- иногда другой уровень, иногда звуковые данные, иногда RAM, иногда что попало.

Level ID $01 + AreaType 0 = Minus World

Самый знаменитый из глитч-миров. Level ID $01 в AreaType 0 (вода) указывает на:

• Tile pointer: $AE45 → подводная зона 2-2/7-2
• Sprite pointer: $A171 → спрайты 2-2/7-2

Результат: водный уровень, похожий на 2-2, но зацикленный бесконечно, потому что flagpole не существует. Нет конца уровня, нет выхода.

Это уровень 36-1 (или 36-1 в мире $-1).

; Pourquoi le flagpole manque dans le Minus World :
; Les sprites de 2-2/7-2 ($A171) n'ont pas de flagpole
; dans leur séquence. Le jeu cherche le sprite $FD (flagpole)
; mais ne le trouve jamais → boucle infinie
;
; Le jeu continue de générer le niveau à l'infini
; jusqu'à ce que le timer atteigne zéro.

Указатели, указывающие на RAM

Когда tile pointer или sprite pointer указывает на адрес в RAM ($00-$7F) вместо ROM, игра пытается интерпретировать постоянные изменения RAM как тайлы:

; Exemple : Level ID $03 en Water
; Tile Pointer : $A46B (3-3 - valide)
; Sprite Pointer : $009D (pointe vers la RAM page zéro !)
;
; La RAM page zéro contient les registres du jeu,
; la position de Mario, l'état des compteurs...
; Le jeu décompresse ça comme une séquence de sprites,
; et le résultat c'est un niveau avec des ennemis
; qui sont en fait des valeurs de registres.

Когда нулевая страница меняется (потому что Mario двигается, таймер тикает и т.д.), "спрайты" уровня тоже меняются. Поэтому у некоторых глитч-миров враги мигают и постоянно превращаются во что-то другое.

Level ID $36: пустой уровень (Overworld)

Level ID $36 в Overworld:

• Tile pointer: $AC35 (1-2)
• Sprite pointer: $A0D8 (1-2)

Результат: ничего. Игра загружает уровень, но в каталоге RGMechEx он отмечен как "без уровня". Тайлы могут быть валидными, но спрайты указывают на место, которое создаёт пустой или нерабочий уровень.

Level ID $1D (Castle): чемпион крашей

Level ID $1D в Castle:

• Tile pointer: $A210 (4-4)
• Sprite pointer: $7EA0 (RAM!)

Sprite pointer в RAM = неопределённые спрайты. Игра пытается отрисовать Spiny ball или Bullet Bill blaster в первой строке тайлов. Это вызывает немедленный краш.

; Quand le sprite pointer pointe vers la RAM,
; le jeu décompresse des bytes qui changent tout le temps
; comme des instructions "spawn". Le résultat :
; - Apparition d'objets inexistants (valeur undefined)
; - Crash PPU quand le sprite NES essaie d'afficher un tile invalide
; - Freeze complet de la console

256 глитч-миров, каталогизированных

RGMechEx написал скрипт, который генерирует карты всех уровней для 4 типов зон и 128 ID каждый.

Счётчик мира -- 8 бит (0-255). Миры 1-8 легитимные. Остаётся 248 потенциальных глитч-миров. Каждый глитч-мир соответствует первому уровню этого мира, а его Level ID вычисляется механизмом переполнения WorldIndexTable.

Из 128 возможных ID только 68 являются "первым уровнем" мира (доступными через номер глитч-мира). Остальные 60 -- это уровни 2+ или недоступные.

Тип	Уникальные играбельные ID	ID, которые крашатся	Пустые ID
Water (0)	~20	~60	~48
Overworld (1)	~30	~55	~43
Underground (2)	~15	~65	~48
Castle (3)	~25	~58	~45

Многие ID ведут на один и тот же уровень из-за указателей, попадающих на одинаковые адреса ROM. Например, Level ID $28 (Overworld) -- tile pointer $A7CD (2-1) -- появляется в 38 разных глитч-мирах, потому что его sprite pointer $9F51 указывает на область ROM, которая используется как padding/звуковые данные и переиспользуется множеством ID.

6 по-настоящему уникальных глитч-уровней

Из 19 доступных ID глитч-уровней только 6 не крашатся сразу при загрузке:

Мир	Level ID	Описание
E-1 (224)	$50	Один-единственный ? блок над пропастью. Mario умирает мгновенно.
W	$57	Mario застревает при спавне, не может двигаться.
42 (133)	$50	Облачный туннель, который ловит Mario, если он уйдёт достаточно далеко.
62 (131, 240)	$4D	Замёрзший замок: Mario спавнится наверху, не может упасть → застревает.
127	$4B	Подземный туннель, но крашится, если уйти слишком далеко.
137	$4B	Активирует автоматический скроллинг кат-сцен. Mario встречает единственный brick block, который блокирует его навсегда.

Шесть глитч-миров из 248, которые производят что-то действительно новое. Остальные -- это нормальные уровни с неправильным типом зоны или чёрные экраны.

Формат уровней в деталях

Копнём в точный формат данных уровня, чтобы понять, почему глитч-уровни держатся (или нет).

Заголовок уровня: 2 байта, 6 свойств

Каждый уровень начинается с заголовка в 2 байта, который управляет 6 свойствами:

; Byte 0 : timer + Y start + modifier
;   Bits 7-6 : timer (00=inchangé, 01=200, 10=300, 11=400)
;   Bits 5-3 : Y start Mario (111/110 = autowalk)
;   Bits 2-0 : level type modifier
;              000=default, 001=waves, 010=brick wall,
;              011=water bottom, 100=night, 101=snow,
;              110=snow night, 111=gray night

; Byte 1 : platform + background + floor pattern
;   Bits 7-6 : special platform (00=tree, 01=mushroom,
;                                 10=Bullet Bill, 11=cloud)
;   Bits 5-4 : background (00=none, 01=clouds,
;                           10=montains, 11=fences)
;   Bits 3-0 : floor pattern initial (0-15)

Модификатор типа управляет визуальными вариациями: волны вверху водных уровней, кирпичный фон 8-3, ночная палитра 4-3, снег 6-2 и т.д.

Объекты тайлов: 2 байта, Next Screen Flag, очередь на 3 слота

После заголовка идёт список объектов тайлов, каждый по 2 байта. Байт $FD отмечает конец списка.

; Format objet tile (16 bits) :
; Byte 0 :
;   Bits 7-4 : X position (colonne 0-15)
;   Bits 3-0 : Y position
;     Y=0-11  : position Y normale
;     Y=12    : objets spéciaux (trous, ponts, rope, ? blocks)
;     Y=13    : screen skip / objets spéciaux 2
;     Y=14    : changement de modifier/scenery/floor
;     Y=15    : objets spéciaux 3 (château, escaliers, gros tuyau)

; Byte 1 :
;   Bit  7   : NEXT SCREEN FLAG
;   Bits 6-4 : type d'objet (0-7)
;   Bits 3-0 : largeur/hauteur / sous-type

Когда установлен бит "next screen", текущая рабочая колонка увеличивается на 1. Это позволяет размещать объекты за пределами первых 16 колонок. Объекты должны быть перечислены в порядке (слева направо), потому что игра загружает их последовательно:

; La routine de chargement a DEUX phases par colonne :
; Phase 1 : chercher les nouveaux objets qui commencent sur cette colonne
;            et les ajouter à la file d'attente (queue)
; Phase 2 : traiter chaque objet dans la queue en dessinant les tiles,
;            et retirer ceux qui finissent sur cette colonne

О очередь вмещает ровно 3 слота. Прямое следствие: нельзя иметь больше 3 объектов, начинающихся на одной колонке. Если очередь заполнена, 4-й объект игнорируется и никогда не загрузится.

Именно поэтому хорошо спроектированные уровни избегают слишком плотной укладки объектов. Пример из 1-2: колонка с 1up блоком в потолке + кирпичи рядом разделены на два отдельных объекта, чтобы соблюсти лимит в 3.

Специальные Y-позиции: 12, 13, 14, 15

Когда Y=12, объект не имеет Y-позиции (она зашита по типу):

; Y=12 : objets sans Y position
;   Type 0 : trou (supprime le sol)
;   Type 1 : rope de plateforme mobile
;   Types 2-4 : ponts à Y fixe
;   Type 5 : trou avec eau/lave
;   Types 6-7 : rangées de ? blocks

Когда Y=13, две подгруппы. Если бит 6 первого байта равен 1:

; Y=13, bit6=1 : objets spéciaux
;   0 = L-pipe (cutscene), 1 = flagpole, 2-3 = pont/axe/hamer (fin château)
;   4 = stop screen, 5 = random enemies, 6 = loop level, 7+ = crash possible

Если bit6=0, младшие 5 бит кодируют screen skip (перейти напрямую к экрану N, не проходя по next screen flag по одному).

Когда Y=14: тот же принцип -- bit6=1 для смены модификатора типа, bit6=0 для смены фона + паттерна пола.

Floor patterns: 16 паттернов пола

Пол уровней не состоит из отдельных объектов. SMB1 использует floor patterns -- паттерн фона, который применяется ко всем колонкам до следующего изменения:

; Floor patterns (4 bits = 16 possibilités)
;   0 = vide total
;   1 = sol 2 tiles haut
;   2 = sol 1 tile haut
;   3 = sol + bottom
;   4 = sol + bottom 2
;   5 = sol 1/2 tile
;   6 = 3/4 sol
;   ... jusqu'à 15 = rempli total (sol + plafond)

Именно поэтому дыры -- это объекты: они переопределяют floor pattern на конкретной колонке, не изменяя паттерн для всего остального.

Лимит 256 байт и повторение

Все tile-данные уровня помещаются в максимум 256 байт. Y-регистр 6502 используется как индекс, и он 8-битный. Если игра доходит до конца данных, не найдя байт $FD, она возвращается в начало и повторяет 256 байт бесконечно:

; Index Y = 8 bits → max 256 bytes de données tiles
; Si Y overflow (255 → 0) sans rencontrer $FD → repeat
; Même chose pour les sprites, mais les objets pipe (3 bytes)
; décalent la parité de l'index à chaque chargement.

Некоторые глитч-уровни используют это повторение для генерации уровней, которые длятся "бесконечно".

Система спрайтов: 2 байта + pipe-транзишены

Спрайты следуют похожему формату, но без заголовка и с некоторыми ключевыми отличиями. Байт $FF отмечает конец списка.

; Format sprite (2 bytes) :
; Byte 0 : position X (colonne)
; Byte 1 :
;   Bit 7 : NEXT SCREEN FLAG
;   Bits 6-0 : type de sprite
;       Certains types incluent : goomba, koopa, Blooper,
;       Bullet Bill, Lakitu, Spiny, plateformes,
;       commande warp zone, toad/princesse,
;       commandes de spawn de groupes d'ennemis

Младший бит первого байта -- hard level flag: если установлен в 1, спрайт появляется только на уровнях ≥ 5-3. Так создаются уровни "hard mode".

Y-позиция 15 = screen skip (аналогично тайлам). Y-позиция 14 = pipe transition (3 байта):

; Sprite Y=14 : pipe/vine transition (3 bytes !)
;   Byte 0 : position X
;   Byte 1 : bits 6-0 = Level ID 7-bit (destination)
;   Byte 2 : bits 4-0 = screen de destination
;            bits 7-5 = world où cette transition est valide
;
; Pourquoi un world ? Les bonus rooms sont réutilisées entre mondes.
; Exemple : la salle bonus de 1-1 est aussi utilisée par 2-1 et 7-1.
; Cette salle a 3 transitions, une par monde, pour que Mario
; réapparaisse au bon endroit.

У спрайтов нет системы очереди. Единственное ограничение -- в зоне спавна (просто за экраном справа) не может быть загружено одновременно больше 4 спрайтов. Больше -- спрайты игнорируются.

Как получить доступ к глитч-мирам

Есть два основных метода.

Классический метод: wall clip

Wall clip (прохождение сквозь стены) позволяет выйти из нормального уровня и дойти до спрятанной warp-зоны. Манипулируя счётчиком мира через RAM, можно загрузить любой Level ID.

Техника:

1. World 1-2: зайти в спрятанную трубу в конце
2. Сделать wall clip на правой стене
3. Идти в пустоте до warp-зоны
4. Интерпретирует значения как миры

Но этот метод даёт доступ только к малой части глитч-миров.

Экстремальный метод: cart swap с NES Tennis

Подробности см. в разделе "Тёплый старт" выше. Вкратце: счётчик шагов тennis пишет в тот же байт RAM, что и стартовый мир SMB1, а определение тёплого старта сохраняет это значение.

Блог для хакеров: код для полного исследования

Если хочешь исследовать все глитчи сам в эмуляторе, можно пропатчить Level ID напрямую:

; Patch pour FCEUX / Mesen :
; Adresse RAM $075F = Level ID actuel
; Adresse RAM $0760 = Area Type (0=Water, 1=Overworld, 2=Underground, 3=Castle)

; Exemple : charger le Level 57 (0x39) en Overworld
; Dans l'émulateur, ouvrir le traceur mémoire et écrire :
; $075F = 0x39
; $0760 = 0x01
; Puis entrer dans un tuyau de warp ou mourir et recommencer
; → Le jeu charge le niveau ID $39 en Overworld

RGMechEx опубликовал полный список из 128 уровней × 4 типа с автоматически сгенерированными картами на rgmechex.com. Каждая запись показывает tile pointer, sprite pointer и визуальную карту уровня.

Самые WTF-уровни

Level ID $1F (Water): 15 глитч-миров в одном

Tile pointer $A302 (3-4) в комбинации со sprite pointer $02A0 даёт 15 разных глитч-миров (D-1, J-1, Y-1, Z-1, 55-1, 73-1...). Объяснение: sprite pointer указывает на область ROM, содержащую данные, достаточно близкие к валидным спрайтам для создания играбельных результатов, но комбинация тайлов замка 3-4 со спрайтами overworld создаёт абсурдный рендер.

Level ID $28 (Overworld): 38 глитч-миров = рекорд

Абсолютный рекорд. 38 записей глитч-миров указывают на один и тот же уровень (тайлы 2-1 + $9F51 спрайты). Почему? Потому что sprite pointer $9F51 попадает в область ROM, которая используется как padding/звуковые данные и переиспользуется множеством ID.

Level ID $49 (Underground): уровень FDS

Tile pointer $76AE + sprite pointer $1C9D. Tile pointer указывает на область ROM, зарезервированную для версии Famicom Disk System. Результат: уровень с тайлами, которых не существует в стандартном картридже. Именно этот уровень порождает уровни 52-1 и 196-1.

Level ID $00-$02: настоящие бонусные уровни

Эти ID используются легитимными подуровнями игры:

• $00: подводная зона 5-2/6-2 (используется H-1, 39-1)
• $01: вода 2-2/7-2 (Minus World, 36-1)
• $02: подуровень 8-4 (136-1, 151-1, 215-1)

Разница между "бонусным" уровнем, доступным нормально, и глитч-миром в том, что warp-зоны проверяют текущий мир:

; Vérification warp zone (simplifié)
; Le jeu vérifie que le monde cible est entre 1 et 8
CheckWarp:
  lda TARGET_WORLD
  cmp #1
  bcc InvalidWarp       ; < 1 → refusé
  cmp #9
  bcs InvalidWarp       ; > 8 → refusé
  ; world valide entre 1 et 8 uniquement
  jmp DoWarp

Глитч-миры с номерами > 8 или 0 недоступны через нормальные трубы. Нужен wall clip или cart swap.

Почему некоторые уровни крашатся: jump tables

Когда игра загружает объект тайла, она использует его тип как индекс в jump table:

; Jump table des objets tiles standards (types 0-11)
JumpTable_TileObjects:
  .word Obj_Special       ; type 0 : bloc ?, hidden, flagpole...
  .word Obj_Platform      ; type 1 : plateforme spéciale
  .word Obj_BrickRow      ; type 2 : rangée de briques
  .word Obj_BlockRow      ; type 3 : rangée de blocks
  .word Obj_CoinRow       ; type 4 : rangée de pièces
  .word Obj_BrickCol      ; type 5 : colonne de briques
  .word Obj_BlockCol      ; type 6 : colonne de blocks
  .word Obj_Pipe          ; type 7 : tuyau
  .word Obj_8             ; type 8
  .word Obj_9             ; type 9
  .word Obj_10            ; type 10
  .word Obj_11            ; type 11

Если объект имеет невалидный тип (≥12), игра прыгает на указатель, которого нет в этой таблице. 4 возможных исхода:

1. Валидный указатель → объект загружается нормально
2. Указатель на другую jump table (перекрытие) → появляется другой объект. Пример: тип 12 указывает на таблицу Y=13, что даёт L-pipe.
3. Указатель на исполняемый код → выполнение случайного кода (скорее всего краш)
4. Явный placeholder (NOP) → объект ничего не делает (некоторые спрайты такие -- враги висят на месте без движения)

Глитч-уровень ID $58 (туннель, который крашится): его sprite pointer указывает на область памяти, которой не существует на NES без mapper ROM. Игра пытается загрузить одного и того же Koopa 5 раз за кадр в позиции (0,0), что перегружает PPU и вызывает фриз.

; Pourquoi ID $58 crashe :
; Sprite pointer → adresse invalide (hors espace NES standard)
; → Le jeu lit des bytes indéterminés comme des types de sprite
; → Le Koopa $00 (type invalide sans handler) boucle en appel récursif
; → Stack overflow 6502 → freeze

Парадокс pipe warp

Помнишь проверку target_world BETWEEN 1 AND 8? Даже если найдёшь трубу в глитч-мире, игра проверит, что мир назначения между 1 и 8. Глитч-миры имеют номера > 8 (36-1, 255-1...), поэтому warp не работает.

Именно поэтому Minus World не имеет конца: flagpole не присутствует в спрайтах, а трубы ведут в никуда.

Трюк с 5 объектами в одной колонке

Существует edge case, который позволяет обойти лимит в 3 объекта на колонку. Когда очередь блокируется (слоты заполнены + следующий объект без next screen flag), игра "предобрабатывает" текущую колонку в цикле, пока не найдёт объект с next screen flag. При каждой предобработке:

; Pendant le prétraitement de colonne :
; 1. Les objets dans la queue voient leur largeur restante
;    décrémentée à chaque "fausse avancée" de colonne
; 2. Si un objet atteint largeur=0, il quitte la queue
; 3. Un slot libéré peut être rempli par un nouvel objet
;    ajouté dans la même colonne

; Résultat : jusqu'à 5 objets peuvent être traités sur la même colonne.
; Technique : placer 2 objets qui traversent la screen boundary
; (slots 1 et 2), 1 objet dummy en X < précédent (bloque la queue),
; puis 3 objets à X=0 de l'écran suivant (dont un avec next screen flag).

Это называется "queue skip" и используется некоторыми ромхакерами для создания уровней плотнее, чем позволяет формат.

Различия между версиями

Famicom Disk System

Версия FDS SMB1 имеет другую memory map. Все указатели уровней сдвинуты, но данные те же. Что меняется: индексы глитч-миров полностью другие:

FDS World 36 → Level ID $09 (eau version de 5-3)
  → Le flagpole est présent ! On peut finir le niveau.
  → Ensuite : $27 (7-3 normal) → $44 (4-4 underground)
  → $44 est finissable → la hache fonctionne → fin du jeu !
  
Le Minus World FDS est donc un "bonus world" qui peut mener
à la complétion du jeu, contrairement à la version NES.

Мой любимый FDS-уровень: ID $5F, подземная версия второй половины 3-3 в низком туннеле (жаль, что это автоскроллер).

The Lost Levels (Super Mario Bros. 2 японская)

Lost Levels меняет многое:

1. Одинаковый порядок tiles/sprites: больше нет Frankenstein levels (тайлы и спрайты загружают один и тот же уровень даже с невалидным ID)
2. Одна 16-битная таблица указателей вместо двух отдельных таблиц high/low
3. 4 файл диска: ROM была разделена для FDS:
   • Файл 1: миры 1-4
   • Файл 2: миры 5-8
   • Файл 3: мир 9 + звуковой движок
   • Файл 4: миры A-D (совершенно другая таблица указателей)
4. Один Level ID = 4 возможных уровня в зависимости от загруженного файла
5. Больше нет глитча с теннисом: опция continue (продолжение с того же мира после game over) делает тёплый старт ненужным, и игра мгновенно сбрасывается, если мир > 9
6. Новые объекты: ядовитый гриб, невидимый блок, невидимый блок с огненным цветком, перевёрнутые трубы, ветер -- но вставлены в середину существующих списков → обратная несовместимость с SMB1
7. Piranha Plants всегда красные после мира 4, зелёные пружины только в мирах 2/B/3/C/7

Super Mario All-Stars (SNES)

Прямой порт с теми же 6502-рутинами (SNES выполняет код NES в совместимом режиме):

• Исправленная warp-зона: больше нет Minus World (вход в левую трубу до текста ведёт в правильный мир)
• Падение: большинство глитч-уровней крашатся (кроме ID $6A и 9-1)
• Добавлены объекты замка: более уникальный рендер
• Но: 4-2 wrong warp по-прежнему работает (не исправлен!)

4-2 wrong warp: баг размещения объекта

В 4-2 есть два объекта pipe-транзишена: лоза (warp-зона) и труба (комната с монетами). Первый объект транзишена (лозы) размещён задолго до того, как лоза появляется на экране. Второй (труба) размещён слишком поздно в уровне.

; Timing des transitions dans 4-2 :
; Objet transition 1 (vigne → warp zone) : placé 3 écrans avant la vigne
; Objet transition 2 (tuyau → coin cash) : placé 1 écran après le tuyau
;
; Normalement le premier objet est désactivé avant que Mario
; n'atteigne le tuyau. Mais si Mario va vite (ou utilise
; le raccourci du bloc B+right), la transition de la vigne
; est toujours active quand il touche le tuyau !
; → Le jeu charge la warp zone au lieu du coin cash.
;
; Si l'objet avait été placé juste après la vigne mais avant
; le tuyau, le bug n'existerait pas.

Зацикленные уровни

Как работают loop (8-4, 7-4)? У уровня есть чекпоинты с номерами экранов и зашитыми Y-позициями:

; Checkpoint : {screen_number, vertical_position}
; Si Mario passe ce checkpoint à la bonne hauteur → niveau continue
; Sinon → warp back de 4 écrans (64 blocks)
;
; Pour faire une boucle infinie : vertical_position = $F0
; (en dessous du bas de l'écran) → impossible de valider.
;
; Les checkpoints sont simples (un seul flag) sauf pour world 7
; qui utilise des triplets (3 flags, il faut en échouer au moins 1)
;
; Le warp back est rude : offset de tile data réglé à une valeur
; hardcodée, offset de sprite data remis à 0. Les ennemis présents
; sont déchargés instantanément → les firebars disparaissent.

Менять формат, а не код

Один из самых завораживающих уроков этой архитектуры -- разработчики SMB1 смогли создать очень выразительную систему уровней, никогда не трогая код рендеринга 6502. Всё разнообразие между уровнями идёт от данных (указатели, объекты, спрайты, floor patterns), а не от кода.

256 глитч-миров существуют потому, что таблицы указателей рассчитаны на 128 записей × 4 типа, и игра никогда не проверяет значения, которые читает. Когда указатель попадает в RAM, игра интерпретирует регистры Mario как тайлы. Когда указатель попадает в звуковые данные, игра играет музыку в виде level design. А когда jump tables переполняются, игра выполняет что угодно вплоть до краша.

Чему можно научиться из всего этого

1. Разделение tiles/sprites: полная независимость двух слоёв с разным порядком хранения, создающим уникальные Frankenstein levels
2. RLE-сжатие + система объектов: уровни -- не битмапы, а списки размещённых объектов с floor patterns для пола
3. Очередь на 3 слота: строгое ограничение hardware (и дизайна уровней)
4. Без проверки: игра доверяет указателям и jump tables, что даёт либо играбельные глитчи, либо краши
5. 256 байт максимум: лимит Y-регистра 6502, из-за которого данные повторяются при выходе за границу
6. Warm start / cold start: система "продолжения", открывшая дверь к cart swap Tennis → Mario

Самое прекрасное: всё это -- код 6502, уместившийся в 40КБ. Без слоя абстракции, без проверки доступа к памяти, без обработчика исключений. Если указатель отстойный -- игра крашится. А краши мы называем глитч-мирами.

3 главных вывода

1. Глитч-миры -- это указатели, которые попадают не туда -- У игры 128 ID × 4 типа зон, но только 34 уникальных уровня. Когда номер мира повреждён (теннисом или wall clip), игра загружает указатель, предназначенный для другого уровня, и 512 возможных комбинаций дают непредсказуемые результаты.

2. Minus World -- это баг warp'а в сочетании с повреждением данных -- Левая труба в 1-2, если активирована до появления текста, загружает мир 36 (0x24). Этот мир указывает на Level ID $01 (вода 2-2), уровень без flagpole. И поскольку для мира 36 нет pipe-транзишена, уровень зацикливается. Отсутствие проверки создаёт икону.

3. Tennis → Mario, 15 лет до OoT → Paper Mario -- RAM NES выживает при замене картриджа благодаря конденсаторам и системе warm start / cold start SMB1. Счётчик шагов тенниса (который увеличивает байт RAM, проигрывая звук шагов) попадает точно на адрес номера мира. Нужно, чтобы цифры top score оставались 0, байт $A5 был нетронут, и игра определила тёплый старт -- идеальное стечение обстоятельств, которое сработало только с теннисом.

Оригинальные видео Retro Game Mechanics Explained -- это потрясающий труд: уровень детализации по дизассембли 6502, автоматические карты всех уровней, объяснения cart swap и warm start. Если не смотрел серию -- посмотри, она короткая, и каждая минута насыщена.

Исходный код карт доступен на rgmechex.com, а полный дизассембл SMB1 -- open source на множестве репозиториев. 40 лет назад японские программисты написали эту систему уровней на 6502 с нулевыми юнит-тестами и нулевым баг-трекером, и мы продолжаем узнавать новое, разглядывая их код сегодня.