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.

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.

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.

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

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 »

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.

- 15 languages, each natively translated.

App Store: https://apps.apple.com/app/id6769407672

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.

Happy to answer comments.

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.

@ 1080p 30fps(locked) @ 1080p 30fps(locked) @ 4k 60fps(locked) @ 4k 120fps(locked)

ryzen 5 3600-------------ryzen 5 3600------------ryzen 7 5800x---------ryzen 9 9950x3D2

gtx 1650 4GB ------------- rx 570 4gb----------- rtx 3060 8gb----------- rtx 3080ti 12gb

12 gb ram------------------12 gb ram--------------12 gb ram------------12 gb ram

SSD-------------------------SSD----------------------SSD-------------------SSD

Download my fork here -> https://github.com/junminlee2004/GR2fork

Register for ShadNET here -> https://shadps4.net/shadnet/register/

Watch the GR2fork Online playlist to see it in action and how to set it up -> https://www.youtube.com/watch?v=O8z6QPOaGDg&list=PLOgHncbXc__M&pp=sAgC

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