If you were lucky enough to own a Dreamcast back in the day, and even luckier to experience its online functions via the Broadband Adapter, then you may have come across Bomberman Online, a superb puzzle game that allows you to blow up your enemies in unique and mind-boggling ways.

It's not long since I clicked publish on an article about The Wind Waker being decompiled, and now here I am, writing about The Minish Cap going through the exact same process.

Video Overview: https://www.youtube.com/watch?v=St-5e9sZYzU

OP copy pasta: After a few months in development, I am excited to reveal the first release of GR2fork, a fork of shadPS4 focused on improving the performance, stability, and accuracy of Gravity Rush 2. Thank you for your patience and if you can please support me by buying me a kofi.

NOTE: this fork currently also supports version 1.11, also please do not enable readbacks.

introduced several code optimizations to increase cpu performance (+30% boost over latest pre-release)  
delivered feature complete photomode by coding in stubbed shadps4 functionality such as content search, screenshotservice, and content export. It is now 1 to 1 with the ps4 version.  
improved rendering accuracy by tweaking shader recompiler code  
the contour cel shading outline is now visible  
foliage is now correctly rendering  
better gravity kick audio fix than the mainline version  
removed all video artifacts from cutscenes to in game videos and TVs  
identified and patched several crashes by clamping vulkan layers >512 and tweaking problematic code that caused race conditions  
added null absorption code to signal handler to prevent some benign null reads from crashing the entire emulator, opting to skip the instruction instead  
added more input control to allow emulation of the touchpad swipes  
All polaroid photos captured in game are saved to the Capture Gallery folder in the shadps4 user/appdata folder on your pc so you can access them directly.  

Minimum Requirements:

@ 1080p 30fps (LOCKED)

CPU: Ryzen 5 5600X

GPU: GTX 1650 4gb / RX 6400 4gb

RAM: 12gb

Recommended Requirements:

CPU: i7 12700 / ryzen 5 7600

GPU: Any modern gpu stronger than the minimum requirements with >4gb vram

RAM: 16gb

ROG ALLY Z1 EXTREME

XBOX ALLY X Z2 EXTREME

LEGION GO Z1 EXTREME

• any 7840u cpu

  Download my fork here -> https://github.com/junminlee2004/GR2fork
  Watch my fork in action here -> https://www.youtube.com/watch?v=8aHVM7qea6g&t=5s&pp=0gcJCdQKAYcqIYzv
  Buy me a kofi here -> https://ko-fi.com/junminlee2004

Source: https://old.reddit.com/r/emulation/comments/1sxehyl/shadps4_gr2fork_v10_for_windows_and_linux_pcs/

Also this issue: RetroAchievements come to the MiSTer, and a PS1 cross between Zelda and Tomb Raider gets a translation.

https://zsnes.com/ "It just happened. During tonight’s livestream, I was joined by the original creator of ZSNES to officially announce something no one expected…Super ZSNES."

I don't think it's been mentioned anywhere but _Demo_ was the other developer besides zsKnight.

A new "live platform" has launched which allows users to "host, stream, and share real-time Commodore 64 sessions with friends and spectators online."

Anyone who had an N64 will have a soft spot for Pilotwings 64. I can remember looking at the box for my console (which I put back in the box every time after using it for the first couple of weeks and kept out by the TV like a trophy), and seeing the images for Pilotwings 64 on the box. It was an amazing launch title and showed us all just what the N64 could do, bringing us into the 3D era alongside Super Mario 64.

"I call it the GB Bridge" - An in-development emulator has been revealed which "ports" existing Game Boy games to the GBA, taking advantage of the additional...

I unblocked X for a minute to get the media files so you don't have to:

Plus: Catching up with a spring blossom's worth of recompilation progress in just the last 2 weeks.

Preview:

When I see the words "The 3DO Company," my mind goes to a very specific place: Battletanx. The arcadey masterpiece that was 1999 sequel Global Assault probably spent more hours slotted into my teen years N64 than any game this side of Goldeneye or Mario Kart, thanks to a genuinely inventive array of asymmetrical multiplayer modes, tank archetypes and impressive-for-the-time destruction.

The second place my mind goes is Army Men: Sarge's Heroes, the shittiest videogame I've played in my entire life (and my best friend in first grade owned E.T.).

So, y'know. Win some, lose some.

I have no personal affinity with the 3DO itself, an oddball console that the company launched in the early '90s, but by all accounts it falls into the "lose some" category. It only lasted a few years before The 3DO Company shifted to just developing and publishing games for the Nintendo 64, PlayStation and PC. Despite shutting down in 2003 (should've made more Battletanx and fewer Army Men), the company legacy does live on today in a few forms. 3DO originally published pioneering online 3D MMO Meridian 59, which I wrote about last year on PC Gamer because it's one of the oldest videogames in existence still being updated today. It came out in 1996!!

Also, more relevant to this newsletter: the 3DO console now has a MiSTer core. Somebody get Trip Hawkins a MiSTer Pi, stat.

Inside the foam-insulated briefcase were hundreds of screws and the wiring to make the improvised explosive device explode, RCMP in Sherwood Park said.

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.

I came across a post from Pixel Cherry Ninja on X of a new flashcart made by David Brito, who has turned this thought into a reality. David has a big history of modding retro consoles, having adapted N64s to be powered by USB-C, working with HDMI mods, and creating better controller solutions. He even made a built-in display for the Xbox 360 which is incredibly cool!

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!

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!

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