sl0pboy - a Game Boy Color emulator (companion to the gbos OS) https://git.sl0p.foo/sl0pboy.git/atom/Makefile?h=master 2026-09-22T18:48:09Z 2026-09-22T18:48:09Z gbc dev gbc@localhost 2026-09-22T18:48:09Z urn:sha1:a2aa8fbb20cab296d44bcdd23c63c0f76ec52869 zig defaults the wasm stack to 16MB, and that lands in the module's *initial* memory, so every instance allocated 16.25MB before executing an instruction. With several Game Boys on one page that was the dominant cost: 123MB for six. The machine is a static and nothing here recurses deeply, so 256KB is plenty. Per instance: 20.5MB -> 4.8MB of linear memory (six: 123MB -> 29MB). Note the spelling - zig cc rejects -Wl,--stack-size and -zstack-size, and wants -Wl,-z,stack-size=N. With memory no longer the constraint, the page cap goes 6 -> 8 on measurement rather than guesswork. Emulation-only, one thread: 12.5x realtime at 1, 3.1x at 4, 1.5x at 8, and exactly 1.0x at 12 - i.e. ~12 is where a thread runs out of road with nothing left for rendering. 8 holds a verified 60fps each in a real browser with all eight leased. Golden frames are still pixel-exact on cgb-acid2, dmg-acid2, cpu_instrs@600 and pky@400 with its .sav, and two Game Boys still lease and ping 4/4. 2026-09-22T13:57:06Z gbc dev gbc@localhost 2026-09-22T13:57:06Z urn:sha1:6fb4fbbce99c08bd535d1b7e0f356864fb0c38a0 `make wasm` builds the core to WebAssembly (~44KB stripped) and web/ is a front-end for it: drag-drop a ROM, pixelated canvas at any zoom, keyboard mapped like the native build, battery saves in localStorage. Built with zig cc, which carries its own wasm backend, linker and wasi-libc - so no emscripten dependency, just zig on PATH. Only the portable core goes in; render/kitty/control/main are terminal- and POSIX-bound and stay out. src/wasm.c is the browser's whole host layer: no terminal, no sockets, no files, and no frame pacing (the page's requestAnimationFrame owns that). The machine is static, the RGB888 -> RGBA conversion for putImageData happens in wasm, and nothing allocates per frame. The entire host interface is four WASI fd_* imports, pulled in by the cart info banner's fprintf; the page shims them to console.log in ~20 lines. Cartridge RAM *is* the save file here, so it's exported for the page to persist per cart title (every 5s and on unload). Because both builds now advance on the same frame boundary, the port is checked byte-for-byte against the native binary rather than by eyeballing a canvas - tools/wasm_check.mjs runs N frames in node and diffs the framebuffer against a --shot PPM: cgb-acid2 @60, dmg-acid2 @60, cpu_instrs @600, mem_timing-2 @700, pky.gbc @400 with an imported .sav, cgb-acid2 @120 through the full CGB BIOS boot animation -> all pixel-identical Also smoke-tested in headless chromium over CDP: core instantiates, ROM loads through the file input, canvas animates (7 distinct frames over 5.6s), keyboard reaches the joypad, 60fps, and a 32KB save lands in localStorage. No audio: the APU is still stubbed. 2026-07-16T23:08:48Z gbc dev gbc@localhost 2026-07-16T23:08:48Z urn:sha1:c714fc8927c454b5cf4735429b4cc9cde7aa5760 2026-07-04T20:12:57Z gbc dev gbc@localhost 2026-07-04T20:12:57Z urn:sha1:5800f04eb0417c980fef2eddd78d8b60d19d0db5 2026-07-04T20:05:31Z gbc dev gbc@localhost 2026-07-04T20:05:31Z urn:sha1:0d0f4f1d23851c0c34e518834f7d316e61dec1f3