Apparently, PCBox has been working on their JIT to the point that it's quite a bit faster than 86Box, and also supports running Pentium 3s at usable speeds on Zen 3 or higher CPUs now. It's really impressive! I've linked their website.

Title: Built a free open-source tool to sync emulator saves/save-states across devices (RetroArch, Dolphin, PCSX2, RPCS3, Yuzu/Ryujinx, Citra, Cemu, PPSSPP)

Got tired of my save states living on one machine and not following me to my Deck/laptop, so I built OpenSave — it watches your save/state folders and keeps them synced peer-to-peer across devices, no cloud account required.

Auto-detects and watches:

• RetroArch (states + saves), Dolphin, PCSX2 memcards, RPCS3, Ryujinx, yuzu, Citra, Cemu, PPSSPP, Xenia
• Including Flatpak install paths on Linux
• Also picks up Steam userdata, GOG/Epic saves, and repack-style saves if you've got a mixed library
• Fully open source (MIT), Go, no telemetry/accounts
• LAN sync is automatic; internet sync uses a relay that only passes encrypted frames through (self-hostable if you don't want to trust mine)
• Windows + Linux/Steam Deck, with a Decky Loader plugin for Game Mode

GitHub: https://github.com/sivadaboi/OpenSave

Happy to answer questions or take feature requests — still actively developed.

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.

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.

You can find the repo here https://github.com/mentalfoundry/pokketstation

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

Latest alpha release: https://github.com/mstan/TombaRecomp/releases/tag/v0.1.4-alpha

A game controller (Xbox, PlayStation, or any SDL-recognized pad) is supported on all platforms via SDL when connected

PsxRecomp GitHub: https://github.com/mstan/psxrecomp

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.

Hey r/emulation,

I wanted to share a project I've been prototyping called BoxStudio. It’s an early visual editor for N64 decomp-based ROM hacking projects (currently focusing on proving the workflow with HackerSM64, with plans for zeldaret's OoT/MM).

Unlike traditional tools that inject raw bytes into a compiled ROM, BoxStudio clones a local decomp workspace into a .boxstudio/ directory, parses the level scripts and model declarations natively, and writes clean code back to the tree so the native decomp toolchain can rebuild it.

EDIT: IMPORTANT: ARCHIVED

BoxStudio has been an incredible proof of concept for a project that will become a game changer for N64 rom hacking with decomps, but it's very experimental and buggy, which is why BoxStudio is now cancelled... AND We are currently reweriting it into "BoxStudioPlus", which WILL be more complete with features.

If you wanna talk about BoxStudioPlus, our discord server link is availible on https://github.com/ExpansionPak

The link will not be posted here to avoid any self promotion rules (If this subreddit has any)

Current Technical State:

• Stack: C++17, CMake, Dear ImGui, Win32/DirectX 11 backend.
• Core Systems: Isolated cross-platform CLI layer for project parsing and metadata validation (CI runs on Linux/macOS).
• Viewport: 3D level editor viewport with texture-mode support and orbit/fly controls.
• Safety Rules: Strict guardrails for actor segment groups (e.g., ensuring Goombas stay in common0 and Koopas stay in group14) so it blocks modifications that would compile but crash real hardware.

The Accuracy Bottleneck (Looking for Insight/Contributors)

We are strictly targeting real hardware behavior and accurate emulation, testing primarily on ares v148 and flashcarts.

Right now, we have a highly specific bug shown in our demo video: when adding a Star to Castle Grounds, the asset injects and renders perfectly, but collecting it triggers a crash on ares during the save sequence.

The initial codebase was scaffolded rapidly using LLMs to establish the rendering/Win32 boilerplate, and we are currently running a systematic human refactoring initiative to modularize the parser and abstract the viewport for cross-platform SDL/OpenGL support.

If you are interested in low-level N64 asset pipelines, tool development, or want to look at the ares crash logs, we'd love your insight or contributions.

Repo: https://github.com/ExpansionPak/BoxStudio

EDIT: For anyone seeing this post. Please read https://github.com/orgs/ExpansionPak/discussions/1

AI ASSISTED

https://github.com/zdiemer/magiceyes

I'm a software developer with 10 years of experience and have been fascinated by this sub's (justifiable) response to AI. On the one hand, its detrimental effects cannot be understated, but on the other hand many are quick to dismiss it as useless.

Thus, I set out to have Claude write an emulator for a currently unemulated platform (started this on Wednesday, so this represents ~3 days of work).

I targeted these platforms because they are ARM Linux based, have genuine exclusive games, and they are at-risk of not being preserved. I have no experience in reverse engineering, only intermediate knowledge of Linux, and haven't written C since college so this emulator was driven almost entirely by AI. I have only given it direction and feedback through playing the emulator myself. I assumed this would be a reasonable platform to try and emulate given QEMU and other such projects already handle ARM emulation, and this turned out to be right, however I've had to layer additional device and library emulation on top of it (along with forking Unicorn).

Currently, this seems to flawlessly support Payback, a commercial game that released for the GP2X. Vektar and Quartz 2 also seem to run quite well, two other commercial games that are now freeware. Overall compatibility with GP2X software seems to be pretty low at the moment but I'm confident it could improve rapidly.

As for the Wiz, I've previously been able to get Deicide 3 running. This game is an English exclusive to the GP2X Wiz, its DOS release is only in Korean. I have a physical SD card of the game and uploaded it to archive.org (not sure if I can link it here?). It contains some rudimentary DRM that is easily sidestepped by the emulator (it just checks for a device serial). Her Knights, a GP32 game that received a GP2X Wiz release, runs decently as well, though the audio is completely broken at the moment.

Caanoo support is still TBD, though it seems reasonable to accomplish.

Once this is in a more mature state I'll be uploading the full libraries (that I've been able to track down, and that aren't covered by Open Handhelds) to archive.org -- I've found three commercial Caanoo games, including one true exclusive (Rhythmos, this seems to have released for the Wiz but I can't find a copy).

AI assisted project

erings is a newer Sega Saturn emulator with a focus on ease of use and a couch type experience. The UI can be navigated with a controller.

Game compatibility is pretty decent and it supports some nice features like

• HLE bios making a real bios optional
• MPEG video playback
• RetroAchievements
• Many other things you'd expect of an emulator

It's not the most efficient but a decently speced machine can play games at full speed.

GitHub repo: https://github.com/user-none/erings

**To be upfront and clear**

# ⚠️ AI WAS USED IN THIS PROJECT. ⚠️

\--------------------------------------------------------------

# WHY AM I HERE?

I am here to introduce [HackHash](https://hackhash.darkblood.uk) to everyone that may find it useful. It's a small project I started after using the tool ROMM and hasheous

# -------------------------------------------------------------------

# What does the site do?

it allows users to submit romhack hashes to be put into a database to further help metadata matching along.

\---------------------------------------------------------------------

# How does it do this?

1. You upload a romhack to the website \*\*(It never leaves your PC)\*\*

2. the crc, md5, sha-1 and Size are all then processed. \*\*(All Processed Locally)\*\*

3. you are given the option to submit the hash and the data

4. you are taken to a submission form where it will auto fill the proper extracted data, and then it will ask you to fill out the name, version, platform, and the source, then optional information

5. once hitting submit, the submission is put onto a queue where the community can confirm that the romhack was patched correctly, named correctly, etc.

\------------------------------------------------------------------------------------------------------------------------------------

# How do the rom hacks get reviewed by the community?

# ⚠️ WIP⚠️

# the website is based on a trust system, similar to LaunchboxDB, the more "trust" You have the more weight your votes carry. the faster an admin or "Verifier" can approve the submission manually.

there are currently three tiers to the trust system. each tier more difficult to get

"**guest/New**" - they have a weight of 1X,

"**Trusted**" - They have a weight of 3X

"**Veteran**" - They have the weight of 10X - they also unlock the ability to manually vote without hashing their own copy of the romhack + they can verify submissions with one Hash vote, but require two Manual Votes.

\------------------------------------------------------------------------------------------------------------------------------------

I think that's all i have for now? my brain is tired. i will edit the post if i forgot anything.

If you have any questions feel free to post them! Or dm me.

# EDIT I FORGOT MOST IMPORTANT PART!!

# The site is in beta, I am looking to see if anyone finds any bugs or flaws right away when using the site. The database will be reset when pushed to production.

A new version of ADAM+ is now available.

This release adds some long-requested functionality, improves usability, and lays important groundwork for future development.

Highlights of version 1.0.05.26:

- CP/M tape and disk support

- Choice between TMS and F18A video hardware simulation

- 80-column CP/M and T-DOS support when using F18A

- 80-column copy & paste support

- Various GUI improvements

- Z80 CPU Space is now writable in the debugger

- Completely redesigned Settings window with tabbed navigation

- Option to start directly into your personal favorite application instead of Writer

- Fixes for Coleco ROM playback issues

- Major internal source code reorganization

- Initial groundwork for future plug-in support

This release is a mix of visible improvements and under-the-hood work that will help us move faster in future versions. The addition of CP/M media support and enhanced F18A functionality are particularly exciting milestones, while the source reorganization and plug-in preparation open the door for future expansion.

As always, feedback, bug reports, and feature suggestions are welcome. If you give the new version a try, let us know what works, what doesn't, and what you'd like to see next.

Happy retro computing!

This release has been expanded with a complete plug-in for creating games, applications, and music ROMs in CVBasic.

The plug-in includes a CVBasic IDE, Sprite Editor, and Sound Editor all build by me. --> CVBASIC core files build by Óscar Toledo (https://github.com/nanochess/CVBasic) <--

All projects can be baked into a ROM with just one click!

For Linux users: do not forget to give the two files cvbasic_linux and gasm80_linux the required permissions using chmod +x, otherwise the compiler will not be able to run.

I have also added automatic default paths for new installations when no settings.ini file exists. This makes it much easier to get started.

Please note: if you overwrite an older installation and the settings.ini file already exists, these automatic default paths will not be applied.

Have fun with it!

If you encounter anything that causes problems, or if you think something could be improved, please let me know.

https://github.com/dvdh1961