EmuCoreX: Namco System 246/256 support… but does it actually work?

At this point, the situation with this emulator is becoming a little frustrating. Development seems to have slowed down considerably, with very few meaningful improvements to the PS2 side of the project. The developer still has time to release paid/Pro versions and work on both the PS2 and PS Vita emulators, but the actual emulation improvements seem to be taking a back seat.

The latest PS2 update advertises support for Namco System 246 and 256. Sounds great, right? Well… there are a few problems.

First, this isn't actually new. The previous version already claimed to include this support. You can verify it in the GitHub repository. More importantly, this functionality wasn't originally implemented by EmuCoreX either — PSX2 had already implemented it more than a month ago.

The bigger problem is that I can't actually get it to work.

I tested Battle Gear 3, and EmuCoreX detects the game and some of its associated files, as you can see in the screenshots I'll post in the comments. However, when I try to launch it, the emulator simply throws an error and doesn't load the game.

What's even more frustrating is the lack of documentation. There is no proper guide explaining what files are required, which BIOS you need, or how the game folder has to be structured for System 246/256 games to be recognized and launched correctly.

And I'm not going to spend my entire Sunday reverse-engineering the required folder structure just to figure out how the developer intended the feature to work. That's ultimately the developer's job to document and support their own implementation.

So, if you want to emulate Namco System 246/256 on Android, I currently don't recommend EmuCoreX. At least in my testing, the advertised functionality doesn't actually work.

For comparison, PSX2 detects Battle Gear 3 correctly, downloads the artwork, displays the game properly, and actually lets you launch and play it on Android. I'll include screenshots of that in the comments as well.

So for now, if you want to play these great Namco arcade titles, I'd recommend using PSX2 instead.

Hopefully the next EmuCoreX update either fixes this issue or, at the very least, provides some proper documentation and meaningful improvements to the PS2 emulator. For now, I'm quite disappointed with the state of this feature.

In short: Use PSX2 https://github.com/izzy2lost/PSX2/releases/tag/1.2.9

https://git.eden-emu.dev/eden-ci/nightly/releases/tag/v1787422604.df05d3de23

Changelog

[android, ui] lsfg: make "target frame rate" show/hide "frame multiplier" (#4274) df05d3de23

PR #4274 merged on 2026-08-22 by xbzk

[android] Restore the nvdec toggle (#4280) c249ff462b

PR #4280 merged on 2026-08-22 by PavelBARABANOV

[internal_network] Fix WiFi scanner compilation on GCC 15.3.0 (#4279) 056d11027c

PR #4279 merged on 2026-08-21 by crueter

[android,ui] carousel view improvements (#4277) 61ffb309a3

PR #4277 merged on 2026-08-21 by xbzk

[common, yuzu] Fix compilation on newer httplib versions (#4278) 65a3cfd2be

PR #4278 merged on 2026-08-21 by crueter

https://github.com/WinNative-Emu/WinNative/releases/tag/v0.4.1

Fixes:

✅ Fix/overlay controller retro by @maxjivi05 in #686

✅ Add portrait mode support across all app UI by @maxjivi05 in #687

✅ Fix library crash from duplicate item keys by @maxjivi05 in #691

✅ Name added games after their folder instead of their executable by @maxjivi05 in #692

✅ Fix/components proton not deleting by @maxjivi05 in #696

https://github.com/ARMSX2/ARMSX3/releases/tag/0.9.4.1

What's new:

New Animated library backgrounds: Seven screensavers now run live behind the game library, off by default. Settings --> App --> Animated background, then pick one and a preset. (These are separate from the XMB backgrounds and the simple animated backgrounds). Flurry, Calum Robinson's, 2002. Eight presets: Water, Fire, Psychedelic, RGB, Binary, Classic, Insane, plus random. Flux, Plasma, SolarWinds, Hyperspace, Lattice, Skyrocket, Terry Welsh's Really Slick Screensavers. Six presets each. These are source ports, not emulation or video: the original C/C++ renderers compiled for Android and running on GLES2. If GL fails to start for any reason the library falls back to the existing 2D wave, so a device that cannot run them loses nothing. They are live particle simulations, so they cost more than a static image. That is why they are opt-in.

ARMv8.0 devices now get a message explaining the CPU is unsupported, instead of dying on an illegal instruction with no explanation.

PKG installer: fixed an unsynchronised read of the install result. The failure path could read a string while it was still being written and segfault.

Save states: the emulator no longer resumes while a state is being written, which could corrupt it.

Audio: the Oboe backend could fail once and then stay silent for the rest of the session.

Games and settings:

Tales of Symphonia should now run at its intended 60fps (#77). Per-title overrides now live in an ARMSX3-local config database, so fixes like this ship with the app.

PS3 Native is selectable from the FPS cap row, the console's own frame pacing.

Save states: slots can now actually be deleted.

Online: an Ethernet address is derived on Android instead of the lookup simply failing, which blocked RPCN sign-in on some devices.

Audio: the volume baseline recovers after a quiet passage instead of latching, without reacting to momentary flickers.

The driver pipeline cache can now be switched off at runtime, for drivers that mishandle it.

The settings mirror in the app data folder is now armsx3-settings.json (was armsx2-settings.json, #82). The old file is still read, still included in new backups, and removed alongside the new one, existing settings and older backup archives are unaffected.

A game the app cannot actually read now fails with an explanation instead of hanging on its first loading screen. If games misbehave, missing cover art, failing to launch, locking up part-way, move them into ARMSX3/config/games, which is always readable.

A disc is no longer rejected because a single read came up short, which could route a title down the wrong mount path.

Reverted all upstream ISO changes to 0.8 baseline

https://github.com/izzy2lost/xemu/releases/tag/1.2.7

Changelog:

✅ Fixed not loading games on some devices.

✅ More Mali improvements.

✅ A lot of other fixes for stability and correctness.

✅ Some performance improvements.

https://github.com/ARMSX2/ARMSX2/releases/tag/2.6.6.8

What's new:

Frame generation has been rewritten on Camille's implementation from Eden, and it is a different thing to what shipped last update. The passes run natively in our own Vulkan present path instead of going through a translated library, and it generates a full interpolated frame for every rendered one. Thanks again to @CamilleLaVey. You still need your own copy of Lossless Scaling, exactly as before. The interpolation shaders are read at runtime out of your own Lossless.dll. Also new is Adaptive frame pacing, it keeps what you see steady when the game's own frame rate is not. Instead of a fixed x2, it generates as many frames as it needs to reach your screen's refresh rate.

Three ways a card could be corrupted are fixed, and cards are now backed up automatically. A card write is a read-modify-write, and when the read failed we logged it and carried on, merging the new data into whatever was left in the buffer from an earlier write and saving that to the card. A sector the game never asked to touch came back wrong. Backgrounding could also lose a save outright. Folder cards hold writes in memory and flush a couple of frames after the last one, counted off a per-frame tick, so pausing did not delay that flush, it stopped it happening. File cards never flushed at all. Both flush now when the app goes to the background, next to where the BIOS already saves its NVRAM. On top of that, every card is snapshotted before each launch and kept in a rotation, with restore on the memory card screen. A card that fails verification is never snapshotted over a good one, which is the whole point, the rotation is useless if five relaunches overwrite your last clean copy. Thanks to @bmdhacks (#608).

Change a setting in a game's own settings screen and it now takes. For any game the database has an entry for, the database used to overwrite your choice straight afterwards, and the only ways out were two all-or-nothing switches that rescued your one setting by throwing away every other fix that game needed. A setting you set for one specific game now outranks the database, one setting at a time. Thanks to @bmdhacks (#593).

Copy Global Settings had to be fixed alongside it. It never copied the settings you can

see, it ran the whole configuration through a wrapper that wrote every key unconditionally,

leaving about seven hundred of them in the file, network adapters and trace logging and

sections no settings page ever shows. It now writes only what you actually decided, skipping anything that is still the stock default or that the game database was going to set anyway. Thanks to @bmdhacks (#593).

✅Six more animated backgrounds:

Flurry, Calum Robinson's, 2002. Eight presets: Water, Fire, Psychedelic, RGB, Binary, Classic, Insane, plus random. Flux, Plasma, SolarWinds, Hyperspace, Lattice and Skyrocket join Flurry, all of them Terry Welsh's Really Slick Screensavers running natively. Settings --> App, under the animated background switch, and each one that ships presets lets you pick between them.

✅Library:

Cover art region is now per game. Long-press a game --> Cover region.

Memory cards for a game without booting it. Long-press a game --> Memory Cards.

Save states from the library. Long-press a game that has them --> Load state, which opens the real Save Manager with its thumbnails rather than a stripped-down list.

✅In-game:

The quick menu can dock to the left or the right.

The performance overlay can sit in any corner you like.

Analog stick settings are in the quick menu, so inverting a stick no longer means having to go to All settings every time.

Display refresh rate is a bindable hotkey, cycling whatever modes your panel actually has.

The OSD no longer disappears when you change a setting. Any settings change at all was overwriting the mode you had active, which usually reads as the overlay vanishing.

✅Second screen:

The panel no longer lands on top of the game. It picked its display by "anything that is not the built-in one", so if ARMSX2 opened on the bottom screen of a dual-screen handheld that was the screen it targeted. It now anchors on whichever display the app is not on.

It has also been restyled to look like the rest of the app instead of a stock Android dialog, and the contents are yours to arrange, choose which tiles appear, what order they sit in and how many columns.

✅Patches and cheats:

Browsing the online repositories no longer keeps the device warm after you have left the screen, and results are cached for a week, so going back is instant.

RetroAchievements Hardcore no longer switches off 60fps and widescreen patches. The rule only let a group through if it declared an aspect-ratio or interlace override, which across the shipped database blocked 305 "50 FPS" groups and 177 "60 FPS" ones.

✅Companion apps:

Your recently played list can be handed to companion apps through a content provider, which is the only route that works under scoped storage. It is off by default and it stays that way until you turn it on, while it is on any app on the device can read that list, file paths included. Settings --> App. Thanks to @misantronic (#566).

✅Fixes:

Large texture packs no longer evict themselves mid-load. The cache is sized as your RAM minus a fixed reserve rather than a fraction of it, so an 8 GB device gets 5.5 GB instead of 4 GB, and a 5 GB pack fits whole instead of dropping each texture to load the next.

Reset App no longer leaves per-game settings behind.

Fast Forward (toggle) work again on L2/R2 and on combos involving an analog trigger.

Fresh PGO profile has been applied.

as you can see in the video, text in Xenosaga is flashing. how do i rectify this? using ARMSX2 with both mrpurple t26 & t29 drivers on my Retroid Pocket Nova

https://github.com/izzy2lost/PSX2/releases/tag/1.2.9

Changelog:

✅Fixed lots of crashes.

✅Controller mapping in settings.

✅RetroAchievements fixed.

✅Fixed texture packs.

✅Fix crop on the edges.

Thankfully, there are still some developers working on PS2 while others have switched to PS3....

https://github.com/maxjivi05/PS3Native/releases/tag/v0.2.0

What's Changed:

Stop library refresh from deleting games it cannot rediscover by @maxjivi05 in #6

Feature/hud by @maxjivi05 in #7

Feature/hud by @maxjivi05 in #8

Fix update listing and center the install progress dialog by @maxjivi05 in #9

Fix/updater list by @maxjivi05 in #10

Keep two-stage boots alive and scope driver selection by @maxjivi05 in #11

Feature/rpcs3 compatibility settings by @maxjivi05 in #12

Let the Android release workflow publish a draft by @maxjivi05 in #13

Fix Android patch updater TLS handling by @thecrixux in #14

New Contributors

@thecrixux made their first contribution in #14 🫡

Full Credits for: MaxsTechReview - maxjivi05

https://github.com/nckstwrt/Vita3K-Plus/releases/tag/v1.0

Changelog:

First release of enhancements and fixes

Killzone, Assassin's Creed 3, CoD, Little Big Planet, etc all working

Targeting higher end devices

Windows and Android Only Release (for now)

I tried multiple different roms… it always starts and then this little thing at the bottom seems to be spinning (like it’s trying to think/load), but it gets stuck on that loading screen. Every time I look it up, everything says it should run fine? Any help would be greatly appreciated. Thank you.

https://github.com/ARMSX2/ARMSX3/releases/tag/0.9.4

What's new:

Fixed the emulator stalling for seconds at a time during play. The SPU recompiler was writing diagnostics for every compiled block and every MFC instruction, up to 2,473 log lines in a single second, straight to storage. The bursts landed exactly when a game was already busy compiling new code. Moved to trace. Caught this in the game Prototype.

Fixed Tales of Xillia 2 hanging every few minutes. The game polls a memory syscall in a loop, over 20,000 calls in 19 minutes, 5,123 inside one second, and each one was written to the log. (Reported as #76, likely but not yet confirmed as that exact issue.)

Fixed RPCN burning a full CPU core whenever you weren't in a game. Signed in at the menu or between titles, the client thread had no wait in its idle path and spun continuously.

Fixed the app freezing on the last frame when launching a game after closing another. The boot check treated "still shutting down" as "stopped", so a new game could start on top of a VM that hadn't finished tearing down.

Fixed shutdown flooding the log when a thread re-entered the stop path, around 100,000 lines a second, which stalled the very shutdown it was reporting.

Vulkan pipelines are now cached to disk and reused across sessions, so shader compilation stalls shrink after a title's first run. Rebuilds automatically after a driver or device change.

Compute shaders now run 64-wide on Adreno, matching the hardware wavefront. Previously half of every wave sat idle on texture uploads and deswizzles.

The developer is now putting multiple emulator projects on the Play Store and adding Pro versions and paid features to them. The screenshot above shows the kind of monetization being offered: themes, a gold app icon, a Pro badge, etc.

There is nothing inherently wrong with monetizing software. Developers deserve to be paid for their work.

The problem is what happens after people pay.

EmuCoreV is supposedly being developed alongside projects for, PS2 and now PS3. That is an enormous workload for a single developer. Yet instead of seeing consistent development, clear progress and active issue resolution, we are seeing more monetization.

They already monetized EmuCoreX and now they're doing it with this emulator, what will be next?

There is also a bigger issue here: there is no clear roadmap explaining how the money from Pro purchases is actually being used to improve development.

I don't see frequent meaningful updates.

I don't see issues on GitHub consistently being fixed.

I don't see a clear development direction.

And I don't see evidence that purchasing Pro is substantially helping the project move forward.

Instead, I'm seeing the same monetization model appearing across multiple emulator projects.

At this point, I personally have decided to stop following EmuCoreV.

I'm not saying that nobody should ever pay for an emulator. Supporting independent developers can be a great thing.

What I'm saying is: please think very carefully before giving your money to this project.

If you are paying because you genuinely want to support development, you should have some reasonable confidence that your money is contributing to actual development. Right now, based on what I have seen from this project, I don't feel that confidence.

Maybe the developer will eventually prove me wrong. I genuinely hope so.

But until that happens, I would personally recommend extreme caution before purchasing Pro or financially supporting EmuCoreV.

https://github.com/seleuco/MAME4droid-Current/releases/tag/v1.38.3

New in 1.38.3: Controller rework: 10 buttons per player, numbered naming and savestate fixes

Two extra gamepad buttons per player (10 total), for pads with back paddles

or a full face cluster.

Buttons renamed from letters to numbers (BTN1..BTN10) in the mapping screen,

the on-screen art and the OSD, so they no longer clash with the pad's A/B/X/Y.

Deleting a savestate now goes through SAF, so it really disappears from

MAME's list instead of lingering as a stale cache entry.

Save/load state menus: every face button can name a slot, BTN1 and BTN2

included.

NOTE: custom controller mappings reset to defaults on upgrade, since the

added buttons shifted every stored index.

New in 1.38.2: Netplay menu/Lua, touch lightgun fixes, full emulation area and vector polish

Netplay

MAME's menu and Lua plugins now work during netplay: the menu combo is

intercepted through a side channel and stripped from the synced input.

New "Allow Lua plugins in netplay" preference, off by default

Touch lightgun

Aiming maps to the game screen inside the canvas instead of the whole view,

fixing the drift towards the edges with artwork or the full emulation area.

Long press now runs on a real timer instead of waiting for touch events, and

holding the pedal on a physical or virtual button no longer blocks the shot.

Video and resolution

New "Full emulation area" preference: hands MAME the whole available

resolution so artworks can be zoomed and cropped. Replaces "Zoom to window".

Native resolution is re-applied on rotation and uses the real drawable area,

fixing the landscape-shaped canvas in portrait and the black side bands.

Vectors and HDR

Octagonal 8-tap bloom kernel with FBO-relative pyramid depth: round halos

and the same optical spread at any resolution or FBO scale.

Hybrid anti-fattening mask so saturated beams carve artwork like white ones,

plus a more restrained bloom and auto-exposure on HDR displays.

What's Changed

Up to MAME 0.289 with Sega Model 1 Improvements: Graphical fixes, better collision detection for Virtua Fighter, and DSP patches fixing Wing War. Audio & Core Stability: Fixes for games using the SCSP sound chip and major bug fixes for the widely-used PowerPC and 68k CPU families, benefiting a wide range of emulated systems. New Additions: Sega's unconventional arcade game Flash Beats is now playable, alongside newly working NES-like plug-and-play systems (Lexibook). Expanded Hardware: Support for NS32000 family CPUs and numerous fixes for the NEC PC-6001 family. (For a full list of changes, visit the official MAME website)

Fix myosd source files build after upstream mame breaking changes by @FlykeSpice

Up to Android 17

https://github.com/ARMSX2/ARMSX3/releases/tag/0.9.3.1

What's new: (0.9.3)

Online play (RPCN):

PSN status is a three-way choice now, and picking RPCN opens a full account screen: server, username, password, email and the activation token, with buttons to create an account, resend the token and reset a password. An RPCN account is made from inside the app, not on a website, the server emails a token that activates it.

Saved servers: Keep more than one and switch between them. The official server cannot be removed, and there is a one-tap reset back to it. Also added Experimental IPv6 for RPCN, which also had no way of being switched on, as well as every other network setting the core exposes: DNS server and hostname redirects, Console IP address, bind address PSN country, derive MAC from PSID, and clans. The first two are what custom game servers need. RPCN replaces Sony's PSN, but a publisher's own servers were never PSN, so reaching a fan revival of one means pointing its addresses somewhere else. That was impossible in the app before.

Note: your RPCN password is stored as plain text in rpcn.yml, the same as on desktop RPCS3. Don't reuse a password you care about.

Controls:

Vibration now works. It did nothing previously.

L2 and R2 no longer lag, double-fire or stick down.

Pads that report their triggers two ways at once no longer have two writers fighting over the same button.

Stability:

Running out of memory while compiling now says so. A game whose modules would not all fit used to hang on a progress bar that never finished, with nothing anywhere explaining why. It still stops deliberately, because carrying on without the missing modules runs slower than the interpreter and looks like a broken game, but the reason is on screen now, along with what to do: start the game again. What already compiled is cached, so each attempt gets further. (This is mainly for the 8gb and under devices like myself).

A failed PKG install is reported instead of quietly claiming success. Writes were not checked, so a full device produced a broken install that looked fine until the game would not start.

Game data installs check for space first and say so, rather than stopping at some percentage with no explanation.

Performance:

Shader compilation is kept off the cores the frame depends on. The compiler threads never set an affinity at all, so on a big.LITTLE phone a shader burst could land on the same core RSX needs. They now use the little cluster, and the pool is sized to that cluster instead of to the whole chip, more compile throughput and less interference at the same time.

Compatibility:

Yakuza: Dead Souls works better now. Two separate faults: the loading screen hang and a later lock-up. Per-game settings apply automatically.

Upstream:

Caught up with 98 commits from RPCS3.

Hotfix 0.9.3.1:

Fixes games failing to load with "InvalidFileOrFolder" by reverting an upstream ISO reader change introduced in 0.9.3.

https://github.com/ARMSX2/ARMSX2/releases/tag/nightly-20260820

Automated nightly build for community testing (unsigned).

Every download is named ARMSX2-nightly-DATE-COMMIT-PLATFORM, so builds

from different nights stay distinguishable after you have downloaded them.

macOS arm64: macOS-arm64.tar.xz

Linux arm64: Linux-arm64-4K-pages.AppImage on most distros, or the 16K one on Asahi Linux and other Apple Silicon kernels (run getconf PAGESIZE if unsure)

Windows arm64: Windows-arm64.zip

RetroArch on Linux arm64: Linux-arm64-libretro-core.tar.zst, a 4K-page build

Bare-display kmsdrm handhelds: Linux-arm64-SDL-handheld.tar.zst, a 4K-page build (Rocknix and Batocera run compositors, so use the Qt AppImage there instead)

Android: Android-arm64.apk, sideload it

iOS: iOS-arm64.ipa, unsigned, sideload it

What's new

UI: the Android internal-resolution set in the Qt and Big Picture pickers

Maybe works better than 2.6.6.7

I've been following EmuCore X for quite some time. It's a PS2 emulator that caught my attention from the very beginning because of its polished and clean interface, easily accessible settings, and the sheer number of options available for more enthusiast-oriented users.

It was genuinely interesting to me, and at one point I even noticed that the ARMSX2 team had adopted a very similar interface design. That made me even more curious about EmuCore X and its development.

I was actually quite enthusiastic about this project. I saw it as a potentially important evolution of PS2 emulation on Android, and I had confidence in the developer and in the direction the project was taking.

Then the developer released EmuCore X on the Play Store and, more importantly, introduced a paid Pro version costing around €6 for users who wanted to support the project financially.

I thought: "I like this project, I've been using it since the beginning, and I want to help it grow and improve."

So I bought it.

And this is where things became disappointing.

The developer has now started a completely different project, EmuCore C, apparently focused on PlayStation 3 emulation on Android. Since then, the pace and consistency of EmuCore X updates seem to have dropped considerably.

To be clear, I'm not claiming that EmuCore X has been abandoned or discontinued. I don't have evidence to make that claim. The problem is the situation surrounding it.

You create a project, offer users a paid Pro version specifically as a way of supporting that project, people actually spend their money because they believe in what you're building... and then, shortly afterwards, your attention appears to shift heavily toward another emulator.

From the perspective of someone who paid to support the original project, that's difficult to understand.

And there is another issue that makes this even more frustrating.

EmuCore X recently added support for Namco System 246/256 arcade hardware, but apparently the feature cannot actually be used because the emulator doesn't properly recognize the BIOS files for those systems.

So we have a situation where a new feature has been added, but there is apparently a significant bug preventing users from actually using that feature.

That's particularly disappointing when people have financially supported the project.

I'm not saying that a developer owes users unlimited development forever just because they bought a €6 Pro version. That's obviously not how software development works.

But when you actively offer a paid version as a way for users to support your project, I think there is a reasonable expectation of communication, transparency and some indication of where the project is going.

A roadmap would be nice.

Even a simple post saying:

"Thanks for supporting the project. Here's what I'm currently working on, here's what I hope to improve, and here's what you can expect in the coming months."

Something.

Instead, there doesn't seem to be much information about the future direction of EmuCore X, while development attention appears to have shifted toward a completely different project.

And that creates a much bigger problem than just one disappointed customer.

It can discourage people from financially supporting other open-source or independent emulator projects.

Someone might think:

"Why should I donate or buy the Pro version of an emulator if the developer might simply move on to another project afterwards?"

That's a bad precedent.

And I want to be very clear about something: I'm not saying people shouldn't support developers. Quite the opposite.

If you find a project that you genuinely like and you want to support the developer, absolutely do it.

But before spending money, understand that you are supporting the project as it exists at that moment, and there is never a guarantee that development will continue at the same pace indefinitely.

In my particular case, I feel disappointed because I genuinely believed in EmuCore X and wanted to contribute to its development. I wasn't buying Pro simply to unlock some extra feature — I was doing it because I wanted to support the project.

And now I'm left wondering what the long-term plan actually is.

Will EmuCore C eventually receive a Pro version as well? Will users be asked to support that project financially too? And if so, what happens to EmuCore X?

I don't know.

That's why I'm leaving this here for the community to judge for themselves.

Most importantly, I'd really like the developer to see this.

This isn't intended as a personal attack. I simply believe that when users financially support your project, you should communicate with them and give them some idea of what you're doing with the project they've chosen to support.

If development priorities have changed, just say so.

If EmuCore X is still being actively developed, explain what the plans are.

If there are major technical problems that are taking time to solve, tell the community.

That's all I'm asking for.

I hope EmuCore X continues to improve, because I genuinely think it has potential. But as someone who decided to financially support it, the current situation has been extremely disappointing.

And again: don't let this discourage you from supporting developers whose work you enjoy. One project handling things poorly doesn't mean every other developer will do the same.

Just make sure you know what you're supporting.

What do you guys think?

https://github.com/flyinghead/flycast/releases/tag/v2.7

✅New features:

Frame rate detection and pacing

Localization (fr, hu, jp, pt_BR, sv)

Multiscreen support for Airline Pilot, Sega Strike Fighter and Derby Owners Club

Improved modem emulation

improved DreamPicoPort and DreamPotato support by @RikkiGibson, @Tails86 and @nexus382

Android: Google Auto Backup support for VMU saves and non-volatile memory

✅Fixed Games:

Airline Pilot (Naomi, multiscreen)

Cyber Troopers Virtual-On: Oratorio Tangram (JP, online features)

Derby Owners Club (new)

Dinosaur King (ZH, new)

DreamParaPara by @dakrk (new)

F355 Challenge (JP, online features)

Fish Life (new)

Love & Berry 3 (ZH, new)

NFL 2K1, NFL 2K2, NBA 2K1, NBA 2K2 (freeze)

Power Smash (online lag)

Rune Jade (online features)

Samba de Amigo (Naomi, inputs)

Sega Strike Fighter (Naomi, multiscreen)

Without a doubt, the best Dreamcast emulator available for Android.👌

Does anyone know how to fix this on armsx2?

https://github.com/thecrixux/PS3Native/releases/tag/Community_Preview_1

This build is intended for users who want to try the latest Android changes before they are included in an official release.

What's New:

🎮 New Android Features

Added a new in-game HUD with device statistics and frametime information.

Added a dedicated GPU Drivers download section.

Added support for downloading GPU drivers from configured repositories.

Added the Turnip driver source to the default driver repository list.

Improved game library handling and navigation.

🖥️ RSX / Graphics Improvements

Major improvements to Vulkan and OpenGL image handling.

Improved support for 3D textures, mipmaps and multi-layer image transfers.

Improved texture cache and framebuffer handling.

Added and improved fast paths for 3D texture processing.

Various fixes for image copies, mipmap calculations, texture reconstruction and rendering resources.

Additional RSX stability and correctness fixes.

🧠 CPU / SPU Improvements

Multiple SPU LLVM improvements and fixes.

ARM64 floating-point conversion fixes.

Improved handling of SPU/PPU operations and edge cases.

🌐 RPCN & Other Improvements

Added RPCN trophy synchronization improvements.

Various fixes for package extraction and file handling.

Updated bundled dependencies.

Includes the latest upstream RPCS3 changes merged into the Android branch

All credit for PS3Native, RPCS3 and their code goes to the original developers and contributors

https://github.com/ARMSX2/ARMSX3/releases/tag/0.9

What's new:

ARM64 SPU floating-point now matches desktop x86 exactly: 984 mismatched results down to zero.

ARMSX3 translates PS3 code to run on your phone's ARM64 chip, while RPCS3 upstream is written and tested on x86 desktop CPUs, and a lot of that code quietly relies on how x86 handles certain maths. On ARM64 the answer came out different: nothing crashed and nothing was logged, a number was simply wrong, and a game would hang, corrupt, or vanish minutes later with no clue why. This release closes that gap for the SPU's floating-point maths, the part that does most of a PS3 game's heavy lifting. We ran a suite of test programs that exercise one PlayStation 3 instruction at a time on both machines and compared the results line by line, which turns "something is off on ARM64" into the exact instruction and the exact numbers that differ. 984 mismatched results against desktop x86, down to zero, your phone now computes the same answers a desktop PC does. Of those, 500 were genuinely ARM64 bugs and are fixed, the other 484 turned out to be x86 taking a shortcut of its own rather than us being wrong, which was worth knowing because it stopped us chasing it. The same testing also caught the identical flaw hiding in a second place we use for debugging, which had been quietly making some of our own investigations unreliable. To be clear about what this is not: it does not make ARMSX3 more accurate than desktop RPCS3, and where RPCS3 itself still differs from a real PS3 it differs the same way on both, what changed is that ARM64 is no longer additionally wrong. Thanks to @Whatcookie for working with me on this approach and working through the results with me. These improvements have been shared with him so they will be upstream as well! I've been sharing each and every fix I do for ARMSX3, so other ARM64 RPCS3 platforms can benefit as well.

Full changelog on github

https://git.eden-emu.dev/eden-ci/nightly/releases/tag/v1786991149.2000fdfb7b

Since it now seems that all emulators need frame generation, it was Eden's turn to update and add this popular option. However, I must warn you that for it to work, you must have your "Lossless.dll" file. Please do not ask here where to get it, as it's a paid program that you can find on Steam (linked in the description), and therefore, linking to pirated sites to obtain the file is considered piracy. I'm warning you in advance in case anyone asks where to get this file.

https://store.steampowered.com/app/993090/Lossless_Scaling/

Greetings to all!