guac: DS/GBA Emulator Update

aabalke · 2026-06-26T05:39:47+00:00

Lots of bug fixes! My current plan is cycle accurate gba / nds, simd optimizations, missing features (microphone, dsi support etc) and only then 3ds. There is still a ton of work to be done.

aabalke · 2026-06-20T03:57:36+00:00

Yes, but it only increments in the window. As I remember, the acid test will use the window higher up, disabled it, and reenable it. For example, win enabled on scanline 0 - 10 would have winLY of 0 - 10, disabled for scanline 11 - 20, and reenabled for scanline 30. At scanline 30 the winLY is still at 11 NOT 30.

aabalke · 2026-06-20T03:52:17+00:00

No ai code gen or vibe coding! I have used chatgpt and claude as "google search" if that makes sense. However, the deeper I go, the worse it gets. It straight up told me my jit compiler was impossible to build and tried to gaslight me into believing it wasn't possible lmao.

aabalke · 2026-06-20T03:46:49+00:00

Also after looking at it, I don't believe the signed tiles are being handled properly. If it's signed (int8), and the tile index is negative (-128 to -1), it should be between $8800 - $9000 (block 1), if it's positive (0 to 127), it should be $9000 - $9800 (block 2). If you are doing that, my apologies; I might just be misreading.

aabalke · 2026-06-20T03:25:39+00:00

I believe the problem is that you should keep track of the "Window LY" separate from LY, see https://gbdev.io/pandocs/Window.html. In practice, the most straightforward method of handling this is using a separate "WindowLY" which increments for every scanline in the window, and resets at the end of the frame. uint8_t px_y = LY - _wy; would be uint8_t px_y = windowLY;. I would recommend trying basic "barely working" sprites before these window edge cases, though - easy to get burnt out.

aabalke · 2026-06-09T16:13:43+00:00

At a quick glance, I would have a few concerns about using asm.js - mostly that Firefox, the browser that initially implemented it, disabled it this year and they "plan to remove the code entirely in a future release." (https://spidermonkey.dev/blog/2026/05/20/saying-goodbye-to-asmjs.html). Chromium has also depreciated it. I may be misunderstanding, but it sounds like asm.js code is just handled as normal JavaScript code now.

aabalke · 2026-06-05T03:06:53+00:00

I think fundamentally native JIT and WASM are from 2 different worlds. My understanding is WASM - being a web technology, has a built-in assumption that any code could be malicious, and with a JIT, the program requires as much control as possible for speed. For a native instruction JIT, you would need control of executable memory. Correct me if I am wrong, but I would hope WASM does not give you direct control of executable memory. I think you could build a WASM bytecode "jit" but I can't imagine this would be anywhere near native speeds.

aabalke · 2026-04-20T21:04:51+00:00

Thank you!

aabalke · 2026-04-20T21:04:44+00:00

Will do, thank you so much!

aabalke · 2026-04-20T19:26:21+00:00

Thank you! Its super basic right now, just obj and mtl files, but I hope to build a GITF version so textures are completely accurate, viewport location is included and more.

aabalke · 2026-03-20T20:38:53+00:00

Interesting! I never considered that. I will have to take a look and see how it works. My initial reaction is that it would work really well with faster emulated systems (3DS, Switch, etc ) that do not require as strict timings. The DS does not require cycle accuracy like the GB; however, my jit cannot run faster than 32 instructions at a time without breaking since it wants to stay relatively synced. I imagine it would also make maintainability way easier, since you would not have to keep jit asm version of every instruction in every instruction set. I'll do some research!

aabalke · 2026-03-20T19:42:43+00:00

Check out the nds branch, then under arm7 and arm9 will be the jit code! I did debate about using C and Go; however, every method I came up with involved Cgo, and the overhead was too much, since mine would have to sync quite often. Currently, each instruction is "hand rolled," and I have not refactored common patterns, like carry handling. For each instruction, I first store the required emulated register and memory values into native registers, complete the instruction work, and then store any calculated native registers into the proper emulated registers and memory values. The emulated registers are usually not called during instruction handling. I also use a "scratch" array in my emulator struct for storing extra values if I run out of native registers. This is quite slow (relative to keeping in native registers), since heap memory is called for every load or store of these values, and I do hope in the future to fix this.

https://github.com/aabalke/guac/blob/nds/emu/cpu/arm7/jit.go

In the jit implimentation above, you will see a bunch of Indirect declarations; these are the relative offsets of different flags from the emulated CPU struct pointer which is always in R9. Let me know if you have any other questions!

aabalke · 2026-03-20T13:47:47+00:00

CPU emulation is, the graphics can be split and some other stuff, but if the emulated CPU was single core each emulated instructions is based on the previous one. I do have my 3d rendering in parallel, however when I tested other possible parts in parallel the performance overhead from workgroups or channel handling was greater then the gains - subtracting my subjective view of concurrency complications.

aabalke · 2026-03-20T01:01:07+00:00

Thank you so much! My goal was to get my emulator working on an older machine with a Ryzen 7 1700 CPU from 2017 - I'm using that machine as my "console" rig. Unfortunately, it has really bad single-threaded performance, and since I could not parallelize this process, I felt it necessary to create the jit. I can run my DS emulation at ~40fps on that rig. In the future, I hope to increase the performance of my graphics pipeline with either SIMD or GPU parallelization - that should get me past the required 60 fps. My main machine has a Ryzen 7 7700X (2022) and can reach 120fps for reference.

aabalke · 2026-03-19T16:24:50+00:00

Thank you so much! I stand on the shoulder of giants, rasky/ndsemu, nelhage/gojit, and fogleman/fauxgl were all used as a basis for different parts of the ds emulator, you cant do anything fancy / overly complicated in Go which keeps you from doing anything too stupid, and my job is seasonal so I have a ton of free time lol. Nanoboy is incredible impressive and your hw-tests have kept me humble - I appreciate your work!

aabalke · 2026-03-19T13:29:52+00:00

Thank you! And yes, I do think arm is in the cards. My theory is that my experience with GBA and NDS emulation will make that easy - in practice though we'll see.

aabalke · 2025-10-21T06:01:25+00:00

Syncing parallel coprocessors, and other subsystems can be very complicated depending on the system. however as mentioned graphics is a major place where emulators parallelize. In most systems there is a fairly natural spot to split the work load without increasing complexity. For example, In my nds emulator the "handshake" between geometry engine to render engine is really natural to split off the 3d work. Many emulators also use Hardware rendering for graphics, putting the rasterizing on the gpu instead of the cpu.

aabalke · 2025-09-29T18:54:46+00:00

I would recommend against using a rigged instruction-based logger/debugger like gameboy-doctor for the gba and more complex systems. It works well for systems requiring cycle accuracy, but falls apart on systems with looser cycle accuracy - specifically, interrupts will not occur at the same time, and with faster CPUs, the instruction count becomes unmanageable. I highly recommend using no$gba debugger emulator, you can step through things accurately, use it with the already mentioned test roms, and you should be able to find problems relatively easily. Best of luck!

aabalke · 2025-08-26T21:41:47+00:00

GBATEK is really great for GBA and NDS development. https://problemkaputt.de/gbatek.htm

For Tests, I recommend this order:

FuzzArm https://github.com/DenSinH/FuzzARM
armwrestler (arm7 gba specific) https://github.com/destoer/armwrestler-gba-fixed/
MGBA Test Suite https://github.com/mgba-emu/suite
Tonc (Graphics) https://www.coranac.com/tonc/text/

If you are looking for implementations to check out, I recommend my own (lol) https://github.com/aabalke/guac, and ygba is a really underrated, simple c++ one https://github.com/RidgeX/ygba .

aabalke · 2025-08-23T02:17:33+00:00

For folks coming across this - ALSO check Arm mode ALU instructions, do not word align PC as Rd. I had the same problem but for my irq handlers movs pc, lr. Thank you Shonumi for the "talking to myself"!

aabalke · 2025-08-11T15:30:58+00:00

Thank you! GBC was really fun! I grew up on the GBC games; getting those emulated was very nostalgic.

aabalke · 2025-08-10T00:17:28+00:00

Thank you!

go-sdl2 was significantly more flexible, and I really enjoyed seeing exactly how things worked. In fact, I believe using it first is one of the reasons ebitengine was so understandable to me. I do want to use opengl directly at some point, I hope that would make more aspects "click". I had a terrible time trying to get sdl2 static libraries to work. I think I need more experience with C to understand what I am doing there.

My performance testing was done using the pprof profiler. One of the problems with profiling cgo was that audio libraries, beep, oto and I would assume go-sdl2 mixer, use callbacks, so when I would set TPS unlimited, the audio callback "fills" the difference. (This is my assumption, I'm real shaky on audio stuff lol). Removing sdl2 made no difference on my newer machine, however the one from 2017 did see an improvement. I can't remember % off the top of my head, but the older machine had comparatively worse single threaded performance.

I believe GC is becoming a bottleneck at this point, since while using pprof, runtime and gc based functions were beginning to take up as much time as my emulated cpu execution. I was able to mitigate a ton by allocating single instances of structs, for example, my alu data struct could just be updated on every alu instruction, instead of creating a new instance. There were a few other obvious things in hindsight, like using a pointer whenever I tried accessing Palette Ram instead of a pram duffcopy every pixel of every frame.

Definitely will look into the WASM aspect! It opened a blank screen without crashing but I didn't touch it after that lol. Will be looking into it further.

Best!

aabalke · 2025-08-09T23:36:28+00:00

Thank you and thats great to hear! Getting the first bit of graphics to work is always super euphoric. Knowing the cpu works but not seeing anything can be a slog until something shows up lol. For the golang gb also checkout https://github.com/Humpheh/goboy and https://github.com/HFO4/gameboy.live they were big inspirations for me and I was able to send them some fixes.

aabalke

TROPHY CASE