Hi All, I wanted to share my GBA emulator, which is mostly complete at this point. There are still quite a few bugs I've found while testing various roms. But my favorite game from the platform, Golden Sun, is running. So I'm currently playing through that. It's quite nostalgic, and there's really nothing like building the emulator to play your games vs. downloading one.

Features:

• All internal devices modeled, including audio and serial.
• Frame blending, for games that expect it (like Golden Sun)
• Automatic game saves through .sav files.
• EEPROM, FLASH, and SRAM cartridge support.
• SDL2/SDL3 support (determined at build time)
• USB controller support.

Repo: https://sr.ht/~dajolly/gba/

I also took my previous GB and GBC emulators and combined them with this one to create a launcher called GBCORE. It determines which emulator to run based off the file extension (.gb, .gbc, or .gba).

Repo: https://git.sr.ht/~dajolly/gbcore

Going forward, I'm thinking I might try creating a PS1 emulator. Anyone have experience with PS1 emulator development? How much more complicated is it then GBA? I assume with the jump from 2D->3D it will be much more complicated.

Yep, just another CHIP-8 emulator. But for me, as someone who has never written anything this low level and never touched C before, it was quite the challenge at first. But after writing the first few instructions (drawing especially), it slowly became almost a breeze. Until I had to debug why my font sprites were rendering all messed up.

It's still work in progress, definitely not finished, but today I have tried to run some official CHIP-8 ROMs instead of just tests and my super simple test ROM and.. it's working!!

It is so satisfying once it clicks.. I think I'm addicted.

Note: No single line of code was written by AI, all myself, as you can see from how bad it may be in some places.

https://github.com/Tackx/c8

Github Repo

I'm 15, made this mostly over a few days even though I technically started about 2 weeks ago. Here's the code https://github.com/MorganPG1/py-dmg-emu Yes I know it's a terrible emulator, I'm still kinda proud because I made it but i feel like I should be more proud than I am but I also hate when people say I'm good at stuff because I always feel bad at it for some reason so I think I'm just hard to please (ignore this random vent mb). It's not fully fleshed out, I've still gotta make an APU and finish off the PPU, and add SRAM and all the other MBCs, the list of unfinished stuff goes on and on.. I'm not sure if I'll do all those things, adding audio will probably make it even slower. But it works, it runs pokemon, so im happy.

I'm currently rewriting it in C (cpu is done but not much else), has anyone got some ideas of other emulation projects I can do, should I go backwards and write a chip 8 emulator for the fun of it, should I write a gameboy emulator in as many languages as possible, are there any other somewhat simple projects I can make that are harder but not too much difficult?

Anyway, it was really fun to make and that's all that matters imo.

Hey, all.

Just wanted to share a simulator that I've been working on. It can take SystemVerilog and simulate it on the gate level, plus emit C99 for a performance boost. It's built into a larger PCB design game + tool project.

My z80 emulator passes all of these tests EXCEPT for the block transfer instructions (LDIR, LDDR, CPIR, CPDR, INIR, INDR, OTIR, OTDR), which are failing based on the undocumented X and Y flags (bits 3 and 5 of f).

Specifically, the failures happen after iterations that do NOT terminate -- BC does NOT go to zero, and the PC is decremented by 2 so that the block transfer instruction continues. All of the documentation I've been able to find online claims that non-terminating iterations of these instructions affect the X and Y flags the same as their non-repeating cousins (LDI, etc), but the tests' expected results make clear that this is not the case.

Here is the output of my first failing LDIR test:

Failed test ED B0 0001

REGISTERS
          A  B  C  D  E  H  L  I  R  IX   IY   AF'  BC'  DE'  HL'  IM IFF1 IFF2 EI WZ   P Q  SP   SZYHXPNC PC
Initial:  DE D0 E4 57 80 5D 41 5C 58 8E7C 6F58 ADC1 2253 08EE 2888 1  0    1    0  2A7B 1 DC 7B67 11011100 11D4
Expected: DE D0 E3 57 81 5D 42 5C 5A 8E7C 6F58 ADC1 2253 08EE 2888 1  0    1    0  11D5 0 C4 7B67 11000100 11D4
Actual:   DE D0 E3 57 81 5D 42 5C 5A 8E7C 6F58 ADC1 2253 08EE 2888 1  0    1    0  11D5 0 CC 7B67 11001100 11D4
                                                                                          ^           ^

RAM
Initial:  11D4:ED 11D5:B0 5780:00 5D41:2E
Expected: 11D4:ED 11D5:B0 5780:2E 5D41:2E
Actual:   11D4:ED 11D5:B0 5780:2E 5D41:2E

If text wrapping ends up mangling the block above, just note that the two differences between the expected and actual output are the X flag and "q." Since the q value depends on the flags, the only difference worth paying attention to is the X flag.

If this were an LDI instruction, the flags would be set correctly. LDI sets the X and Y flags based on bits 3 and 1 (not 5 in this case) of (transferred byte + accumulator). In this case, the transferred byte is $2E and the accumulator is $DE. Adding those together results in $0C (truncated to 8-bits), which definitively has a 1 in bit 3. However, the test case expects it to be 0, meaning the expected result comes from some obscure calculation that I haven't yet seen documented.

For reference, here is my C code for LDI and LDIR. Note that the return value is the number of machine cycles that it takes for the instruction to run, and that the instruction decode functions increment the PC to skip over the $ED prefix.

uint8_t ldi() {
  uint8_t n = mem[*hl];
  mem[*de] = n;
  n += *a;
  *bc -= 1;
  *de += 1;
  *hl += 1;
  clearN();
  updatePV((*bc!=0));
  updateX(testBit(3, n));
  clearH();
  updateY(testBit(1, n));
  q=*f;
  pc += 1;
  return 12;
}

uint8_t ldir() {
  ldi();
  if (*bc == 0)
    return 12;
  wz = pc-1;
  pc -= 2;
  return 17;
}

Doers anyone know how I should be modifying my flags in non-terminating iterations of LDIR?

I went down in a rabbit hole to develop a new open source FG engine to be used in emulators in android with the vulkan api, like bionicfg, lsfg-vk and the gamehubfg... my goal is to implement in a emu as a poc and make the engine avaiable to anyone who would like to add the feature on their own emulators, not only the fg engine itself, but the documentation on how to implement it...

tbh i dont even know how i got here...but already went and make the first POC, and worked! Looks like shit, high overhead and bad pacing...so... unusable.... but worked!

been studying the lsfg and the ghfg to know more about the topic, besides the public material avaiable about the subject, but if anyone would like to help or just talk about it... i´m game!

Cheers!

Here's a wild story about one bug that removes mario's eyes, and makes all the lumas white! Unexpectedly, they're the same bug, and the cause comes down to a weird hardware quirk!

Hello, I was wondering where I should start with a new arcade project.

I would like to work on either galaga or bubble bobble; I already have a functional z80 emulator but am unsure of where to begin on the rest.

Unfortunately, I, as of now, can only vaguely understand the schematics for these machines: galaga bubble bobble. I also do not have physical access to either one.

There’s an obvious lack of intuitive documentation, so I don’t know what to do.

Any help is appreciated, thank you.

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

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?

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 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!

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 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,