Following N64 and CPS-1, three more systems joined the sigilOS RetroPie layer today, bringing the launchable count to 40. CPS-2 extends the Capcom arcade stack with a second scroll layer. CPS-3 pushes the 68000 into 32-bit address space as a 68020. And the Famicom Disk System hooks into the existing NES core without touching a single line of NES ROM emulation. The pattern across all three: reuse first, extend minimally.
System #38 — CPS-2
CPS-2 is the arcade board behind Super Street Fighter II Turbo, Dungeons & Dragons, and Marvel vs. Capcom. Like CPS-1, its CPU is a Motorola 68000 — the same cores/m68k.sg that was already in the repo. The new work in cores/cps2.sg is almost entirely a rendering upgrade over CPS-1: a second scroll layer with transparency.
What's new over CPS-1
| Feature | CPS-1 | CPS-2 |
|---|---|---|
| ROM size | 4 MB | 8 MB |
| GFX ROM | 4 MB | 8 MB |
| Palette entries | 256 | 512 |
| Scroll layers | BG1 (opaque) | BG1 (opaque) + BG2 (transparent) |
| Framebuffer | 256×224 | 256×224 |
BG2 transparency
The key rendering difference is BG2: a second 32×28 tilemap layer that composites over BG1. Pixels where the palette index is zero are transparent — the BG1 color shows through. This is implemented with a single branch in the shared c2_render_bg(map_base, sx, sy, transparent) function: when transparent=1, pxi=0 skips the pixel write. BG1 is rendered first (opaque), BG2 on top. The CPS-A register block at $9A0000 provides per-layer tilemap addresses and scroll X/Y offsets.
What's wired
- 68000 bus — 8MB ROM + 8MB GFX + 64KB RAM + 1024B palette + CPS-A regs + IN0 input
- Palette — 512 entries × 2B, 15-bit B5G5R5 → ARGB32
- BG1 + BG2 — shared
c2_render_bg, 4bpp tile decode, 32×28 tilemap, 256×224 scanout - EL0 app — loads
/roms/game.cps2(16 MB cap, SECURE capability) - Blob size — 38,496 bytes, 0 undecodable words
System #39 — CPS-3
CPS-3 is the hardware behind Street Fighter III and Red Earth. Its CPU is a Motorola 68020 — which is, for sigilOS's purposes, a 68000 with a 32-bit address space. The existing cores/m68k.sg runs unchanged. Unknown 68020 opcodes (MULS.L, bit-field instructions) fall through as NOPs per the existing convention. The new work in cores/cps3.sg is one meaningful delta: no 24-bit address mask.
The 32-bit delta
CPS-1 and CPS-2 operate in the 68000's 24-bit address space — the top byte of every address is masked. CPS-3 doesn't: the ROM lives at $00000000–$01FFFFFF (32 MB), RAM at $02000000, palette at $04000000. Removing the mask is the entire upgrade. The bus map:
| Region | Address | Size |
|---|---|---|
| SIMM ROM | $00000000 | 32 MB |
| RAM | $02000000 | 2 MB |
| Palette (LE) | $04000000 | 64 KB |
| Video regs | $04100000 | — |
The framebuffer is 384×224 — wider than CPS-1/2's 256 pixels. Each frame runs ~200,000 68020 steps, then fills the framebuffer with palette entry 0 as a backdrop. Full tile and sprite rendering are follow-on work; the core ABI, bus, and EL0 launcher are complete and PARITY.md marks CPS-3 launchable.
What's wired
- 68020 bus — 32-bit, no mask; ROM/RAM/palette/video-regs
- Palette — little-endian bus writes, 15-bit color
- Backdrop —
cps3_backdrop()fills 384×224 fb from palette[0] each frame - EL0 app — loads
/roms/game.cps3(32 MB cap, SECURE capability) - Blob size — 35,256 bytes, 0 undecodable words
System #40 — Famicom Disk System
The Famicom Disk System is Nintendo's 1986 floppy add-on for the Famicom. Its CPU is the same 6502 the NES uses. sigilOS already had a complete NES core (cores/nes.sg). The FDS core (cores/fds.sg) doesn't replace the NES core — it hooks into it.
first-def-wins
The cc0 linker resolves symbols by first definition. fds.sg is linked first, so its versions of the relevant functions win over nes.sg's stubs. nes.sg gains three things: fds_mode() / fds_reg_read() / fds_reg_write() stubs, and a 3-line guard in n6_read / n6_write that routes FDS register addresses to the FDS handler when fds_mode()==1. When the NES app runs (FDS mode off), that guard is a single comparison that falls through — zero overhead for all existing NES ROM emulation.
How disk streaming works
The FDS BIOS is loaded at $E000 in NES RAM — the same address it occupies on real hardware. Disk data streams through registers $4031 (read) and $4032 (status), which the FDS hooks intercept and serve from the loaded disk image. The EL0 app loads /roms/fds_bios.rom (8 KB) first, then /roms/game.fds (up to 256 KB).
What's wired
- BIOS load —
fds_load_bios()copies 8 KB ton6_mem[$E000] - Disk streaming —
$4031/$4032hooks serve disk data from the FDS image - Audio — FDS wavetable audio submitted via the audio seam
- Display — reuses NES VI: 256×240 framebuffer, same compositor blit path
- EL0 app — loads BIOS (8 KB) + disk (up to 256 KB), SECURE capability
- Blob size — 91,536 bytes, 0 undecodable words
The pattern
All three systems follow the same design principle: reuse the existing CPU, extend the bus and renderer. CPS-2 reuses the CPS-1 68000 and adds a second scroll layer. CPS-3 reuses the same 68000 with one change (drop the address mask). FDS reuses the entire NES 6502 and adds three register hooks. The only new CPU introduced to the RetroPie layer since the project started has been the MIPS R4300i for N64 and the ARM7TDMI for GBA (in progress). Everything else is leverage.
All three cores run as EL0 capability-isolated processes. ROM and disk images are loaded with size-capped SECURE capability tokens — no game content can reach the host OS or any other process.
Where we stand
The RetroPie layer now covers 40 launchable systems. MANIFEST sits at 289 entries, 0 FAIL across all regression tests. Neo Geo is in active development — the header parser and C-ROM deplanarizer (sprite tiles) landed today as a second pass on that core.