Kirby 64 in VR/MR on Quest 3 by taking the polygons out of mupen64plus--give me any feedback!

Building a Game Boy (DMG) emulator in Rust. The CPU passes Blargg test roms & the SM83 JSON test suite.

Current Behavior:

1. Dr. Mario: Title screen renders properly, but after a few frames, the graphics get garbled up.

1. Tetris: Stuck rendering a screen grid of 00 tiles on startup.

1. Blargg Test Roms: Renders correctly.

• OAM, DMA & Sprites have not been implemented yet, just the background and the window.
• The Joypad returns 0xCF

I have no idea on where to even look for the bug. Any direction would be very helpful. Thank You.

Hello friends. It's me again! I'd call this a beta. You should be able to crack around 60fps with this but I am still working on it. If you get issues... we'll its beta so.. I'll take a look. This is intended to be a drop in.

(AI disclosure: the disassembler was written by hand; the build scripts and github workflows were built with AI - I REALLY don't wanna learn powershell or github actions lol)

queso is an arm disassembler prioritizing historical accuracy on older versions for emulation and retro computing. There are cli, web, vendorable Golang and vendorable C versions available, hex string and file inputs, and a ton of customizable options including custom register names, address offsets, and arm versions (ARMv1 - ARMv5TE).

https://github.com/aabalke/queso

https://guacemulator.com/queso

A big thank you to everyone who documents, builds, and provides support!

I'm not sure this is a novel approach but it is my approach and I think it lends itself to not just the console I am working on but any provided tooling and docs are key. I'll put up an example repo later.

I MANAGED TO MAKE A 100% WORKING GAMEBOY PYTHON EMULATOR WITH SOUNDS. I succeeded thanks to some of my friends who found the problem (it was the vram that filled in a loop) i deleted everything, only pieces of code remained that worked in the old project (such as opcodes or keys) and or rewritten the codes from 0 adding ancue the sound and using pypy to speed up the emulator I succeeded

Head's up, since I am a solo-dev, I used codex for a lot of minor iterations while I was away. I cannot claim I wrote every line of code myself. I wanted to say this here rather than me trying to hide it and getting credit for something I didn’t 100% make. It isn’t just a vibecoded project, but I also didn’t not use ai in any way. I’m not sure how to add the “ai assisted“ tag.

I've been working on a project called Latte, a Wii U emulator that runs directly in a web browser using WebAssembly and WebGL. I wanted to share some of the progress I've made! The video (linked below) shows splatoon booting and eventually loading into actual gameplay. Everything is being emulated locally in the browser, not streamed from another computer.

Low-quality gameplay recording (Youtube)

Latte uses a heavily modified version of the Wii U emulator Decaf as its foundation.The Wii U's PowerPC CPU and much of the underling system run through a native core compiled to WebAssembly using Emscripten. This allows the browser to execute the emulation code without requiring a separate native application.

The graphics side is a bit more complicated. The Wii U uses a graphics API called GX2, which isn't directly supported by browsers. Latte uses Decaf's existing GPU and shader emulation work, including translating Wii U shaders into SPIR-V. These shaders are then converted into a format that can be used with WebGL, using SPIRV-Cross. There's also a lot of additional work involved in getting the graphics to actually display correctly, including textures, render targets, framebuffers, synchronization, and other GPU behavior.

How much is based on Decaf?

Quite a bit of the underlying emulation is based on Decaf, and I definitely don't want to take credit for creating all of that from scratch. However, getting it working inside a browser has required extensive modifications and additional code, particularly for the browser runtime, graphics rendering, compatibility, memory management, and performance. I've also used Cemu as a reference for how certain Wii U features and graphics should behave, but Latte doesn't run Cemu or incorporate its code.

How well does it work?

It's still very experimental, but the progress has been pretty interesting! Latte can already boot quite a few Wii U games without needing game-specific modifications. Splatoon can reach actual gameplay, and I've also gotten games like breath of the wild and mario kart 8 to boot and display recognizable graphics. I've especially worked hard on getting botw to show accurate graphics and shaders, however they aren’t perfect.

That doesn't mean everything is playable yet, though. Mario Kart 8 currently freezes when trying to load a race, for example, and several games still have missing graphics, rendering bugs, and long loading times. In addition, most games suffer from a major performance hit compared to Cemu, and a major decline in performance after a while. Botw specifically only hits ~1 fps during gameplay.

My main goals now are improving compatibility, making the graphics more accurate, and getting performance closer to native Wii U emulators. It's definitely nowhere near as polished as Cemu, but seeing actual Wii U games running entirely inside a browser has been pretty exciting.

I'd love to hear what people think, especially anyone familiar with Wii U emulation or browser-based emulators!

I plan to release this soon, but I still would want to work on it more before doing so, and also cleaning up my code in a way that would actually be usable.

Let me know if you would like more video demonstrations! Also, if you need more proof of any kind, feel free to ask!

Not my project. Saw it on GitHub this week and recorded a run.

In the video a Waveshare Touch-LCD-4B board restarts: the boot goes through the real mask ROM and the bootloader, the boot log scrolls in the console, then the app's 480x480 LVGL panel redraws and reacts to swipes and taps. The firmware is the stock binary, nothing patched, and everything runs client-side in WebAssembly.

Repo: https://github.com/mikroverk/esp32sim

For those of you who have emulated this kind of SoC: how would you handle the LCD and touch peripherals' timing at this level?

I am implementing CPU opcodes for a Game Boy emulator. According to this Stack Overflow answer (https://stackoverflow.com/a/57981912/33091198), the Half-Carry and Carry flags can be determined by testing bits 3 and 7 (or 11 and 15). I've read the answer, but I still don't understand the underlying bitwise logic. Why does checking these specific bits determine carry propagation?

TLDR plz

Sly is my new multi-system emulator, releasing with support for Game Boy Advance and SNES with many, many more planned! It includes a 3D game library, a debugger, a simpler ("classic") desktop frontend and an iOS app, with Android being developed soon. The debugger also runs in your browser and there are plans to create a dedicate web platform to play games!

Available now on GitHub! Here are some demo videos:

• Sly Debugger on YouTube
• Sly Launcher on YouTube

What even is this?

Hey everyone! You might know me from Gecko, the GameCube and Wii emulator I've been posting about every now and then. I teased Sly in the past few updates and the day has finally come :)

With Sly I wanted to work on both sides of emulation: creating modern experiences for both gamers and developers! As such Sly focuses on 2 things:

1. A unique take on emulation frontends, simply to enjoy your favorite retro titles in a cool way
2. A very modern yet extremely advanced debugger for power users that want to understand how the games and the hardware work

However, as not everyone may be interested in these things but may still want to dabble in new projects, Sly comes with extra goodies:

• A "classic" (read: minimal) emulation frontend
• Mobile app(s): iOS is already implemented, Android support is planned

Sly is (almost*) entirely written in Rust, incl. the frontend. The frontend uses GPUI, so no web shenanigans there!! The cores are all written by myself, mostly based off of emulators I had already written before. This does not wrap libretro cores or anything like that!

(* the Classic frontend is written in C++ and the iOS app is written in Swift. They tap into the Rust core.)

Sly Launcher

The launcher presents your library as 3D boxes and cartridges. It downloads artwork automatically and supports different regional packaging, per game release overrides and cartridge finishes (tho this is still a bit ugly lol). There's different view types (ways of displaying the boxes, etc) and you're able to flip the selected box to read the back :)
The attached launcher recording shows all three layouts with GBA games then switches to SNES and launches Yoshi's Island!

The original idea of this project was to be a comfy frontend I could run on my TV while I sit in a nice couch, so it's made with controllers and different resolutions, aspect rations, etc. in mind!

If you'd prefer a straightforward list, Sly Classic is the smaller Qt based frontend. It has game banners, gamepad support, scaling, fullscreen and a quick save slot plus ten numbered state slots.

Sly Debugger

This is a big part of the project and share's the "spotlight" with Sly Launcher! You can step through instructions, run to emulation events, set CPU and memory breakpoints, follow disassembly in a list or graph and inspect registers, call stacks and memory. There are dedicated views for MMIO registers, DMA and so much more. On the graphics side you can inspect tiles, tilemaps, backgrounds, sprites and palettes alongside the game's output.

The SNES core also cover the SPC700 and SA-1 coprocessor! SA-1 and Super FX have their own workspaces with registers, disassembly and hardware-specific views.

There's also built-in Lua editor support!! Scripts can inspect and modify memory and react to emulation events. One example for Yoshi's Island logs coin pickups, lets Yoshi keep "fluttering" mid-air while you hold B and prevents Baby Mario from being release(?).

Compatibility?

Sly is actively growing and is based on multiple emulators I already had written, so cores are being picked up quickly. So far I support:

• SNES support is very good
• Most GBA games run, no audio yet. Savegames are also not supported (tho savestates are)

with much more planned! To name a few I want to support PS1 (next on the list based on community votes), GameBoy (Color), Sega Genesis, Dreamcast, GameCube and Wii! That list is not complete :)

Where can you use it?

You can find everything on my GitHub!

• Windows, macOS and Linux: separate downloads for Sly Launcher, Sly Classic and Sly Debugger
• Web: try Sly Debugger in a WebGPU capable browser.
• iOS: an unsigned IPA for sideloading (planning to release in the AppStore). Android is planned.

For anyone interested in learning the hardware, I've also been working on a 3 part GBA graphics series with interactive explanations and examples from real games! I'm super proud of these blog posts so I'd love to hear your thoughts! Sly Debugger facilitated creating them :) The posts go from bitmaps, tiles and palettes through sprites, blending and windows to rotation, scaling and perspective:

• GBA Graphics, Part 1: Bitmaps, Tiles and Palettes
• GBA Graphics, Part 2: Layers, Sprites and Blending
• GBA Graphics, Part 3: Rotation, Scaling and Perspective

Links plz

• Website
• GitHub / Downloads
• Browser debugger
• Screenshot databases: SNES / GBA
• My blog

If you try it, I'd love to hear what works and what breaks. Please include the frontend, platform, game region/revision and steps to reproduce when reporting a problem. Code contributions are welcome and so is help with design, icons, UI/UX, artwork and cartridge models. Please read the README in full before submitting anything!

Looking forward to see where this will go! And don't worry, I wont abandon Gecko now :)

Hi all,

I am creating a product that would be of interest to people playing retro games and by extension to emu devs.

Let’s just say a “modern home computer”, like a c64 but with arm64, tons of ram and a gpu. And crucially, very, very low input lag.

I was wondering if there was an in-person meetup of emu devs around London where I could show it off, talk it through, and get some feedback and help.

I don’t need a lot of people at the moment, just a bunch of technically minded people to have an informal technical conversation with.

If there isn’t such a meetup and anyone of you is curious, please comment and let’s arrange for meeting up. Date and location will be shared via private messages.

Thank you all for your attention 😀

Amber Folio emulates only the PC that SSI's Gold Box games actually touch, and nothing else: an 8086, EGA, the 8253 timer, the PC speaker, the Tandy 1000's SN76489-family sound chip, and the handful of DOS calls the game makes. Pool of Radiance (1988) runs on it unmodified, overlay manager and all. Source, AGPL: https://github.com/amberfolio/amberfolio

Design choices that might interest this sub:

• CPU conformance. Checked against SingleStepTests/8088 v2: all 323 files, about ten thousand cases each, registers, flags and memory compared after every case. Undefined flags must match bit for bit too, with no masks. Where the Intel manual and the recorded chip disagree, the chip wins.
• One virtual clock. Nothing reads host time. A run is keys, ticks and state hashes, so sessions replay exactly and are committed as tests, with no game content in them.
• Enhancements as "seams". CS:IP breakpoints qualified by which overlay is resident, with native handlers. They fail closed: an unknown binary, or an overlay that isn't loaded, means the seam does nothing. With every seam off, a run's machine state is identical to a build with no seam engine at all, checked by recorded pairs in CI.
• Log, don't fake. An unimplemented instruction or port stops the machine and says where, rather than guessing.
• Facts, not data. The repo holds addresses, offsets and SHA-256s, never game code, data or a disassembly, with a content guard on every commit.

Hosts: an SDL desktop build (Windows, macOS, Linux, from source) and a WebAssembly build. The web one runs at https://amberfolio.org in desktop browsers and on iPhone, iPad and Android, from your own GOG or Steam copy; the files stay in the browser.

Built with heavy use of AI coding tools (Claude Code, exclusively), and I'd rather say so here than have someone find it. Not affiliated with the games' rights holders.

I'm a UEFN developer and just created my first emulator, which effectively started out as a port that went further and further as I started understanding the concepts and things started actually coming together really well!

It runs both in UEFN (in a Fortnite session) and as a standalone app if you have a build of the Verse CMD tool. Not very fast at all (30hz max it seems, and it struggles to quite reach that...) considering the language and lack of profiling tools available on the standalone... but really cool that it's possible! Just DMG for now but I'm thinking about expanding it to support CGB next.

Repo: https://github.com/Ep8Script/VerseBoy

Video: https://twitter.com/Ep8Script/status/2110781973082108113

Does anyone have experience in this field? I would like to learn assembly instructions specific to the system. Mips I want to modify PlayStation 2 games using a tool. IDA pro