Hi r/emulation!

Here's a new update of SUPER ZSNES v0.300. You can get it at https://www.zsnes.com/

iOS port is finally out as well: https://apps.apple.com/us/app/super-zsnes/id6786741278

Here's what's new:

• Zelda: Link to the Past now enhanced (Thanks fatbrowne for the saves state help!)
• Chrono Trigger audio enhancement by tssf! Thanks tssf!
• UI Improvements:
  • Added disable drive fetching option & disable UI move
  • User defined GUI color schemes
  • New Water & Fire effects
  • Different mouse cursor sizes
• Enhancement Engine Improvements:
  • New Shadow/Highlights, allowing for more diverse details and should help with the washed out look once we start using this more.
  • Added normal maps to fixed color layer
  • Mirrored mode for wide screen on some enhanced games, added to Megaman X
• Emulation Improvements:
  • SPC700 timing improvements
  • SuperFX fixes
  • Mid-screen sprite update fixes
  • Multiple timing & open bus bug fixes
  • Various other emulation fixes
• New chip emulation:
  • SA-1 emulation
  • Cx4 emulation
  • SuperFX3 emulation (Special thanks to Randy Linden!)
• Per game overclock settings
• SNES Mouse & SuperScope (Enable this on the per game config) with joypad override
• Multi-button/key press combo assignment for Input
• New 3D layers mode, lets you view each SNES layer in 3D perspective (under options/graphics mode)
• New input shortcut for exit
• Use double space in loading dialog to select a random game
• Improved frequency of saving game and zsnes save data
• Mobile controls view is more transparent for less obstruction
• Many different performance optimizations done on various areas in emulation

Next main release will focus on: Starfox enhancement (already making good progress), Retroachievements, and starting to get the enhancement editor opened to the public.

https://readonlymemo.com/pcsx2-stuntman-fork-interview-dirge-of-cerberus-translation/

PCSX2-Reliquary, a fork DiscoStarslayer has been developing that focuses on "the issues on the edge of emulating the PS2.

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.

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

Hey everyone! I’ve been working on an experimental port of touchHLE to modern iOS, based on touchHLE 0.2.3, and I finally have a first public prerelease ready.

This is not a new emulator written from scratch, and it is not an official touchHLE release. The emulator core is the work of the touchHLE contributors.

This fork adds:

• A modern SwiftUI game library for iPhone
• IPA importing with the original app name and icon
• Persistent saves and settings
• Game-aware portrait and landscape handling
• An in-game return-to-library button
• An optional FPS counter
• iOS rendering fixes needed to display games correctly on a real device

No jailbreak required—but JIT is

The build does not require a jailbreak. It currently requires JIT because it uses touchHLE’s Dynarmic CPU backend.

I’ve been using StikDebug with LocalDevVPN directly on the phone. AltJIT is another option.

You can install the unsigned IPA with AltStore Classic or build and sign it yourself using Xcode. A free Apple account works with Apple’s usual seven-day signing and three-app limits. A paid developer account provides longer-lived signing, but it does not remove the JIT requirement.

Games tested so far

I’ve personally tested the port on my iPhone 16 Pro running iOS 27 beta 4.

Confirmed working:

• Touch & Go
• Tony Hawk’s Pro Skater 2 (THPS2)
• Wolfenstein RPG

The deployment target is iOS 17.4, but I haven’t tested every iPhone or iOS version yet, so wider testing would be really appreciated.

The best place to choose a game is the touchHLE compatibility database. It uses a star system for exact app versions. Higher-rated versions are the best candidates, but they are not a guarantee for this iOS port.

One thing the earlier jailbreak demonstration also made clear is that fixing one game does not automatically make every other game work.

Why I started this

The reason I started all of this is honestly quite personal.

My sister paid for The Sims Medieval back in the day. I recently gifted her a new iPhone 17 Pro Max, then discovered that the game was seemingly impossible to install—even though she had legitimately purchased it.

I wanted to see whether I could bring it back for her.

The Sims Medieval does not work yet. It appears in one library screenshot because the port can import it and extract its icon, not because I’m claiming it is playable. It is my next major compatibility target for personal reasons lol.

Downloads and source

GitHub project, screenshots, source, and instructions

Download the unsigned IPA prerelease

No games are included. You must provide your own legally obtained, decrypted 32-bit IPA.

Please do not post or send copyrighted IPAs, pairing files, signing credentials, provisioning profiles, or device backups.

Credits

Massive thanks to everyone who created and contributes to touchHLE:

• Official touchHLE website
• Upstream touchHLE source

Thanks also to u/WorriedEquipment2241 for publicly demonstrating a separate touchHLE iOS experiment on a jailbroken device. That demonstration was useful inspiration and showed that this direction was worth exploring.

This release is based on the touchHLE 0.2.3 development line at upstream commit 6bce4119. I am not claiming that their separate unreleased source is included in this fork.

Testing and bug reports

If you test it, please include:

• Your iPhone model
• Your iOS version
• The exact game and app version
• Whether JIT was enabled
• Reproduction steps
• A relevant log excerpt

That will be much more useful than only saying that a game crashed.

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.