← Blog

sigilOS Retro: N64 and CPS-1 on a Capability-Secure OS

June 22, 2026 · sigil-retropie · Sigil-Docs
retropie n64 cps-1 0.6.0

Two new systems joined the sigilOS RetroPie layer this week, bringing the launchable count to 37. System #36 is the Nintendo 64 — a full MIPS interpreter with VI framebuffer display. System #37 is CPS-1, the arcade hardware behind Street Fighter II and dozens of other Capcom titles, built almost entirely on top of the 68000 core that was already in the repo. Neither needed a new CPU implementation. That's the whole point.


System #36 — Nintendo 64

The N64 core (cores/n64.sg) runs a MIPS R4300i interpreter and bridges the VI (Video Interface) to a 320×240 ARGB framebuffer that the sigilOS compositor can blit. Each frame drives approximately 93,750 MIPS instructions through the interpreter loop, then walks the RDRAM framebuffer (big-endian RGBA8888) and converts it to the host pixel format.

What's wired

A correctness fix worth noting

Before N64 could ship, Sigil-Code caught a register-swap bug in the MIPS shift instructions. SRA (shift-right-arithmetic) and SRAV were both using RS as the value to shift instead of RT. The MIPS ISA is clear: RS is the shift-amount source in SRAV, RT holds the value. When RS happened to be zero — common in well-formed MIPS code — every arithmetic right-shift silently yielded zero. The fix was mechanical once identified (swap the variable), but it would have made any shift-heavy game code behave incorrectly. Test suite (n64_cpu.sg, n64_core.sg) now exercises both instructions directly.


System #37 — CPS-1

CPS-1 (Capcom Play System 1) is the arcade board under Street Fighter II, Ghosts 'n Goblins, 1942, and roughly 30 other titles. Its CPU is a Motorola 68000 — which sigilOS already had in cores/m68k.sg. The CPS-1 core (cores/cps.sg) is almost entirely a new bus and rendering layer around an existing CPU. That's a meaningful reuse story.

Memory map

RegionAddressSizeDescription
ROM$0000004 MBProgram ROM
GFX(separate)4 MBTile/sprite graphics data
RAM$FF000064 KBWork RAM
Palette$9000002 KB15-bit color entries
CPS-A regs$9A0000Scroll / layer control
IN0$800000Player 1 inputs

Rendering

The output framebuffer is 256×224, matching original CPS-1 hardware. Each frame runs ~167,000 68000 steps, then renders the BG1 scroll layer: a 32×28 tilemap stored in RAM is walked tile-by-tile, each tile decoded from the GFX ROM as 4 bits-per-pixel (128 bytes/tile, 2 pixels per byte), with colors looked up from the 15-bit palette (B5G5R5 → ARGB32). The result lands in a host framebuffer the compositor can display.

What's wired


Security model — the same for both

Both cores run as EL0 (unprivileged) capability-isolated processes. ROM loading uses the SECURE capability flag, which enforces a size cap (32 MB for Z64, 8 MB for CPS) and prevents the app from accessing anything outside its granted capabilities. The emulated hardware bus — RDRAM, CPS RAM, palette, registers — is all private to the core. No ROM content can reach the host OS or any other process. That's not a feature bolted on; it's what the sigilOS process model gives you by default.


Where we stand

The RetroPie layer now covers 37 launchable systems. The parity doc (docs/PARITY.md in sigil-retropie) tracks what's wired vs. what's still pending for each. N64 and CPS-1 are both fully checked off. Sprite layers (CPS-1 OBJ) and audio are the obvious next milestones for both systems — neither ships sound yet.

The MANIFEST for sigil-retropie sits at 0 FAIL across all regression tests, and both new cores have their own dedicated test suites exercising CPU correctness, framebuffer pixel round-trips, and core ABI contract before anything reaches the launcher.