Zero Star: SNES Hardware Architecture Deconstruction

🏛️ SNES Hardware Architecture & Memory Allocation

The Super Nintendo operates as a multi-domain architecture with isolated processing cores, non-uniform memory maps, and dedicated coprocessors. Developing *Zero Star* required splitting memory workloads precisely between Work RAM Banks, Video RAM, and Audio RAM without software abstractions.

Hardware Domain Diagram Click any block to inspect technical specs

MAIN CPU DOMAIN

Ricoh 5A22 Core

65c816 @ 3.58 MHz

Allocated Memory:

WRAM Bank $7E (64 kB)

WRAM Bank $7F (63 kB)

DISPLAY DOMAIN

Dual PPUs (PPU1 / PPU2)

Background Mode 1

Dedicated Graphics:

64 kB Video RAM (VRAM)

544 B Sprite Metadata (OAM)

512 B Palette Memory (CGRAM)

AUDIO SUBSYSTEM

Sony SPC700 Core

8-Bit CPU @ 1.024 MHz

Isolated Audio:

64 kB Audio RAM (ARAM)

16-Bit 8-Voice DSP

4x I/O Registers ($2140-$2143)

👉 SELECT A DOMAIN ABOVE TO INSPECT TECHNICAL SPECS

Click on the Main CPU Domain, Display Domain, or Audio Subsystem block to analyze memory layout, bus boundaries, and core hardware register allocations.

Console Memory Budget

Total addressable hardware RAM distribution (256 kB Total)

Bank $7F explicitly holds the uncompressed 63 kB dungeon playfield.

📹 Video Structure & Technical Chapter Roadmap

The video deconstructs nine core engineering stages, mapping each gameplay design goal to specific SNES hardware registers and assembly routines.

⚡ Dynamic SNES Hardware Calculators & Interactive Simulators

Interact directly with the math and register manipulations used in *Zero Star* to bypass hardware limits. Test spatial hashing, CRT scanline HDMA parallax, packed BCD math, and sound channel stealing in real time.

01. Constant-Time O(1) Spatial Hash Grid

Bank $7F Map

Traditional pairwise collision ($O(n^2)$) exhausts the 3.58 MHz CPU. *Zero Star* treats the 63 kB uncompressed tilemap in Bank `$7F` as a direct spatial hash grid, using fast bit shifts to resolve terrain collisions in $O(1)$ constant time.

X Tile Coordinate (0-191):

Y Tile Coordinate (0-167):

FORMULA: Base ($7F:0000) + (Y × 192) + X

Bitwise Shift: (32 << 7) + (32 << 6) + 48

Absolute RAM Address: $7F:1830

Execution Cost: 12 Clock Cycles ($O(1)$)

💡 Why 192 tiles width? $192 = 128 + 64 = (2^7 + 2^6)$. Multiplying by 192 reduces to two fast bitwise arithmetic shifts (`ASL`), eliminating runtime multiplication instructions entirely!

02. HDMA Scanline Parallax Modulation

Register $2111 (BG3HOFS)

Standard V-Blank DMA shifts entire layers uniformly. Horizontal Blank DMA (HDMA) executes micro-transfers during the 15µs scanline gaps, updating scroll offsets line-by-line with zero CPU overhead.

CRT Beam Scanline Position: Scanline 110 / 224

Scanline 1 (Sky) 120 (Peaks) 160 (Playfield) 224 (HUD)

Active Display Layer: BG3: Mountain Peaks (2bpp)

HDMA Register Injection: $2111 Write Value = 12 px

Visual Parallax Offset: dx × 0.25 (Slow Scroll)

[ ▲▲▲▲ MOUNTAIN PEAKS PARALLAX SHIFT: 12px ▲▲▲▲ ]

03. Packed BCD Hardware Decimal HUD

SED Flag Arithmetic

Converting raw binary integers to base-10 strings via software division requires ~320 cycles. By storing HUD tallies (chickens killed, level depth) in Packed BCD and setting the 65c816 decimal flag (`SED`), standard `ADC` operations handle multi-digit carries automatically in zero extra cycles.

Chicken Kills Metrics:

0482

Packed BCD Bytes: $04 $82

Hardware Nibble Encoding: 0000 0100 | 1000 0010

04. SPC700 Dynamic Sound Stealing

8 DSP Channels

The SPC700 audio processor runs independently with 64 kB ARAM. Dr. Matt's music engine uses 5 polyphonic voices, leaving 3 channels reserved for dynamic gameplay sound effects. When dynamic SFX fire, the custom driver steals music channels cleanly and restores them post-playback without audio clicks.

Trigger Gameplay Sound Effect:

8-VOICE DSP HARMONIC CHANNEL MATRIX

📊 SNES Hardware Bottlenecks vs Low-Level Software Solutions

A comprehensive matrix detailing how physical hardware limits were bypassed through custom assembly engineering and mechanical sympathy for the console's architecture.

Hardware Subsystem	Physical Silicon Bottleneck	Software Assembly Solution	Engineering Impact

🔌 Physical Silicon Verification & Engineering Principles

Moving from high-accuracy software emulators (Mesen, bsnes) to real hardware cartridges exposes physical electrical quirks, cold-boot states, and critical lessons for modern constrained engineering.

⚠️ Real Silicon Hardware Divergence

1. Power-On Uninitialized SRAM Noise

Modern emulators often default uninitialized RAM to clean zero states (`$00`). On authentic retail consoles, powering on SRAM cells creates random garbage bit patterns. *Zero Star* required an explicit boot-clearing loop to wipe WRAM before executing game logic.

2. Bus Floats & Ungrounded Lines

Unconnected or floating data lines on physical cartridge PCBs can read ghost register values or produce phantom inputs during CPU reads. Thorough hardware testing on Mouse Bite Labs PCBs ensured strict line grounding and signal stabilization.

3. Color Math Hardware Inversion

Direct sub-screen color subtraction registers (`$2131`/`$2132`) allowed single-frame hit-stop black flashes and elemental spell bursts (Fire, Ice, Gold, Peach) without wasting precious V-Blank bandwidth to reload CGRAM palettes.

💡 Key Embedded Engineering Takeaways

Compiler Limits on Non-Orthogonal CPUs

Modern compilers target architectures with broad, uniform register sets (ARM, RISC-V). Compiling high-level C for accumulator-bound CPUs like the 65c816 introduces severe register thrashing and stack bloat. Hand-assembly unlocks platform-specific features like the `SED` decimal flag.

Mechanical Sympathy & Coprocessor Offloading

High performance on constrained silicon is achieved by delegating workloads to hardware sub-units: HDMA handles raster scrolling, PPU color math executes screen FX, and the SPC700 APU runs 8 audio channels completely independently of the gameplay loop.

Deterministic Memory Isolation

Separating procedural playfields (Bank `$7F`) from stack frames and entity arrays (Bank `$7E`) prevents heap fragmentation and guarantees infinite procedural dungeon scaling within 129 KB ROM bounds.