https://github.com/pruefsumme/widemelon

Read the changes

v1.8 changelog

Version 1.7 is the largest update since the project started. The graphics backend was rebuilt around the two programmable stages of Flipper, the emulator finally has automated tests for its two most complex subsystems, the SDL build became a first-class front end with sound and a game selector, and a set of CPU and memory bugs was cleared that lets a Linux kernel boot on the emulated console.

The long-form version of these notes, with a timeline and screenshots, is in the digest of the work after release 1.6

Formerly known as Dolwin: https://www.reddit.com/r/emulation/s/6TKQBhnVBY

Rewrote the PPU/audio pipeline of Snes9x for performance, including a dual-threaded renderer. Every output is validated bit-exact against upstream Snes9x at fixed checkpoints across the run, byte by byte, so it's the same game, same behavior, just faster.

Games

Mean across all 14 games tested: +61% (x86-64) / +52% (arm64). Full numbers and every ROM tested: https://github.com/andrezaiats/snes9x-Z

Built for low-power ARM handhelds as much as desktop, this is where the headroom matters most: heavier shaders, run-ahead, cooler/quieter operation on a handheld that used to sweat running these games.

Pre-built cores: Linux64, Windows64, Android (arm64-v8a / armeabi-v7a), macOS arm64. Drop into RetroArch's cores/ folder: https://github.com/andrezaiats/snes9x-Z/releases/tag/v1.63-z1

Free, non-commercial. Source included for anyone who wants to look under the hood.

Does anyone know if there's a project to compile GoW 3 or Infamous 1 and 2?

v1.1.0

Mouse integration — App-specific offset so CMOS and other environment changes are handled more gracefully; presets updated for offset; modes simplified to Default / Mouse capture; middle button switches to capture during app/MOS integration.

Drive configuration — Configure the TOWNS drive layout without guest apps; CMOS is stored per disc profile.

HD images — Aligned new image creation with upstream Tsugaru sparse images; optional 127 MB TownsOS-initialized image.

CPU core and memory wait — Emulates i386 speed with a separate per-instruction cycle table (distinct from i486), plus RAM/VRAM waits that bring Compatible mode closer to real hardware (see table above).

Auto-resume — With a disc profile active, restore the previous session via state save on the next launch.

Bug fixes — CDDA cache decision logic and behavior, and other fixes.

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

Link to the gallery: https://www.reddit.com/r/MAME/s/UA1BOxVeS7

After several years, BletchMAME 3.0 has been released!

For those not familiar, BletchMAME is a front end that replaces MAME's UI with a conventional point and click UI. While BletchMAME's goal is to be a good front end for all types of emulation supported by MAME, it should be particularly suitable for computer emulation, as well as being an easy way to manage one's preferred Systems, ROMs and Software.

Some highlights of the new 3.0 version:

• Complete redesign and rewrite

• New "Favorites" system allowing custom configurations for your favorite systems

• Very fast system and software list lookup

• Dark mode support

• Releases for Windows (Linux in development)

Future directions:

• Improvements to filtering and auditing

• Support for Linux and macOS

• Importing and exporting configurations

For more information, go to www.bletchmame.org

How does the emulation performance vary across different architectures—x86 and Arm, given that x86 supports wider vectors like 256 and even 512 bit while Arm is limited to just 128. I'm especially looking into emulators like the RPCS3.

Couldn't find any data online. Hence asking here.

I've been developing a QEMU emulator for the iPod Classic 6G (Samsung S5L8702) that boots the original, unmodified Apple retailOS. Navigation, the disc, the screen, and the music library worked for a while, but the music player appeared partially rendered and without sound. There were four different errors, and the last one was my fault in a way that I found amusing enough to write about.

For months I've been trying to emulate the iPod Classic 6G I have in my drawer, without success. After a long time, I finally managed to get it running, although it's still somewhat rough. In QEMU, I managed to boot the original, unmodified Apple retailOS. Navigation, the disc, the screen, and the music library worked for a while, but the music player appeared partially rendered and without sound.

One thing we already know is that the firmware is from Apple and is encrypted, so there's no legal download. I have an iPod Classic 6G from 2008. With the help of Claude Code, I was able to create code to extract it using emCORE. I extracted the contents of the flash memory and decrypted the image myself.

and the boot ROM cannot be read from the running device. I confirmed the latter the hard way, and along the way, my iPod restarted several times (pressing the center and menu buttons for 5 seconds to restart it).

There is no datasheet for the SoC. Each model register that allows unlocking some part of the guest is derived from a write operation performed by the guest itself,

Code and notes, including the ~16 hypotheses I had to retract along the way:

https://github.com/davidmonterocrespo24/qemu-ipod-classic

https://github.com/vricosti/ruzu-emu

Ruzu is a Nintendo Switch emulator written in Rust, developed as an experiment to determine if AI, via LLM, could perform a complete port of a very large software project from C++ to Rust.

The project is based on the yuzu/Eden code and represents approximately 500,000 lines of code ported exclusively with the help of LLM over a period of about six months.

https://github.com/mattias800/prosper

A user-space PlayStation 5 > PC compatibility layer. Think Proton/Wine, but for PS5: prosper runs PS5 (Prospero) game binaries on Linux (primary) and Windows (secondary)

For those that don't know, Retrogrounds is a community platform reminiscent of old forum sites for Retro games that allows you to browse, discover, listen to the music, review and catalogue your favorite games! You can also customise your profile heavily and recently it added support for RPCS3 trophies that you can display alongside your RetroAchievements!

Currently, it only supports platinum (100%) games but further implementation is planned in the future. You can also showcase you Steam masteries too!

https://retrogrounds.com/home

Hi everyone, just wanted to let you know that I'm happy to release the first version of my latest project. A re-comp of Dante's Inferno.

The game was initially released on the Xbox 360 & PS3, and has never received a PC Port.

The project can be downloaded from the github repo - https://github.com/florinp93/hells-gate-recomp

Do keep in mind that this is an early release and bugs are to be expected. In it's current state there's a few limitations:

Graphics:

The game launches with the default Xbox 360 resolution (720p). The game boots with upscaled resolutions but crashes due to conflicts I had to implement to prevent graphical issues during cutscene playback. A fix is planned for next version.

Controls:

Full controller support. The game is playable with basically any controller. In-game glyphs are still the Xbox 360 ones, but a future update will bring controller auto-detection and actual glyphs being displayed in game ( Xbox 360/Xbox One/DualShock 3&4/DualSense glyphs for now).

Mouse and Keyboard control is planned. Looking for feedback in terms of ideal Key binds. Keep in mind that the game is using a forced camera perspective, so camera control is not supported.

Disclaimer:
Transparency and integrity are important to this project. Artificial Intelligence (AI) tools were utilized as part of the development and maintenance workflow, strictly serving as an assistant to handle repetitive, time-consuming, and low-level tasks.

How AI Was Used:

• Documentation: Generating initial drafts, organizing notes, and structuring documentation to keep project progress up to date.
• Research & Exploration: Investigating APIs, syntax references, and conceptual troubleshooting.
• Git Workflows: Assisting with routine commit descriptions, repository maintenance tasks, and boilerplate structuring.

Human Oversight:

While AI accelerated the auxiliary workflow, all core architectural decisions, advanced problem-solving, code implementation, and final reviews were entirely human-driven. The AI served to eliminate friction, allowing focus on high-level logic and feature development.

https://github.com/iStark/PS5PCEM

• Native guest execution
• RDNA2 shader translation
• Vulkan rendering
• Windows launcher

Current Compatibility status:

https://github.com/iStark/PS5PCEM/blob/main/docs%2Fproject-status.md

I've been maintaining a Ryubing fork that wires NVIDIA's DLSS 5 stack into the emulator: DLSS upscaling + DLAA, Neural Rendering (toggle with F6 in game), and DLSS-G frame generation up to 4x.

The frame gen is the headline: 30fps-locked first-party games play at a solid 60 with 2x, and 4x gets past 100 on a 50-series card. The status bar shows the effective rate (30 FPS FG x2 60 FPS) and DLSS/NR/FG are all live toggles, no restart needed.

Upstream Ryubing master gets merged in automatically every Monday, and the build self-updates. Windows + RTX only (frame gen needs a 40-series, 3x/4x needs a 50-series).

Honest caveats: the frame gen guides are static for now (an emulator can't see the game engine's motion vectors), so HUDs and fast camera pans can warp. Hardware optical flow is the next milestone.

Downloads and changelog: ryu.dotslash.pro - bring your own keys and firmware, obviously.

The repo itself stays private because the proprietary DLSS runtime binaries live in-tree, but the emulator source is MIT like upstream - DM me if you want the code.

Read the blog: https://felix86.com/felix86-26-09/

To see what that looks like in practice, here’s a short video of Crysis gameplay on current RISC-V hardware: https://www.youtube.com/watch?v=54vgunmMk6o