System #75 is WASM-4 — and it's the first sigilOS "console" that runs a portable bytecode VM rather than emulating real silicon.
wasm_interp.sg increment 3 — host draw API (6e18af8)
The WASM-4 interpreter core gains the host draw API, so real carts actually render. WASM-4's fantasy-console surface — the framebuffer, the palette, the draw primitives (blit, line, rect, text) — is now wired through to the Lumen compositor. A cart that draws is a cart you can see.
el0/wasm_app.sg — the EL0 launcher (fcf798b)
The piece that makes it usable: wasm_app.sg loads /roms/wasm/demo.wasm (64 KB, fetched through a cap via fs_resolve + fs_read), core_loads it into the interpreter, and exposes a launcher card in the Lumen UI. Users can pick a WASM-4 cart and run it — it executes as a capability-scoped EL0 app, exactly like any other sigilOS process.
That's the SECURE story for WASM-4: a downloaded .wasm cart is untrusted code, so it runs inside the EL0 capability boundary. It sees its 64 KB linear memory and the host draw API it was granted — nothing else. No filesystem, no network, no ambient authority.
BIOS + save-state UI (7e8cf20, 20a9df7)
Two supporting surfaces shipped alongside:
bios_ui.sg— a BIOS Management panel:fs_resolvescans for installed BIOS files and a Lumen status panel shows which systems have their BIOS present (and which are missing one).savestate_ui.sg— an 8-slot save-state grid with thumbnail capture. Each slot shows a snapshot of the frame at save time.
WASM-4 brings the parity roster to 75 systems. It's also a proof point for the capability model: portable untrusted bytecode, sandboxed at the EL0 boundary, drawing through a granted host API — the same confinement that isolates a browser renderer or a USB-quarantine sandbox, applied to game carts.