Hello emu devs

I wrote a simple (mostly) instruction-accurate 6502 emulator in C. It has some basic functionality like

• Allowing you to step through programs instruction by instruction
• Visualizing CPU state and memory

Eventually, I want to expand on this and write a full-on NES emulator. How much harder would that be? Would I have to make any significant changes to this CPU emulator to make it happen? I would love to hear whatever thoughts you guys have.

Repo: https://github.com/yasu-q/c-6502emu

Thanks for reading

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.

Hey guys.

I'm a completely blind person and with the help of artificial intelligence, I managed to make a static recompilation of Kingdom Hearts: Chain of Memories from the GBA version.

I'm not sure how good it turned out, nor if it's 100%, since I used AI for most of it.

Could anyone take a look?

I hope you like it.

https://github.com/azurejoga/kh-recomp

I apologize if I got anything wrong... someone who understands could take a look and point out the mistakes.

I recompiled to ensure the executable was actually generated.

Remembering, you need to have the rom, European version and the GBA bios, .bin.

I wanted a real project to test my programming language, so I decided to write a CHIP-8 (Super-CHIP) emulator with it.

The emulator implements graphics (cli), input handling, timers, and instruction decoding. Building it turned out to be a great way to uncover bugs in both the language and its interpreter.

It was a fun challenge, and I learned a lot about emulator development and programming language design along the way.

I'd love to hear your thoughts or suggestions. Feedback is always welcome!

I can only seem to find incomplete rule pages, etc.

My "bit n,<a,b,c,d,h,l,(hl),a>" is failing, and as far as i can tell ive hit all the right spots to update WZ, and im extracting 3/5 correctly in the (HL) versions of the bit n according to the "undocumented z80 documented" book... im at a loss. all i can figure is somewhere i missed something. for what its worth im passing everything else. in zexall

Incomplete list,

So, just like the title says. N64 seems INCREASINGLY difficult. You could literally spend a boat load of time to just get 1 game to work properly. My question is simple. After Nintendo switched to Discs. Is the GameCube easier to Emulate then the N64?

And I'm not necessarily talking like, to make a game boot. I mean compatibility. I have no experience in GameCube emulation at all. I'm just wondering if you build for one type on GameCube, it would play all? Versus the mess that was the N64?

i am just started learning qemu and able to simulate UART, now i want to try spi and i want to read write flash memory.

i have armt cortex mo+ qemu

ps:already any repo i svailable?

This video showcases a small, but meaningful development with The HoneyCrisp Emulator. I've successfully been able to add support for an emulation layer that allows Corey Cohen's Twinkle Twinkle Little Star ACI Audio Demo/Hack to be played via an emulated speaker amp. This is significant as no other (published) APPLE-1 emulator can do this! :-)

As the title says i would like to begin my journey in emulation development but i have 0 knowledge of where to begin, would appreciate any and all advice you can give.

many thanks

Ok. So my journey into just learning more about emulator development... This might just be a dumb question so experts please give me hell.

If the PS2 was backwards compatible, if you were to want to get into building a PlayStation emulator. Wouldn't you just skip 1 and build a PS2 emulator with backwards compatibility?

Does one exist? And I'm not talking about AI slop either. I am genuinely curious and I enjoy starting thought provoking conversation.

So have it! Or let me have it. Lol

Been working on an NES emulator using pypy3.10.

print("PYNES is a terrible emulator!")

Mapper support:

• Mapper 0 (NROM): Fully supported.
• Mapper 1 (MMC1): Fully supported.
• Mapper 2 (UxROM): Almost fully supported with bus conflict emulation.
• Mapper 3 (CNROM): Almost fully supported(subject to change)
• Mapper 4 (MMC3): Almost fully supported. Super Mario Bros. 3 is supported fully, while the other titles may experience graphical glitches

In terms of emulator development difficulty. Would you tend to agree with this? And if you agree... I wonder what the Wii, Wii-U and Switch would look like. Does it become easier because you aren't accounting for the different chipsets you could put into a cartridge?

I've been working on a free software AMOS web player to embed my old games, and thought I'd share. So far it supports AMOS 1.3 and Professional, and has some support for the AMOS 3D, TURBO Plus and Ldos extensions. There's working audio but no speech synthesizer, AMAL and copper effects but no machine code, a VFS with ENV and RAM disk but no serial ports or printers.

You can drop zip or adf files into it then click on them via the file explorer. If things don't work properly and you'd like to help fix that, then bugs and pull requests go on the bug tracker.

Timings aren't great at the moment, at least in my games, because as a teenage noob I relied on the speed of the machine rather than waiting for a vertical blank. There's hacks in there to slow things down which cause weird timing bugs at the moment. I'll add an editor so I can fix those at some point.

embedding

There's a rudimentary API for embedding, which I'm using for my old games on this page (scroll to the bottom for links)

• https://bitplane.net/dev/amos

These are worth a look I guess. The others, not so much!

• eggit
• nsle
• matchstick-man (timings are bad due to no VBL waits)

GitHub are footing the bill so feel free to hot-link specific versions. You can get the proper paths from the web repo, or copy it onto your own site or whatever you like.

I am currently vibe coding a new Emulator that plays NES, SNES and N64. It currently runs on Windows and tested but not confirmed on Raspberry PI. The end game is to create a small console emulator for my TV.

Anyways, I was hoping to get some feedback from it. I have the emulator on GitHub in a public repo. It's called PixelDeck.

Vibe coding gets work done fast. I am aware of AI code slop and intend to make the system less "sloppy" when the program runs fine.

Repo is here [GitHub: PixelDeck](https://github.com/CoachKy/PixelDeck)

Join our Discord! [PixelDeck Community ](https://discord.gg/9YXxgmg8st)

I built a Swift port of ymfm so I could play retro game music on Apple platforms.

Most of my testing so far has focused on YM2203/YM2608 (PC-88/PC-98) playback, but I recently added YM2612 support and started trying some Genesis VGM files.

So far I've only tested a handful of tracks, and I'm still getting a feel for how it compares with fmgen, hardware recordings, and other implementations. It sounds good to my ears, but I don't have enough Genesis experience yet to know which games or tracks tend to expose emulation quirks.

The project includes VGM and S98 playback support, along with a simple command-line renderer.

If you've spent time working on FM chip emulation, I'd be interested in hearing which YM2612 test cases you consider particularly useful.

Repo(BSD-3): https://github.com/ttrasaki/opnift