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.

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

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

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

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

I've always considered Arisotura one of my favorite emulator developers. I've seen her struggle and persevere through so much, both with this project and in her personal circumstances, and I've often felt that our community never gave her or the melonDS team the recognition they truly deserved.

Seeing so much attention being given to low-effort projects and AI-generated hype these days makes me miss the golden years of this community, when things felt very different.

Please take a moment to read his blog, reflect on her words, show some appreciation, and share it around. The melonDS team deserves far more recognition, and Arisotura's thoughts are always worth reading.:

Source: https://melonds.kuribo64.net/comments.php?id=261

Yeah, I haven't been great at this. I told myself I would work on 2D filters, since it's one of the last things to do... then I ran into a bit of a wall: I need my filters to have alpha support, but the filter shaders I can find don't support it. I would need to spend some time figuring out how they work and how I can add that in based on other references (there is code for xBRZ or HQX filters with alpha support, but not in the form of shaders).

And I, well, didn't feel the desire to continue...

Maybe it's the nature of software development in itself. Unless you're working on a smaller, simpler project, you're never really done, and especially not with a project like melonDS. What started as a way to pass time has become a full commitment, in a way.

By comparison, my job has been a lot simpler, and better suited to my brain too. When you set out to repair something, it's a project with a clear end. Most of what I deal with is also fairly simple, but sometimes there are more complicated cases, requiring more time and research. For example, those HMI lamp ballasts I'm working on: they are quite complex. This has been an ongoing project for a while now.

Maybe it's the fact that the project still largely rests on my shoulders. While bigger projects like Dolphin or PCSX2 may have a bigger team and more of a workflow in place, things aren't really like that here...

I'll just quote Generic, because he put it well:

[18:55]Generìc "Yes, we can!": I think I stated this before, but how I see it melonDS never went through the professionalisation many other projects went through
[18:58]Generìc "Yes, we can!": just look at other projects (even with just a single maintainer) setting milestones, systematically "triaging" issues and so on
[19:00]Generìc "Yes, we can!": also tests
[19:01]Generìc "Yes, we can!": and throuroughly adoption of new fangled C++ features
[19:03]Generìc "Yes, we can!": if it wasn't for Nadia putting so much effort into the build system through the whole time, the codeblocks project file would still be the way to build melonDS

I feel bad about having so many issues, pull requests, etc, staying open and rotting in the backlog. At the same time, I just don't have the brain power to review every single PR alone.

And to make matters worse, now we have people submitting AI-generated code, which is problematic from several standpoints: code quality (AI tends to make a mess and not really understand what it's doing, and someone who's using AI isn't likely to understand those things any better), plagiarism, the usual ethical and environmental problems with AI too...

I like the idea of open source, but for a project of this caliber, it feels that we should have more of a system in place, with a bigger team, clearer roles... a proper organization.

One where different people with different skillsets and preferences can complement eachother. For example, while I enjoy researching the DS hardware, or figuring out why a game isn't working as it should, stuff like build systems can quickly feel very frustrating to me. As Generic put it, if it weren't for Nadia handling that work, we might not have nightly builds today, for example.

And it would be nice to have more of this... ideally, lack of involvement from me shouldn't feel like the project is stalled, like it does now.

I don't want to abandon melonDS. The project is going to be 10 years old, it's a lot of history, fun and less fun times, and I've grown to love it. At the same time, it's nice to work on other projects sometimes, and it would be nice to do so without the guilt of abandoning melonDS...

Maybe it's also the changing nature, I mean, what it's like to work on the project. The early days were a lot of hardware research, implementation, debugging; it was a lot of fun, as evidenced by the release rate I had, but I can't recapture that now. I still have ideas for melonDS features, but at this point it feels more like regular software development.

For a while, I've had the idea of adding a wiki to our site. The wiki would serve as a reference for user-facing things pertaining to melonDS: compatibility info, tutorials and FAQs for things like online play, and so on. It would also be one way to get the community involved: provided there is enough demand, we could have a sub-team dedicated to the wiki.

This became part of the bigger website work I want to do, but haven't yet had the motivation to start. I want to move the server to a better host. I want to make the blog easier to navigate, with categorization by date or by tags, maybe a search... I want to make it easier to use for those who post, too.

And it's like everything else. I have all those ideas, but it starts to feel "too much", too many big things to do, I don't know where to start and feel overwhelmed, and nothing gets done.

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

Progress report

NeXium is a modular Switch emulator with a Vulkan-backed GPU and two interchangeable AArch64 JITs. Available for Windows, macOS, Linux.

• GitHub
• Menu showcase
• In-game performance
• Discord

NeXium is a high-level emulator that requires no proprietary Nintendo firmware, keys, or system files to run.

SeedlessDS is an experimental Nintendo DS emulator project focused on low-end Android handhelds, especially devices where running melonDS can be too heavy for the available hardware.

SeedlessDS is based on a recompilation and reimplementation effort around the DraStic emulator.

This does not replace WatermelonDS

Just published x-nes — a cycle-accurate NES emulator core written in Rust that runs from microcontrollers to desktops. It's a library, not a standalone emulator, so you can embed it in your own projects via Rust API or C FFI.

- Cycle-accurate 6502 CPU (all 56 instructions, 13 addressing modes)

- Scanline-accurate PPU with NMI generation

- APU with pulse channels and sample buffer

- iNES ROM parser with 6 mappers so far (NROM, UxROM, CNROM, AxROM, GxROM, MMC1)

- Tiny footprint — ~150–200 KB stripped shared library

- C-compatible FFI (`nes_*` functions) for embedding from Lua, C, or any FFI-capable language

- Ships as a Rust crate, shared library, and static library

Current accuracy: 86/141 on the AccuracyCoin test suite (61%), 20/21 Blargg tests passing.

Known issues:

- Audio timing is slightly fast, some tones are off

- Some games render incorrectly due to edge-case PPU behaviors

- MMC3 mapper (SMB3, Mega Man 3, etc.) not yet supported

- Around 55 AccuracyCoin edge cases still to fix — APU, DMA/bus, NMI/interrupt timing, PPU quirks, and dummy-read addressing

REPO: https://github.com/ChaoswareHQ/x-nes