HiROM 32 Mbit Cartridge Test

Cartridge & Mapping Tests

A 4 MiB HiROM cartridge (map mode $21) that checks its own address decoder from the inside. HiROM maps a full 64 KiB per bank across $C0$FF, with the upper halves mirrored into $00$3F so an unmodified boot path still runs. This is the ordinary-map baseline the extended (ExHiROM) cartridges build on — and the ceiling: 64 banks × 64 KiB is exactly 4 MiB, and there is no bank left for a 129th.

loading core…

Self-running — no controls. The screen turns green when every canary, mirror and span read the byte the model predicted, red if any did not. (It spends a few seconds folding spans before the verdict appears.)

Click the screen, then play. (Tab away and it pauses.)

The mapping

map mode      $21  (HiROM, slow ROM)
header        file $00FFB0
image         4,194,304 bytes  =  32 Mbit, one mask ROM
window        $C0-$FF:0000-FFFF   <- file $000000-$3FFFFF   (full 64 KiB banks)
mirrors       $00-$3F / $80-$BF upper halves ($xx8000-$xxFFFF)
holes         none

Because $00:8000$FFFF mirrors $C0:8000$FFFF, the reset vector at $00:FFFC reads file $00FFFC and an unmodified crt0 boots exactly as it would on LoROM. Note the mirror is upper-half only: the low half of every bank below $C0 is not cartridge at all.

ROM map

Every half-bank cell the decoder maps, generated from tools/snes_cartmap.py: the canonical $C0–$FF windows, their upper-half mirrors at $00–$3F/$80–$BF, and banks $7E/$7F handed to WRAM.

HiROM 32 Mbit Cartridge Test — CPU bank decode mapmapping hirom (map mode $21, slow ROM) — ROM 1 = 32Mbit @ file $0000000123456789ABCDEF$00$10$20$30$40$50$60$70$80$90$A0$B0$C0$D0$E0$F0ROM 1 canonical — 32Mbit @ file $000000–$3FFFFFROM 1 mirror — same bytes, alternate CPU addressWRAM ($7E/$7F) — hard-wired, never cartridgesystem area / I-O — bank low half below $C0, not cartridge512 half-bank cells (256 banks × 2 halves): 380 decode to cartridge ROM (128 canonical +252 mirror), 4 WRAM, 128 system-area.canonical windows$C0-$FF:0000-FFFF <- file $000000-$3FFFFF (ROM 1)

What it checks

CheckWhat it proves
5 canary bytesThe first and last byte of every decoded CPU window, every physical mask ROM, and each 1 MiB divider — each read through a 24-bit far pointer (lda [dp]) and compared against the byte the host model says lives there
2 mirror probesEach accepted mirror returns the same byte as its canonical window. The padding pattern is a non-linear hash of the full 24-bit file offset, so a decoder that folded a mirror to a different offset is caught immediately
2 folded spansByte runs crossing one 64 KiB CPU bank, several banks. Each is walked as an ordered list of bank-bounded segments, re-establishing the bank byte at every segment start — never by incrementing a pointer across a boundary
Rotate-add foldThe oracle is order-sensitive and non-linear over GF(2). An earlier XOR fold over an XOR-linear pattern collapsed to $0000 — and to $0000 for the wrong bank too, proving nothing. A bank off-by-one, a flipped byte, a dropped byte, a duplicated byte and a reversed order each change it

How it is built

Every address this ROM tests comes from one authoritative host model, tools/snes_cartmap.py — a direct port of the bsnes-jg cartridge bus (Database/boards.bml plus Bus::map/mirror/reduce), not a paraphrase of a wiki page. A host test greps the vendored boards.bml so a transcription drift fails on the desktop instead of in an emulator. The linker script, the canary addresses, the segment lists, the expected bytes and the final oracle are all generated from that model; the C source contains no addresses of its own.

The model exposes the two directions deliberately asymmetrically. decode(bank, addr) is mirror-aware emulator truth. file_to_cpu(offset) returns only the one canonical CPU address and raises on an addressing hole. A descriptor that named a mirror would still read the right byte — which is exactly the bug class this cartridge exists to catch — so the emitting side is restricted and the reading side is permissive.

Written in C with the llvm-mos 65816 toolchain under +mos-a16 (a runtime far pointer is a 32-bit value, so the cross-bank cursor needs native 16-bit mode). Hit Verify fidelity to reproduce the build gate's WRAM assert live in this tab — the same oracle the host model and the cycle-accurate bsnes-jg core agree on.

ROM SHA-256 e805fca62371926555120b074297426e41ef31730e9f3fe0ce5231eb018f4e0f. Verified on bsnes-jg (native and this in-browser core). MAME was not available on the build machine — it needs the SPC700 IPL, which is not distributable — so the emulator evidence here is bsnes-jg only.