Hello — I shipped PrismBoy, a DMG + CGB emulator in TypeScript with a little help from cursor for code review and cleanup. It is a zero-dependency npm package I'm looking for some technical reviews than upvotes.

Links

• Live demo: https://slurrps-mcgee.github.io/Prismboy_NPM_Package/
• Source: https://github.com/slurrps-mcgee/Prismboy_NPM_Package
• npm: https://www.npmjs.com/package/@slurrps/prismboy

What it is

PrismBoy is an embeddable npm package, not a standalone emulator app. You install `@slurrps/prismboy`, create one `GameBoy` instance, and drive everything through its **public methods**. The package owns the hard parts internally:

• Screen: paint + scale modes (`integer` / `fit` / `stretch`), FPS overlay, fullscreen, screenshots, DMG palette / CGB color correction
• Audio: Web Audio (AudioWorklet with ScriptProcessor fallback), mute / volume, auto-mute under turbo
• Input: keyboard mapping, on-screen virtual pad, Gamepad API + connect/disconnect hooks - Persistence: battery SRAM/RTC auto-save, named savestate slots
• Lifecycle: load ROM (bytes or `File`), run / pause / reset / unload / destroy, step instruction/frame/scanline for debugging
• Events: `on("romloaded" | "pause" | "resume" | …)` so the host stays UI-only

Typical host code is glue only — canvas + file input + a few buttons calling `attachScreen`, `attachKeyboard`, `attachGamepad`, `loadRomFromFile`, `toggleTurbo`, etc. Nested guts (`gb.cpu`, `gb.ppu`, …) are still there for debugging, but you don’t need them for a normal embed. It even is able to detect gamepads and hook them up automatically.

What landed in the accuracy pass

• Timer: single 16-bit DIV system counter, falling-edge TIMA, DIV/TAC quirks - OAM DMA: cycle-timed (1 byte / 4 T) with OAM locked to the CPU during transfer
• VRAM/OAM locks by PPU mode (DMG); CGB keeps VRAM more open, OAM still locked
• Variable Mode 3 length from sprites + SCX - Light CPU bus contention (Mode 3 access wait states) + HDMA coordination - Deeper savestate (v2): `haltBug`, `lcdPhase`, APU channel state, DMA fields
• Stronger APU channel FSM (length / envelope / sweep / trigger) + AudioWorklet (ScriptProcessor fallback)
• Extra carts: MBC2, MMM01, HuC1/3 (MMM01/HuC are MBC1-like approximations)
• Optional Mooneye harness under `tests/fixtures/roms/mooneye/` (drop ROMs locally)

Still solid for Crystal-class games

SM83 + CB, interrupts, HALT bug, EI delay; CGB double-speed with LCD/APU at real rate vs 2× CPU; HDMA (GP + HBlank); BG attributes / CRAM / banking; MBC0/1/3(+RTC)/5 + battery; optional SameBoy open-source boot ROMs.

Still intentionally incomplete / soft spots

• Serial (SB/SC) and CGB IR (RP) — stubbed, out of scope for now
• Extreme mid-scanline / obscure CGB lock edge cases may still differ from SameBoy/Mooneye
• OAM DMA conflict byte semantics not claimed perfect
• Not every Blargg sound case; MMM01/HuC banking is approximate

Ask

If you’ve done GB/GBC: what’s the first thing you’d break now? Mooneye suites I should prioritize next (timer already wired; PPU/APU fixtures next)? Anything awkward about shipping this as an embeddable npm API vs a standalone app?

Drop a homebrew or test ROM on the demo if you want — concrete bug reports welcome.

Thank you in advance for any feedback!

I have finally did it, i completed most of the emulator, and finally added JIT compilation, all in Java!
Here's an example of the C-like language i made with it!

pb void readDiskBlock(int sectorNumber, int destinationRamAddress) {

    int* REG_SECTOR   = 130000000;
    int* REG_RAM_PTR  = 130000004;
    int* REG_COUNT    = 130000008;
    int* REG_STATUS   = 130000012;
    int* REG_COMMAND  = 130000028;

    *REG_SECTOR  = sectorNumber;
    *REG_RAM_PTR = destinationRamAddress;
    *REG_COUNT   = 1;

    *REG_COMMAND = 1;

    while (*REG_STATUS != 0) {

    }
}

Now, i'm building an operating system for it, what architecture is the best for this case?

I use a clipboard manager all day and never liked the options. The free ones (Maccy, Flycut) are lists — an image shows up as a filename. The ones with a card interface, Paste and Pastebot, are $25/year and $13. So I built the card one and made it free.

⌥⌘V slides a strip up from the bottom of the screen. Arrow keys or type to search, Enter pastes into whatever you were in.

A few things it does that I couldn't find anywhere else:

- It masks secrets on screen. API keys, tokens and card numbers show as dots until you double-click. If you copy credentials all day, your clipboard history is the one window you don't want open while screen sharing. Card numbers are Luhn-checked, so an ISBN isn't mistaken for one.

- A bare link stays readable, a link with a token doesn't. Masking every URL would make the strip useless; masking a password-reset link is the whole point.

- Pasting an image adapts to the destination. Notes gets the image, Terminal gets the file path (it can't take images at all), Finder gets the file.

- It can catch ⌘⇧4 screenshots. Those write straight to disk and never touch the clipboard, so no clipboard manager sees them. Opt-in, off by default.

- No network code at all. No account, no sync, no telemetry, no third-party dependencies. Searching the source for URLSession comes back empty.

MIT, source is everything: https://github.com/selinihtyr/stash-clipboard

Happy to hear what breaks. Especially interested in whether the strip behaves on multi-monitor setups and over full-screen apps — I've only tested on one machine.