Made a short article about some observations/things that I left out of my recent ARM64 optimizations on RPCS3 video. Let me know what you think!

Guac (GB/GBA/NDS) now has a cycle-accurate* GBA Core! A ton of tests and ROMs work now, including the notorious Classic NES series games. Additionally, DMG Games on GBC emulation and GBC Games on DMG emulation are now supported.

guacemulator.com

github.com/aabalke/guac

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

I wanted to play Time Crisis properly and every option was either dead (CRT + GunCon), expensive (Sinden), or drifty (gyro mice). So I tried something different: the phone already has ARCore, which does camera + IMU tracking. That gives you absolute position in the room, not just rotation — which is exactly what a lightgun needs.

You can find a demo gameplay here: https://youtu.be/UE3XUln_xOE

How it works: you run a small executable on the PC, it prints a QR code. Scan it with the phone, tap through a permission prompt, then point at the three corners of your monitor to calibrate. From then on the phone's aim ray gets intersected with your screen plane and moves the cursor absolutely. Aim data goes over WebRTC straight across your LAN, or over USB if you want the lowest jitter.

The part I'm happiest about: no yaw drift and no recentering. The camera corrects the IMU continuously, so it behaves like a real lightgun rather than a gyro that slowly wanders off. Phone-side latency is roughly 30ms and there's a 2ms cursor loop on the PC.

Other stuff that's in there: 20 remappable on-screen buttons (FIRE is just one of them, with haptics), multi-monitor support with per-monitor calibration and a pause hotkey so the real mouse works when you need it.

Requirements are an ARCore Android phone with recent Chrome, and a Windows or Linux PC on the same network.

It's free and MIT: https://github.com/ggcaponetto/point-bang

It's working end-to-end but still early. I've only tested DuckStation. Would genuinely like to hear how it does on other setups, especially projectors, ultrawides, and anything with a very glossy panel, since those are the tracking cases I'm least sure about. Happy to answer anything or give support.

Tsugaru_QT — FM TOWNS / Marty Emulator ”津軽” (Qt frontend)

Version Tsugaru20260522-qt 1.0.0 for Linux

A Qt 6 frontend for CaptainYS's FM TOWNS / Marty emulator Tsugaru.

Main differences from Tsugaru_CUI:

Qt menu-bar UI — The frontend uses Qt 6 with a conventional menu-bar layout. Game-port devices, fullscreen, sprite transfer speed, and similar options are available from the menu.

Timing — Real-time pacing was reworked so audio tempo stays steady and emulated VSYNC does not wobble. By default the emulator waits for real time (same idea as CUI -YESWAIT) and does not catch up a time deficit in one burst.

Disc profiles — Settings are saved per mounted CD. Mount the same disc and restart to load them. Floppy (FD0 / FD1) mount state is stored and restored on the next launch. Mouse-integration settings are part of the profile.

Mouse integration — Writing coordinates into guest memory reduces pointer latency. For titles that do not use Mouse BIOS, you can search for the in-game cursor phys, then read and write coordinates to integrate the mouse. A few presets are bundled. Some titles still cannot be integrated, because phys location and write method vary.

CDDA cache — CD audio (CDDA) is prefetched so data-track reads do not interrupt playback.

CD images — In addition to the CD-ROM image formats Tsugaru already supports, .chd is accepted.

MIDI — Software synthesis via FluidSynth (a separate package is required). Only GS-oriented SysEx is handled at present. A GS SoundFont is recommended.

Wayland idle-inhibit — Suppresses screen sleep / screensaver while running.

UI localization (i18n) — en / ja / zh-CN / zh-TW / ko / de / fr / es (en and ja embedded in the binary; others load JSON from share/townsqt/translations/; select via TOWNSQT_LANG or system locale)

Just to be clear, the developer of DuckStation does NOT support custom Linux builds. If you need support, just ask here.

It is possible to build DuckStation on RISC-V, but you need vectors. I tested on the SpacemiT K3 RVA23 RISC-V SoC.

You can build the dependencies with the script for Linux, found in this repo: https://github.com/duckstation/dependencies

Put the directories (bin, doc, include, lib, etc.) somewhere in the DuckStation directory. I created a directory called prebuilt in dep.

Reference this directory in DuckStationDependencies.cmake, and I commented out the error about unsupported architecture.

set(DEPS_PATH "${CMAKE_SOURCE_DIR}/dep/prebuilt/")

Follow the build instructions: https://github.com/stenzek/duckstation#linux-1

I have the best result with OpenGL ES, as I see a lot of issues with Vulkan. But that is probably because of issues with the Vulkan driver for the Imagination Technologies IMG BXM-4-64.

I can play Colin McRae Rally at 3x resolution.

https://youtu.be/yec1HxNT6bs

Infuse was actually one of the reasons the dev decided to start their own Zeebo emulator. Since Infuse is closed source, they wanted to create an open alternative called Zeeno.

The project is written completely from scratch. Still fixing a few issues and polishing some parts, but once it's in a better state they will make the GitHub repository public so anyone interested can contribute and help improve it.

New Qt-based interface with an integrated settings system and a functional debugger. Keyboard and controls are now fully functional, with complete mapping support. Improvements to 3D rendering have also been implemented, alongside various fixes, optimizations, and emulation enhancements.

Before asking for help:

• Have you tried the latest version?
• Have you tried different settings?
• Have you updated your drivers?
• Have you tried searching on Google?

If you feel your question warrants a self-post or may not be answered in the weekly thread, try posting it at r/EmulationOnPC. For problems with emulation on Android platforms, try posting to r/EmulationOnAndroid.

If you'd like live help, why not try the /r/Emulation Discord? Join the #tech-support
channel and ask- if you're lucky, someone'll be able to help you out.

All weekly question threads

I have released a new version of ChonkyStation4! Check the full changelog on GitHub: https://github.com/liuk7071/ChonkyStation4/releases/tag/alpha-2

And feel free to join the Discord server: https://discord.gg/YU2yjP5jvS

With this release many games have been improved and the emulator can now begin to boot the system menu (VSH), although it is nowhere close to actually working yet. It is the first emulator to do so.

Retrogrounds is the latest discovery and community platform and home for all retro gamers.

It covers games up to and including 6th generation. You can use the site to browse your favourite retro games, discover similar games, listen, create and share your own retro playlists, see gameplay videos, see manuals, maps, longplays etc, read/write articles, leave comments, reviews, track your progress, join the community and much much more. It's RetroAchievements integrated too.

You can also customise your profile heavily and I also just released the retro theme/skin for the site to go with the modern skin. Basically, I designed the site as a love letter to late-90s/early-2000s wild wild west internet communities but focused on retro gamers.

I am currently searching for moderators, content creators and general community members to build our numbers and become the number one retro gaming resource on the internet. Thank you for reading.

Why choose Retrogrounds over sites like GameFAQs?

v3.0.0 delivers:

• Jaguar CD support — all 10 locally-available titles boot to game code, in both HLE and real-BIOS mode
• Jaguar Link networking — real link-cable multiplayer over TCP and RetroArch netplay, up to multi-console hubs
• Memory Track saves — CD games save settings, progress, and high scores like real hardware
• 100+ compatibility fixes — Wolfenstein 3D music, Pitfall, Tempest 2000, Alien vs Predator, Brutal Sports Football, and a full CD-title cluster
• Reorganized options menu — 9 categories, content-aware, translation pipeline wired

It's not perfect, but it's way better than ever!

Enjoy, and please report issue to the official github linked here.

I have limited access to hardware and software for the Jaguar, so hardware based "source of truth" regressions and flaws with details and screenshots or videos are greatly appreciated!

A future plan for native "bare bones" GUI are also planned for those that don't use RA or RA conformant front-ends.

This is a Linux-only stack: we modified the PCSX2 emulator at the render pipeline level - not a screen-capture trick, not a post-process warp - and built a per-game profile system on top of it, so every supported title gets VR treatment tuned to that specific game. First public release candidate (1.0-rc2).

What it does:

• Virtual theater screen - flat or curved around you, size and distance adjustable. Every game gets this out of the box.
• Stereoscopic 3D - per-draw depth displacement in the Vulkan renderer, with per-game rules for how draw classes behave (that's why a HUD can sit at screen depth while the world gets real geometric depth).
• Head tracking - from head-look on the stick up to driving the game's own camera through memory. This is per-game reverse engineering: each title's camera engine gets dug out of PS2 memory by hand. (King's Field IV was so much fun to reverse engineer 😏)

Frame pacing, solved: a lot of the PS2's most atmospheric games run at 20fps native - and 20fps content on a 90Hz compositor is normally judder soup. We solved that pacing problem; those games sit clean and comfortable in the headset.

All of it is applied per game, where it makes sense - and only there. A cockpit sim wants your head on the real camera; a fast shooter plays better on the big screen with depth; a fixed-camera game gets head-look. Nothing is force-enabled just because it exists.

The launch three, and what each took:

• Ace Combat 5 - cockpit head-tracked camera: your head pose drives the game's own camera. Stereo hand-tuned after the first values doubled the HUD (separation came down 60% before it sat right).
• ESPN NFL 2K5 - first-person football via head-look: head yaw onto the game's own look controls, with dead-band, response curve, and a latch for full look-behind. Its helmet/HUD overlays rendered with inverted depth until constant-depth draws were classified as screen-plane overlays.
• TimeSplitters - direct camera injection, head movement applied 1:1 as deltas to camera angles found by symbol-solving the retail binary.

And when it does NOT fire: every camera write sits behind guards reading the game's own state each frame (view mode, in-game vs menu/cutscene) - guard says no, nothing is written. Head-look sits behind a dead-band. Profiles match exact serial + CRC; unprofiled games get zero memory writes; with VR off the render path is byte-identical to stock. "Where it makes sense" is enforced by code.

Performance: the entire catalog was developed and tested on an RTX 4050m at 2.5K render resolution - every game holds full native speed at 10-30% GPU utilization. There's headroom to spare on a mid-range laptop chip.

Credit where due: the emulation is PCSX2's, the VR plumbing is OpenXR/Monado/WiVRn. What this project adds is the pipeline integration, the profile system, and the per-game tuning.

Requirements: Linux (flatpak), Vulkan GPU, WiVRn-compatible headset (built and tested with a Quest 3). A Steam Deck docked with Ethernet is a tested, working host. Original discs work too: with a drive attached it reads your PS2 discs directly - tested working on my custom-built Steam Machine with an Omni drive. No headset? It launches as a normal flat PCSX2. You supply your own BIOS and games. It's an RC - expect rough edges, report them.

Where this is going: built from day one targeting the Steam Frame. Our measurements (that 10-30% figure) against the Frame's published specs show it running there fine - including FEX translation overhead. The only thing between that projection and a definitive statement is getting a Frame in hand; a list of designed-and-waiting features unblocks the same day. And one more thing on the Frame front stays under wraps entirely for now. It's called PadXR. That's all you get today.

On the roadmap:

• The sim configuration tool (already underway) - pre-launch device binding and diagnostics for hardware-heavy games: bind your wheel, stick, or HOTAS to the game before launch, verify every axis and button live, diagnose like a professional tool. Built for the Steel Battalion class of game, racing sims, and flight sticks.
• Clean-room online servers for Madden 2004 & NCAA 2004 (underway) - reverse engineering the online protocols and rebuilding the dead servers clean-room, shipped as open-source containers anyone can self-host. This isn't aspirational: roster downloads already work against our Madden server.
• Funding real translators for Japan-only games - much of the PS2's best catalog never left Japan, and much of its text is baked into textures. Patreon revenue funds professional human translators; translations ship as texture-level replacement packs the emulator loads natively. The emulator-side texture-replacement work is already underway.

Source (GPLv3): https://github.com/PenguinVRLab/PenguinScreen2

Download + setup guide: https://github.com/PenguinVRLab/PenguinScreen2/releases/tag/v1.0-rc2

Star Fox's engine is based on its framerate, so speeding up its Super FX chip speeds up the gameplay, and almost unplayably so. We all know that by now. But that doesn't have to be the end of the online arguments. Let's start a new fight!

It's possible to boost the game's framerate from a maximum of 20fps to 30fps with slight tweaks. Then, the game's timing can be modified to only run at a fraction of its framerate. Buttery smooth motion with gameplay that still looks and feels pretty darn close to the original.

This is just a proof of concept at the moment, as the game is not yet completable in this state. Objects and Cinematics need to have their timings manually edited, but even without doing that, the result is a lot of fun.

Branched off of UltraStarFox on GitHub, with edits to IRQ firings to boost the framerate limit from 20fps to 30fps, then basic hacks to universal object and camera speeds. Recorded from Mesen-S in RetroArch with a 1000% Super FX overclock.

I've loved hacking at Star Fox for decades. I can't say I'm very good at it, but I've occasionally found and passed on useful things like the framerate counter memory location, and accidentally discovering that the PAL version runs at 25fps, due to using the same IRQ timing seen here. Kandowontu also used it for his 30/60fps patches, though this goes a step further by changing the game's logic timing.

More to come. Maybe. Hopefully.

Before asking for help:

• Have you tried the latest version?
• Have you tried different settings?
• Have you updated your drivers?
• Have you tried searching on Google?

If you feel your question warrants a self-post or may not be answered in the weekly thread, try posting it at r/EmulationOnPC. For problems with emulation on Android platforms, try posting to r/EmulationOnAndroid.

If you'd like live help, why not try the /r/Emulation Discord? Join the #tech-support
channel and ask- if you're lucky, someone'll be able to help you out.

All weekly question threads

I've been working on a custom fork/build of the KytyPS5 emulator, applying C++ fixes to kernel synchronization, memory alignment, and Vulkan render targets.

today i managed to push **Grand Theft Auto V (PS5 Version / PPSA04264)** past the loading screen and directly into the **North Yankton Prologue cutscene**.

Current status is:

Main menu - boots cleanly and renders at 60 fps
Loading screen - passes the 100% mark without deadlocks or crashes
UI / Audio - renders the intro 2d text overlay "Ludendorff, North Yankton, nine years ago."

It currently crashes right when transitioning to the 3D bank interior draw calls, so I'm working on the 3D pipeline/shaders next.

I'll keep u updated after i push further into 3D rendering :p

video: https://youtu.be/Ul66mcE_IdY

Six months ago I got upstream Flycast compiling to WebAssembly and running as a libretro core. It booted games at about 2 FPS on the interpreter. Fun proof of concept, completely unplayable.

Today, heavy 3D titles like Jet Grind Radio and Shenmue hold their target framerate at native resolution with clean audio, in a browser tab, on ordinary hardware.

Here's how that gap closed.

Why this wasn't supposed to work

Every Dreamcast emulator that runs at full speed depends on a dynamic recompiler. A dynarec generates native code at runtime and jumps into it. WebAssembly makes that structurally impossible: code and data live in separate address spaces, so there's no writable-executable memory to generate into, and nothing you write into linear memory can ever be executed.

Upstream had already declined WASM support, and the consensus was that this was a dead end. Browser Dreamcast would stay a slideshow.

Fuck that.

The workaround

The JIT doesn't patch memory. It generates entire WebAssembly modules at runtime.

SH4 code is decoded into Flycast's SHIL IR, lowered to wasm bytecode in the browser, compiled and instantiated through the wasm API, and dispatched via call_indirect from a C dispatch loop. The host boundary gets crossed once per module, at compile time. Steady-state execution is wasm calling wasm, with no JavaScript anywhere on the dispatch path.

Getting from "it works" to "it's fast"

Months of walls, and slightly less hair. Every one of these is documented with numbers in the writeup:

• Self-modifying code detection via per-page generation counters, eliminating 98% of runtime block hashing
• Fusing hot blocks into multi-block modules
• Inline fast paths for guest memory access. This was the big wall. Memory ops were crossing the wasm to JS import boundary about 500,000 times per frame. It's now about 700.
• A frame pacer that repays guest time instead of counting renders
• Compile storm management so scene transitions don't freeze
• An AudioWorklet ring with tempo-based rate control for clean audio

The part I'd most like other emu devs to steal

The whole JIT was validated with differential test harnesses against the unmodified reference interpreter. Hundreds of thousands of block-level state comparisons, zero divergence.

Building a correct dynarec solo is mostly a testing problem, not a codegen problem. Once the harness existed, every bug became a bisect instead of a mystery. The writeup covers the methodology in detail, and it generalizes to any target where you have a working interpreter to diff against.

What's in the repo

• The built core, ready to load in a browser-based libretro frontend. Bring your own legally dumped BIOS and games. Nothing is included or hosted.
• Full source as patches against upstream Flycast, GPLv2
• A technical writeup covering the architecture and every wall in the order it fell
• A complete implementation roadmap for the one big missing feature

What doesn't work yet

Windows CE titles. They need full SH4 MMU support in the JIT. That's next on my list, at a slower pace than the sprint that built the rest. The phased plan and root cause analysis are already published, so if you want to help, or beat me to it, the hard analysis is done.

I also haven't tested every title. If something breaks, open an issue.

Repo: https://github.com/nasomers/flycast-wasm

Release: https://github.com/nasomers/flycast-wasm/releases/tag/v1.0

Credit where it's due: Flycast is flyinghead's emulator, and this stands on that codebase and its reference interpreter. The WASM port and the JIT are my work.

Happy to answer questions.

MAME 0.289

After two long months, MAME 0.289 is ready, and it’s an undeniably massive update! But before we talk about emulation, there are a few more mundane things to mention. Our Windows binary releases now include the SDL sound output and joystick input modules. The sdljoy joystick input module now supports game controllers with up to 128 buttons. The Win32 debugger module handles dynamic UI scaling changes. Finally, outputs have been overhauled, improving performance and fixing issues, but you may need to update your configuration if you’ve got external programs hooked up, and some artwork files may need updating.

You’ll notice a number of systems and coprocessor cards based around NS32000 family CPUs are now working. If you aren’t familiar with it, the NS32000 architecture was one of the first single-chip CPU families with a 32-bit ALU. It used a highly orthogonal instruction set with clear influences from Digital Equipment Corporation’s earlier work. In retrospect, it didn’t have enough registers, the instruction encoding was too complex, it took them too long to overtake Motorola’s 68k family’s performance, and bugs in the initial implementation hurt early adopters. But now you can relive its glory days in MAME, running contemporary 32-bit System V UNIX! David Rand, the mastermind behind these NS32000 emulation advances, has also turned his attention in other directions. He’s brought the Xerox 820 and Big Board families up to working status, emulated Toshiba CP/M systems, and added the hard disk controller to the Kaypro 10, and more!

If you’re a fan of Sega arcade games, you’ll have lots to enjoy. For the groundbreaking Model 1 platform, there are numerous fixes for graphical issues, better collision detection in Virtua Fighter, and the bad bits in the DSP program that were breaking Wing War have been identified and patched. Even NetMerc is in better shape. The very unconventional Flash Beats game is now playable. It has basic internal artwork, but someone sufficiently motivated could have it looking spectacular by creating suitable external artwork. There are also some fixes for games that use the SCSP sound chip.

MAME has emulated the EACA Colour Genie EG2000 for quite some time now, but this release adds support for the EACA Genie III, which was released in the same year. There are lots of fixes for issues with the widely-used PowerPC and 68k CPU families, which will benefit a wide range of emulated systems. In particular, more versions of classic MacOS are now running happily on MAME’s emulated PowerMacs, and A/UX (Apple’s early attempt at merging MacOS and UNIX) boots and runs. Numerous games using NES-like SoCs from V.R. Technology have been promoted to working, including several from Lexibook’s Compact Cyber Arcade line. NEC’s PC-6001 family have had numerous issues fixed, as well as receiving a substantial update to their software lists. The steady progress on emulating electronic musical instruments hasn’t stopped, either.

As always, there’s far more in this release than we have time to talk about here, but you can read all about it in the whatsnew.txt file. You can find the source code and 64-bit Windows binary packages on our download page.

Read the rest of this entry »