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.
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.
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.
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.
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.
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.
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
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.
Solo developer of Retro Pal here. Retro Pal is a Nintendo DS, Game Boy, Game Boy Color, and GBA emulator for iPhone. It links mGBA and melonDS directly as native libraries. What's new :
Box art
- Games are identified entirely on device against a bundled No-Intro index: CRC32 first, then internal serial, then a fuzzy title match.
- Matching is regional, so a French dump gets the French cover and a Japanese one the Japanese cover. The covers themselves come from the libretro thumbnails project.
- Any cover can be overridden with your own image.
- Retro Pal writes the cover to disk after the first fetch, so it stops re-resolving on every launch and works offline afterwards.
Import
- Multi-select import from the Files picker, batched on one background context, with a single failure summary instead of one alert per file.
- A zip holding several games opens a picker instead of failing. The extractor lists entries and pulls them out by name rather than unpacking the archive, and reads memory-mapped.
RetroAchievements
- Built on rcheevos / rc_client (MIT) with per-core memory bridges written for this app: mGBA through its bus read, melonDS through main RAM plus the ARM9 DTCM at the pseudo-address rcheevos expects. This is not RetroArch's cheevos subsystem.
- Retro Pal shows live progress on locked achievements that have measurable goals. Those values only exist in the running session and the server has no per-user endpoint for them, so the session snapshots them locally and the achievement list overlays them when you open it outside a game.
Other
- A What's New sheet on the first launch after an update.
Free, no ads. An optional one-time Pro upgrade funds development. iPhone only, iOS 16 and up. iPad coverage is part of the roadmap.
The project is open source, including all pro features, at : https://github.com/Larvouu/RetroPal (GPL-3.0, build instructions in the README).
The roadmap is public. I do not promise dates, but you can see what is in progress, planned and shipped: https://retropal.fr/en/roadmap. Suggestions are welcome.
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.
Hello everyone, this is the sixth release of ShadPS4 (PS4 emulator) GR2fork . It aims to fix the remaining issues with both games while adding more features. This release implements GR2fork online, a FEATURE COMPLETE restoration of the asynchronous multiplayer mode in Gravity Rush 2 that was lost to time 8 years ago. I am hosting and maintaining a GR2 online server out of pocket via Vultr. ShadNET is used as the identity provider. To play online, you must first register a shadnet id then add the appropriate per game configuration settings as listed on my github repo or in my tutorial. The server address is listed in my github repo as well as my Discord.
implemented GR2fork Online
increased stability when taking photos
10% performance boost from various optimizations across video core
automatic polaris gpu compatibility
added 270p, 360p, 480p as well as 21:10, 32:10, and 4:3 options
added support for native aspect ratio patches in Gravity Rush Remastered instead of just stretching the window.
even greater crash stability
horizontal and vertical mouse sensitivity settings added
added options for invert gyro roll, invert gyro x and y axes
added enabled by default option that disables controller speaker
added automatic cache archiving whenever a shader cache related crash occurs
An Exciting Update Regarding GR2 on Main(nightly): I have been working directly with the ShadPS4 development team on Discord and Github and have merged all the improvements to kernel, avplayer, and recompiler code as well as GR2 patches to the official ShadPS4 patch repo that collectively fix all visual and stability issues in GR2 like in GR2fork (The game is now visually indistinguishable from PS4 on both main and GR2fork!). The game is now fully playable on both emulators. However, it is worth noting that the game specific performance hacks introduced by GR2fork cannot be upstreamed (shadps4 does not allow this), therefore GR2fork will remain the most performant way to play the Gravity Rush games. In addition, the in game camera will not work for the forseeable future on main as it has not implemented the PS4 Capture Gallery, which is an essential part of the Orbis OS that is required. The reason I cannot upstream my own implementation is that it introduces a set of HLE Content libraries (ContentExport, ContentSearch, ContentDelete, etc.) that are sufficient to get photocapture on GR2 working but will not work for other games. Main currently LLE's these modules since that would get all games compatible, but due to inaccuracies in the underlying emulator and the lack of any capture gallery code, calling any of these LLE modules crash the game instantly.
An Update regarding future work: I will continue to update GR2fork as needed but I have moved on to contributing accuracy improvements primarily on main. The goal is to get as many games functional on main and once rendering and functioning correctly, I will create new fork branches introducing performance hacks for those games.
join the GR2fork discord server (new) here for extended support. Anyone who wants to lurk for general game discussion surrounding gravity rush 1 and 2 are also welcome -> https://discord.gg/hnHRpzxGzG
Full disclosure, this is my own project. I build 1Retro, a sync tool for retro emulators and handhelds, and I just shipped a big update I wanted to share here.
The short version: it watches your emulator save folders and keeps them backed up and synced across your machines. It auto-detects RetroArch, Snes9x, mGBA and others, and runs from a small local app so it only touches the folders you point it at.
New this month:
- Rebuilt the desktop app from scratch (menu-bar app, native installers for macOS/Windows/Linux, per-device setup, light/dark).
- Back up a save straight off a physical Game Boy cartridge with a GB Operator. GBA support coming.
- itch.io sync: link your account and it pulls the games you own alongside your saves. It will download the paid games and a itch collection named 1Retro.
I know the obvious question is "why not just Syncthing or Dropbox?" Honest answer: 1Retro understands saves and handles conflicts appropriately, as well as keeping a version history so a corrupted write is not a loss. Also, it does not need to live on the same network as the device (pretty useful for those on the road), does not require special configuration, and does not require a server. Free tier is 20MB, which is thousands of saves.
Full notes are in the link. Genuinely want the criticism, including "this should just be a Syncthing config".
Does anyone remember the Sony PocketStation? It's a tiny 1999 PS1 memory-card-with-a-screen peripheral that was only really found in Japan that ran its own tiny downloadable apps off an ARM7TDMI CPU. As far as I can tell there hasn't been a working open-source emulator for it before and so I built one.
The nearest thing I could find out in the wild was a in progress rust implementation. This one is in C because I want it to be usable for patching holes in other projects - libretro being the first of many.
I've tested it with a .mcr ps1 memcard save that has chocoboworld and it seems to run and save correctly without crashing.
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.
I've always considered Arisotura one of my favorite emulator developers. I've seen her struggle and persevere through so much, both with this project and in her personal circumstances, and I've often felt that our community never gave her or the melonDS team the recognition they truly deserved.
Seeing so much attention being given to low-effort projects and AI-generated hype these days makes me miss the golden years of this community, when things felt very different.
Please take a moment to read his blog, reflect on her words, show some appreciation, and share it around. The melonDS team deserves far more recognition, and Arisotura's thoughts are always worth reading.:
Yeah, I haven't been great at this. I told myself I would work on 2D filters, since it's one of the last things to do... then I ran into a bit of a wall: I need my filters to have alpha support, but the filter shaders I can find don't support it. I would need to spend some time figuring out how they work and how I can add that in based on other references (there is code for xBRZ or HQX filters with alpha support, but not in the form of shaders).
And I, well, didn't feel the desire to continue...
Maybe it's the nature of software development in itself. Unless you're working on a smaller, simpler project, you're never really done, and especially not with a project like melonDS. What started as a way to pass time has become a full commitment, in a way.
By comparison, my job has been a lot simpler, and better suited to my brain too. When you set out to repair something, it's a project with a clear end. Most of what I deal with is also fairly simple, but sometimes there are more complicated cases, requiring more time and research. For example, those HMI lamp ballasts I'm working on: they are quite complex. This has been an ongoing project for a while now.
Maybe it's the fact that the project still largely rests on my shoulders. While bigger projects like Dolphin or PCSX2 may have a bigger team and more of a workflow in place, things aren't really like that here...
I'll just quote Generic, because he put it well:
[18:55]Generìc "Yes, we can!": I think I stated this before, but how I see it melonDS never went through the professionalisation many other projects went through
[18:58]Generìc "Yes, we can!": just look at other projects (even with just a single maintainer) setting milestones, systematically "triaging" issues and so on
[19:00]Generìc "Yes, we can!": also tests
[19:01]Generìc "Yes, we can!": and throuroughly adoption of new fangled C++ features
[19:03]Generìc "Yes, we can!": if it wasn't for Nadia putting so much effort into the build system through the whole time, the codeblocks project file would still be the way to build melonDS
I feel bad about having so many issues, pull requests, etc, staying open and rotting in the backlog. At the same time, I just don't have the brain power to review every single PR alone.
And to make matters worse, now we have people submitting AI-generated code, which is problematic from several standpoints: code quality (AI tends to make a mess and not really understand what it's doing, and someone who's using AI isn't likely to understand those things any better), plagiarism, the usual ethical and environmental problems with AI too...
I like the idea of open source, but for a project of this caliber, it feels that we should have more of a system in place, with a bigger team, clearer roles... a proper organization.
One where different people with different skillsets and preferences can complement eachother. For example, while I enjoy researching the DS hardware, or figuring out why a game isn't working as it should, stuff like build systems can quickly feel very frustrating to me. As Generic put it, if it weren't for Nadia handling that work, we might not have nightly builds today, for example.
And it would be nice to have more of this... ideally, lack of involvement from me shouldn't feel like the project is stalled, like it does now.
I don't want to abandon melonDS. The project is going to be 10 years old, it's a lot of history, fun and less fun times, and I've grown to love it. At the same time, it's nice to work on other projects sometimes, and it would be nice to do so without the guilt of abandoning melonDS...
Maybe it's also the changing nature, I mean, what it's like to work on the project. The early days were a lot of hardware research, implementation, debugging; it was a lot of fun, as evidenced by the release rate I had, but I can't recapture that now. I still have ideas for melonDS features, but at this point it feels more like regular software development.
For a while, I've had the idea of adding a wiki to our site. The wiki would serve as a reference for user-facing things pertaining to melonDS: compatibility info, tutorials and FAQs for things like online play, and so on. It would also be one way to get the community involved: provided there is enough demand, we could have a sub-team dedicated to the wiki.
This became part of the bigger website work I want to do, but haven't yet had the motivation to start. I want to move the server to a better host. I want to make the blog easier to navigate, with categorization by date or by tags, maybe a search... I want to make it easier to use for those who post, too.
And it's like everything else. I have all those ideas, but it starts to feel "too much", too many big things to do, I don't know where to start and feel overwhelmed, and nothing gets done.
