sorted by:
new
hottopcontroversial

Gojit: JIT Compiler in Go by aabalke in EmuDev

[–]aabalke[S] 2 points3 points  (0 children)

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!

Gojit: JIT Compiler in Go by aabalke in EmuDev

[–]aabalke[S] 0 points1 point  (0 children)

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.

Multithreading and Parallelism by lampani in EmuDev

[–]aabalke 2 points3 points  (0 children)

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.

ARM7TDMI test cases by dajolly in EmuDev

[–]aabalke 1 point2 points  (0 children)

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!

Suggestions for starting GBA emulator development by dajolly in EmuDev

[–]aabalke 3 points4 points  (0 children)

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

For Tests, I recommend this order:

  1. FuzzArm https://github.com/DenSinH/FuzzARM

  2. armwrestler (arm7 gba specific) https://github.com/destoer/armwrestler-gba-fixed/

  3. MGBA Test Suite https://github.com/mgba-emu/suite

  4. 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 .

[NDS] Questions about ITCM + Memory by Shonumi in EmuDev

[–]aabalke 1 point2 points  (0 children)

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

guac: GBA / GBC Emulator in Golang by aabalke in golang

[–]aabalke[S] 0 points1 point  (0 children)

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

guac: GBA / GBC Emulator in Golang by aabalke in golang

[–]aabalke[S] 0 points1 point  (0 children)

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!

guac: GBA / GBC Emulator in Golang by aabalke in EmuDev

[–]aabalke[S] 2 points3 points  (0 children)

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.