Emulation

ES-DE is a frontend for browsing and launching games from your multi-platform collection.

Release overview
This release adds official (although experimental) support for Linux on AArch64, which is aiming for operating systems such as the upcoming SteamOS release for ARM. It also adds support for a lot of new emulators across all the main supported operating systems.
For Android specifically there are three new systems enabled, those being Namco-Sega-Nintendo Triforce (triforce), Microsoft Xbox (xbox) and Microsoft Xbox 360 (xbox360). And although the Sega Model 3 (model3) system was technically supported in the previous release, it wasn't really usable in practice due to only MAME being available for these games, but now these games are fully playable due to the new SUPER3 emulator. Likewise PICO-8 is now much more usable on Android as the official Raspberry Pi build can be used via an unofficial PICO-8 wrapper. Support for multi-user setups has also been fully rolled out for all RetroArch cores as of this release, meaning ES-DE should now work correctly in Android multi-user environments.
On macOS three new systems have been enabled as well, those being OpenBOR Game Engine (openbor), Namco-Sega-Nintendo Triforce (triforce) and Microsoft Xbox 360 (xbox360).
As for general cross-platform topics, a new language has been added, which is Vietnamese. There are also a couple of general bug fixes and translation updates as well as some dependency library updates. There are also quite a number of new standalone emulators and RetroArch cores added for many systems, see below for all details.
Under the hood the remaining ancient Raspberry Pi specific code and configuration has now been fully removed, meaning there is no longer any device-specific code or configuration whatsoever in ES-DE and everything is instead completely generalized.

Finally a successor to the very out of date DolphinVR fork. DolphinXR is a GameCube / Wii emulator, allowing you to play games for these two platforms on PC with improvements and in VR. - iChris4/dolphinXR

I hope you enjoyed our April Fools’ Day announcement. With that out of the way, it’s time to discuss actual upcoming changes to MAME. We’re upgrading the development language standard from C++17 to C++20 and winding back support for obsolete configurations. We’ll also be reducing the frequency of releases a bit, so there will no longer be a release nearly every month. There will be no April release; our next release will be near the end of May.

A summary of updated requirements:

A compiler and C++ standard library with a reasonable level of C++20 support. GCC 11 is the oldest version of GCC that we will support. You can also use a reasonably up-to-date version of clang.  
Windows releases will require an updated installation of Windows 10 or later. Microsoft has already discontinued mainstream support for Windows 10, as well as all prior versions of Windows Home and Pro, and Windows 11 is already four years old.  
MAME’s Qt-based debugger will require Qt 6.  

A summary of some functionality we’re removing:

The 32-bit x86 (i686) recompiler back-end. It’s been over two decades since the x86-64 architecture was introduced. All major x86 operating systems have supported x86-64 for years, and 32-bit x86 support is being wound back.  
Support for compiling on OpenSolaris and other System V UNIX systems. There are no actively developed OpenSolaris distributions remaining, and no other System V UNIX variants have a meaningful presence on desktop systems.  
Specific optimisations for PowerPC host systems. PowerPC and OpenPOWER currently have no meaningful desktop presence, and the Libre-SOC project to produce a completely free, high-performance OpenPOWER implementation has stalled.  
The obsolete aueffectutil tool for macOS. This tool is no longer relevant with MAME’s new audio output system, and it had not been updated to work with recent versions of macOS.  
The pre-built MSYS2 environments with included development tools. There are multiple issues with our MSYS2 environment that we can’t practically solve.  

Read on for some more background and details.

We’ve decided it’s time to upgrade to the next version of the C++ standard and start taking advantage of the new functionality. It’s been long enough that libraries and tools with adequate C++20 support should be widespread. We’ll support building with GCC 11 and GNU libstdc++ 11 or later for now. If you’re using clang to compile MAME, please be aware that clang 11 and 12 have unacceptably bad bugs in their implementation of C++20, and clang 13 may crash when compiling some constructs. This means you may need a reasonably up-to-date version of clang to continue using it to build MAME.

Similarly, Qt 6 is available in MSYS2 and has been provided by all major Linux distributions for quite some time. We feel it’s a good time to remove support for Qt 5.

Due to increased memory usage of newer versions of GCC and the removal of clang and other LLVM-related packages from the MSYS2 MINGW32 package repository, it’s no longer practical to create 32-bit x86 builds of MAME for Windows. As such, features for supporting 32-bit x86 on Windows will become unmaintained. Since 32-bit x86 support in other operating systems is also being scaled back, we’ve decided it’s no longer worth the effort to maintain features catering to 32-bit x86 specifically. We’re removing functionality catering to PowerPC specifically at the same time as it has become similarly impractical to maintain.

We will be switching to building x86-64 Windows release with clang, the libc++ standard library, and the Microsoft Universal CRT (UCRT) C runtime library. This will mean our 64-bit x86 and ARM releases will be built with the same tools and libraries.

It’s become apparent that support for MSYS2 environments using the obsolete MSVCRT C runtime library is being wound down. Various packages are being removed from the repositories rather than being updated. It will become necessary to migrate to one of the environments using the UCRT C runtime library, i.e. UCRT64 or CLANG64 for 64-bit x86, or CLANGARM64 for 64-bit ARM. Our build scripts currently include support for building MAME using these environments with no additional effort.

There are multiple issues with the pre-packaged MSYS2 environments we provide for download. These include:

They have not matched the exact package versions used to build MAME releases for a long time, so they are not useful for reproducing official MAME releases.  
They are updated infrequently. This makes trying to update the core MSYS2 runtime or any of the included packages fraught with issues, as MSYS2 packages often have poor support skipping multiple versions when updating.  
Including packages to support building MAME across supported configurations, as well as generally useful development tools, would make the download impractically large. On the other hand, omitting packages leads to users encountering all the issues with updating MSYS2 packages when they attempt to add packages to support their use cases.  
Packaging development tools isn’t part of our core mission, so to speak, and takes time away from working on MAME development.  

As such, we recommend installing a standard MSYS2 environment and installing packages needed to build MAME using the pacman package manager command. We list the necessary packages in our documentation, and our Windows workflows on GitHub Actions show the necessary packages in a structured form.

There will always be some bumps in the road with a major change like this, but we believe this is a necessary step as part of our mission to keep MAME development viable for the long term.

But why?... Asphaltian in the comments: I'm planning a scripting API to allow anyone to create add-ons for any ROM you want, just not a priority right now. And because why not? Besides, I have lots of plans in store for it too.

Fast PlayStation 1 emulator for x86-64/AArch32/AArch64/RV64 - Release Latest Rolling Release · stenzek/duckstation

• Qt: Tweak slider colour in Dark Ocean theme
• 28c34fe Qt: Use saveAndReloadGameSettings() instead of manual save
• efa9741 Qt: Warn when changing renderer for the first time
• 0f7eed0 dep/imgui: Update to 3a26b64
• 805dce4 FullscreenUI: Add outline renderer
• aebca6a ImGuiOverlays: Use outline text for OSD

I swear I had a Japanese version (Super Famicom) with better hover cars back in the day although my memory is shaky about it.

You know how the movie Inception was like a dream within a dream? Well, the Dolphin emulator can now emulate the Game Boy Player within the emulator itself, meaning that the GameCube has some inception of its own going on!

It is rare that the MAME Team addresses the community with news of this magnitude, and we want to approach this moment with the transparency and care it deserves. What follows is a candid account of where this project stands, where it is going, and why the decisions we have made — difficult as some of them are — represent the most responsible path forward for a codebase that has grown into one of the most complex preservation efforts in the history of open-source software.

Game Boy / Game Boy Color / Super Game Boy emulator, debugger and embedded MCP server for macOS, Windows, Linux, BSD and RetroArch.

• 🎨 Added Super Game Boy support
• 🎯 Improved accuracy
• 👾 [libretro] Added webOS and Linux aarch64 support
• 🧠 Improved MCP server + skill
• 🐛 Many improvements and bug fixes

Plus: A launcher for recompilations and a new PS1 fan translation.

by Wes Fenlon

March 29, 2026 — 15 min read

Hello hello hello! In this week-late-but-worth-the-wait edition of ROM, I'm back to my old hijinks with a meaty interview for one of the most exciting open source projects on the scene right now: ReXGlue, the Xbox 360 recompilation tool.

The Dream Color Plus really is the gift that keeps on giving. Fans of the Dreamcast have been rejoicing over the fact that Angelo Pontes, aka Nai Adventure, has shown off the new Dreamcast controller with two joysticks, finally righting a 28-year wrong. It always amazed me that it only came with one stick when the other consoles of the time were boasting two, and perhaps that's one of the reasons why it didn't succeed as well as the competition.

For the past few weeks, our lead developers have been focusing on redesigning the ingame overlay of the emulator and we're announcing these updates with this video!

Everything shown is already available, just update RPCS3 and give it a try!

DMG/GBC/GBA emulator and experimental NDS emulator. - Release GBE+ 1.10

Ain't nobody got time for jokes today! There are some pretty sizable additions with the new GBE+ 1.10. Here's a breakdown of all the developments over the past year.

Notable Changes:

• Added support for the Wave Scanner, for use with Ryuusei no Rockman on the DS.
• Added support for the Wantame Card Scanner, for use with Wantame Music Channel: Doko Demo Style.
• Added support for the unreleased Vaus Controller. Allows you to use joysticks to control the paddle in Alleyway on the Game Boy.
• Added support for the unreleased WorkBoy. Allows you to use a QWERTY keyboard to emulate the WorkBoy's keyboard.
• Added support for sending and receiving Nectaris maps. This brings GB KISS support to 100%.
• Added support for the Bayer Didget. This is mostly a copy of the Glucoboy, but for the NDS.
• Added support for file fragmentation when running dumps of AM3 SmartMedia cards.
• Added stereo support for the GBA core.
• Completely reworked networking in DMG/GBC and Pokemon Mini cores. Allows for easier disconnects and resets (without segfaults!)
• Save States are now versioned. GBE+ will refuse to load incompatible versions. Everything from 1.9 and before will not work, so consider booting up from a .sav file and making new ones for 1.10.
• Save States now have Time & Date metadata in format YYYY-MM-DD HH:MM:SS. GBE+ will display this in the GUI, letting you see which save states you've used and when you last used them.
• The Qt GUI now displays FPS in the titlebar.

Other structural changes have been made to better facilitate GBE+'s transition to SDL3 once a stable release of SDL_Net 3.0 comes out. GBE+'s architecture should be able to accomodate a Vulkan backend in the future as well.

3DS Emulator.

- GPU emulation improvements:  
    - correct lighting emulation  
    - normal mapping, shadow mapping  
    - fog  
- Camera and Mic support  
- Motion controls fixes  
- New game list UI  
- Other misc fixes/improvements  

It’s the end of another month, which means it’s time for another MAME release! As you’d expect, MAME 0.287 includes a wide-ranging array of emulation improvements to a multitude of systems. Interesting changes this month include better Namco System 23 graphics, improved lighting for Sega Model 3, and software-controlled volume control/panning for Philips CD-i (along with improved stability).

The GRiD Compass family has received a keyboard overhaul as well as an initial DAC sound output implementation. The Apple II family now handles tricky raster effects more realistically, as well as getting a substantial software list update (metadata for the MECC collection is in much better shape). And speaking of software lists, a couple of NES prototypes have been added.

Three months have passed since the last release, and here we are again, with our new release approach. We are both worried and excited, but hope that in the current reality of the absence of pre-release testing, with more frequent releases, we will …

• Add dosbox.conf option to control the duration of the beep when
  DOS CON and INT 10h are given the BEL character. (joncampbell123).
• DOS CON device BEL (beep) handling: For IBM PC modes, call on
  INT 10h to make the beep, rather than duplicate code. Fix the
  DOS CON device so that it can also properly beep in PC-98 mode.
  (joncampbell123).
• Fix bug where the "zero memory on DOS allocation" option was
  stuck on. Some games, like "Bad Cat" rely on memory contents
  peristing across DOS EXEC and memory allocation. (joncampbell123).
• Fix Hercules palette selection related to herc blend. (joncampbell123).
• DOS kernel: When executing an EXE file, the loader can now detect
  EXE files that were compressed using EXEPACK. Based on the new
  exepack dosbox.conf setting, it can decompress the EXE by itself,
  switch off the A20 gate, or do nothing. The purpose of this
  setting is to avoid EXEPACK "Packed File is Corrupt" errors that
  happen if the A20 gate is enabled and the EXE was loaded too low
  in memory. (joncampbell123).
• Linux SDL1: Use XDG_SESSION_TYPE environment variable to detect
  whether or not the user is running DOSBox-X under X11 or Wayland,
  and if so, prevent the fbcon and svga drivers from initializing.
  There seems to be a problem where, if run under Wayland and the
  XWayland compatibility layer if not present, SDL1 uses the fbcon
  driver to take over the screen using vtcon switching and the classic
  fbdev driver interface. Don't do that! (joncampbell123).
  INT 21h AH=4Ah resize memory: If memory resize fails because there
  is not enough room for the requested amount of memory, do not
  set ownership of the block to the program. This fixes memory
  allocation error in California Games II. The game at one point
  seems to miscalculate and ask for an excessively large amount
  of memory on resize, and then fail, which doesn't seem to affect
  the game. HOWEVER, prior to the bugfix, the memory block that
  was available was assigned ownership to the game anyway. Later
  on after helicopter takeoff, the game would attempt to allocate
  more memory, which would fail because of the erroneous assignment
  of ownership to free memory. (joncampbell123).

Recently I stumbled on the DKcafe frontend. It is an emulation frontend for the original Donkey Kong, Donkey Kong Jr., and Donkey Kong 3,* but also for countless Donkey Kong ROM hacks. What makes this frontend unique is the gamified experience.

When you load the frontend, you end up in an interface that looks like a classic Donkey Kong level. You control Jumpman (Mario) and can jump and climb ladders. But in the background there are several arcade machines. (Initially only one to three, depending on the ROMs you have provided for games). And on the top of the level, Donkey Kong is standing, throwing barrels at you but also coins. By collecting the coins he is throwing, you can unlock more arcade cabinets that are ROM hack variations of the game.
Additionally, while playing the games or ROM Hacks and get a certain amount of score, and you can win trophies, and when you exit the game, you get rewarded with a large amount of coins, unlocking the coins faster.

DKCafe also includes an add-on that you can download separately from the project GitHub page or from inside the front end itself. This add-on includes ROMs and ROM hacks for the home computer versions of the first Donkey Kong game.

You do not need to provide an emulator for the frontend, it comes with its own emulator called DKWolf, which is based on WolfMame. I am not sure what exactly is different about WolfMame and regular Mame, its GitHub page does not provide an explanation. It just explains what Mame is. I assume it focuses on ROM hacks, but I am not sure. You can also replace it with your own emulator if you want to do that.
The emulator is in the DKWolf folder in the root directory and can be run on its own. It can be configured as a standard MAME, emulator cheats can also be enabled. They seem to work with many ROM hacks but not with all.

The frontend also includes additional features. Like a practice mode to improve your DK skills. The ability to continue and DKTV an alternative viewpoint of the game. Jumpman is fixed to the center of the screen as the camera follows his movements. The camera zooms in further on the action when Jumpman is jumping or hammering.

The ROMs go into the ROM folder in the root directory. You have to provide your own ROMs for the three arcade games. Though I did not manage to get Donkey Kong 3 running with it. The arcade cabinet for the game did not appear in the frontend. When I tried to run DKWolf from the command line with Dkong3 as a parameter, it informed me that all files were missing even though they were in the zip file. And it runs with regular MAME, so I am not sure what is going on there.

DKCafe runs on Windows and Raspberry Pi 4. It also provides instruction to compile it for Ubuntu Linux, but they are a bit complicated. Though it does run with Wine on Linux without any problems unless the Donkey Kong 3 issue is related to that.

In conclusion, I love this idea and would love to see it for other games like Pac-Man, for example.
I also would love if DKcafe would add ROM hacks for Donkey Kong Jr. and Donkey Kong 3. Also maybe for the Game Boy Donkey Kong game from 1994.

Link

Game Boy / Gameboy Color emulator, debugger and embedded MCP server for macOS, Windows, Linux, BSD and RetroArch. - Release Gearboy 3.8.0 · drhelius/Gearboy

• 🎯 Improved accuracy
• 🧠 MCP server + SKILL with optional headless mode for AI assisted debugging and hacking
• 💾 Desktop app migrated to SDL3 + OGL3
• ⚙️ Completely redesigned debugger with new features and windows
• 🔈 Improved audio latency with configurable settings
• 🖼️ Improved fullscreen mode
• 🗒️ New option to load default settings
• 🖥️ Support for vsync in 120/240 Hz screens
• 🍺 Homebrew tap for macOS
• 📦 Ubuntu PPA repo
• 🐛 Many bug fixes

" This frame of Screamer 2 was rendered not by an original 3dfx card and not by an emulator, but by an FPGA reimplementation of the Voodoo 1 that I wrote in SpinalHDL. Available on GitHub.

What surprised me was not just that it worked. It was that a design like this can now be described, simulated, and debugged by one person, provided the tools let you express the architecture directly and inspect execution at the right level of abstraction.

The Voodoo 1 is old, but it is not simple. It has no transform-and-lighting hardware and no programmable shaders, so all of its graphics behavior is fixed in silicon: gradients for Gouraud shading, texture sampling, mipmapping, bilinear and trilinear filtering, alpha clipping, clipping, depth testing, fog, and more. A modern GPU concentrates much of its complexity in flexible programmable units. The Voodoo concentrates it in a large number of hardwired rendering behaviors.

One of the bugs that drove this home looked at first like a framebuffer hazard. Small clusters of partially translucent text and overlay pixels would go mysteriously transparent, even though most of the frame looked fine. The real issue turned out not to be one broken subsystem, but several small hardware-accuracy mismatches stacking up in exactly the wrong way. That bug ended up being a good summary of the whole project: the hard part was not "making triangles appear." It was matching the Voodoo's exact behavior closely enough that the wrong pixels stopped appearing.

This post is about the two abstractions that made that tractable. The first is how I represented the Voodoo's register semantics in SpinalHDL. The second is how I debugged a deep graphics pipeline using netlist-aware waveform queries in conetrace. "

cont. in dev blog.

tl;dr: "I forked mGBA to print Game Boy Camera output directly to a thermal printer."

"The Game Boy Camera was brilliant and stupid in equal measure, a 128x112 pixel sensor bolted on top of a cartridge, printing to thermal paper on a Game Boy Printer the size of a brick. I got both for Christmas when I was 12 and somehow spent hours with them. The minigames are absurd, the image quality is aggressively awful, and the whole thing looks like a prop from a cheap sci-fi film. I loved it."

Cont. reading in linked dev blog.