You would think doing this month after month we would eventually run out of things to work on, but in true emulator fashion the work never ends. Let’s jump in to what has changed for the release this month!

A fast linux usermode x86 and x86-64 emulator
FEX allows you to run x86 applications on ARM64 Linux devices, similar to qemu-user and box64. It offers broad compatibility with both 32-bit and 64-bit binaries, and it can be used alongside Wine/Proton to play Windows games.
It supports forwarding API calls to host system libraries like OpenGL or Vulkan to reduce emulation overhead. An experimental code cache helps minimize in-game stuttering as much as possible. Furthermore, a per-app configuration system allows tweaking performance per game, e.g. by skipping costly memory model emulation. We also provide a user-friendly FEXConfig GUI to explore and change these settings.
On the technical side, FEX features an advanced binary recompiler that supports all modern extensions of the x86(-64) instruction set, including AVX/AVX2. The heart of this recompiler is a custom IR that allows us to generate more optimized code than a traditional splatter JIT. A comprehensive system call translation layer takes care of differences between the emulated and host operating systems and implements even niche features like seccomp. A modular core enables FEX to be used as a WoW64/ARM64EC backend in Wine.
Try it outYou would think doing this month after month we would eventually run out of things to work on, but in true emulator fashion the work never ends. Let’s jump in to what has changed for the release this month!
We’re just gonna kick out this little release and be on our way. There might be some interesting things this month, read and find out!
After last month’s enormous improvements, this release will look quite tame in comparison. Although we still did a bunch of work, so let’s dive in.
> FEX allows you to run x86 applications on ARM64 Linux devices, similar to qemu-user and box64. It offers broad compatibility with both 32-bit and 64-bit binaries, and it can be used alongside Wine/Proton to play Windows games.
> It supports forwarding API calls to host system libraries like OpenGL or Vulkan to reduce emulation overhead. An experimental code cache helps minimize in-game stuttering as much as possible. Furthermore, a per-app configuration system allows tweaking performance per game, e.g. by skipping costly memory model emulation. We also provide a user-friendly FEXConfig GUI to explore and change these settings.
> On the technical side, FEX features an advanced binary recompiler that supports all modern extensions of the x86(-64) instruction set, including AVX/AVX2. The heart of this recompiler is a custom IR that allows us to generate more optimized code than a traditional splatter JIT. A comprehensive system call translation layer takes care of differences between the emulated and host operating systems and implements even niche features like seccomp. A modular core enables FEX to be used as a WoW64/ARM64EC backend in Wine.
Used by the new Steam Frame (https://store.steampowered.com/sale/steamframe) which is an ARM64 Snapdragon 8 Gen 3 that will run PC and PCVR gaming titles.
CodeWeavers' Crossover just released a Preview version for Arm that incorporates Fex and allows games like Cyberpunk 2077 to run: https://www.codeweavers.com/blog/mjohnson/2025/11/6/twist-ou...
I've tested it on an Ampere workstation, and was trying it on a Pi, but it seems with Trixie, there may be some bugs with both that and box64 right now, I was having trouble with both of them.
Hey, it's that YouTube guy with cursed Raspberry Pi setups!
What motivates CodeWeavers specifically to work on this?
They make CrossOver, which is a productized version of Wine that lets you run Windows software on MacOS. They also work closely with Valve, who have just announced Steam Frame (a device that runs SteamOS on ARM).
It is quite likely that Valve is paying for this work. It benefits the Steam Frame.
> The main corporate sponsor of Wine is CodeWeavers, which employs Julliard and many other Wine developers to work on Wine and on CrossOver, CodeWeavers' supported version of Wine.
Not just used by, Valve is sponsoring FEX.
https://news.ycombinator.com/item?id=45903610#:~:text=Valve%...
I wouldn't call this random comment reliable testimony that they are sponsoring FEX.
https://gamersnexus.net/pc-builds-news/valve-steam-machine-d... "Valve has devoted significant resources to the development of FEX emulation."
As the random commenter I agree. By "support" I meant that they have a line of product and a strategy that relies on FEX to work and work as seamlessly as possible.
If they contribute to FEX at even a fraction of what they did to wine and Proton it is indeed huge.
Man, Fex is Valve, Valve is Fex! The steam logo is right there in the logo!
https://files.mastodon.social/accounts/headers/110/652/595/6...
Center of left side, it is a Valve product. All main devs are employed by Valve.
A binary recompiler for running x86 on a different architecture? Where have I heard this story before?
The example that most people think of these days is Rosetta. But I also always think of FX32 as I think it was the first.
The Alpha was such a great platform. It is too bad it’s reign was so brief.
Does that mean I can run windows games on my rpi? (In theory at least)
Yes (just possibly at ~2 fps)
Into the Breach is back on the menu.
There's probably a mountain of x86 games that would not need to hit above 15-30fps to be fun.
Into the Breach can even run on a Pi 4: https://youtu.be/jF6xGlmKVUQ
Put a GPU on it, and you can get 30+ fps in some newer(ish) games, 60+ fps in older games.
It would be cool if we can use LLVM to lift the x86 code into LLVM bitcode and go to different platforms easily with ostate of the art optimizations, won't it?
Been there, done that during my PhD (code: [1]). Works reasonably well, except for compile times (for which I implemented a caching strategy). However, due to calling conventions, using LLVM isn't going to give the best possible performance. Some features like signal handling are extremely hard to implement with LLVM (I didn't, therefore). Although the overall performance results have been good, it's not an approach that I could strongly recommend.
Sadly compile times of LLVM-based recompilers make it impractical for competitive x86 emulation. We're not just talking a few single-frame stutters here and there, but considerable startup delays and pauses in-game.
LLVM's optimization passes also are less useful than you might think, since the vast majority of them is motivated by source->binary translation (like clang). They don't have much effect when recompiling an already optimized binary to another architecture.
I'n incredibly impressed by valve's commitment to playing the long game. It makes sense to have the frame by arm since the system is lighter and its clear this is just the trojan horse to get arm linux into every gamer's house. I wouldn't be surprised if we end up with an arm steamdeck 1-2 version from now when the tech is ready.
Too bad Arm doesn't allow architectural licenses, because this is exactly the kind of thing Valve and the FEX developers would want to extend the ISA to support. I bet we see a RISC-V backend to FEX in the next 6 months, it probably already exists in a private repo.
FEX is the shootstring, extra special discount budget (not maligning) version of Rosetta. Apple should sell Rosetta to Valve.
My understanding is that Rosetta sidesteps a bunch of tricky memory model issues by using non-standard hardware extensions only present in Apple Silicon, so even if Apple did share Rosetta, which they certainly won't, it wouldn't work properly on Valves hardware anyway.
It's not only present in Apple Silicon, it's just not required by the ARM standard. Fujitsu also has an ARM64 CPU with TSO.
Nice article on this topic: https://lwn.net/Articles/970907/
There are also RISC-V designs with TSO. If you are targeting x86 workloads, it makes sense to have a per thread TSO mode.
https://dougallj.wordpress.com/2022/11/09/why-is-rosetta-2-f...
> Apple M1 has an undocumented extension that, when enabled, ensures instructions like ADDS, SUBS and CMP compute PF and AF and store them as bits 26 and 27 of NZCV respectively, providing accurate emulation with no performance penalty.
Oh yeah, maybe that one was too obscure for me. I don't think I've ever seen something use PF/AF…
You do want FEAT_AFP though, so you do want ARMv8.6+.
SETP is used rarely to compute parity, though it doesn't really save anything if you can use POPCNT. PF is also used by floating point comparisons with a different meaning though that is not useful for the Arm extension from Apple.
AF indeed is basically unused. The problem for both is that you need them for accurate emulation "just in case".
You can eliminate flag generation almost all the time with a little optimization (slash deoptimizing if you hit an unexpected use) but it certainly is less convenient to have to implement an optimizer.
Perhaps another interesting aspect of this is that it’ll be Apple with their vertical stack that will decide when to physically remove this logic from the chips.
macOS 26 is the last OS with an Intel build. Presumably this means that in all likelihood, M6 chips will remove this functionality.
Why do you assume that dropping support for Intel hardware from the OS will coincide with dropping hardware features that help support for x86 applications? Have you not seen Apple's documentation that states they plan to retain some Rosetta functionality beyond macOS 27 for the sake of x86 games?
I am not sure I consider it that likely.
First, these features are a big draw for developers (a key macOS audience).
Second, the ability to run Windows games is not getting less valuable.
yeah that is correct. The m series chips can turn on total store ordering memory model solely for Rosetta. There's also some hardware extensions to arm to support x86 condition codes in the hardware because it's way more instruction efficient that way.
The latter is now an optional feature in the mainstream Arm ISA now (FEAT_FlagM and FEAT_FlagM2). Similarly the “alternate floating point mode” that Apple uses to match nuances of x86 FP semantics is a standard architectural feature as well. The TSO option though is Apples own thing.
If you mean FEAT_FlagM, that's standard in ARMv8.4. (There's also FlagM2 and AFP that are optional.)
The JavaScript instruction is cooler though.
https://developer.arm.com/documentation/dui0801/g/A64-Floati...
RISC is dead; long live RISC
Box64 already runs on RISC-V. Just, the available processors are so slow it's hard to even play 5-10 year old games.
This means that, when the much faster chips implementing RVA23 arrive next year, they'll be immediately able to run Box64.
ARM already has most stuff required for this on board. Two proprietary extensions are used by Rosetta: one emulates the parity (rarely used) and half-carry (obsolete) flags, which can also be emulated conventionally. The other implementa TSO memory ordering, which can either be ignored or implemented with explicit barriers; some other chips apparently have a similar setting.
The other stuff is all present in ARMv8.5 I think.
You are looking for Felix86
> Too bad Arm doesn't allow architectural licenses
QEMU exists. I doubt they want the bad press of suing an Open Source project everyone is using.
ARM were perfectly fine getting the bad press for suing Qualcomm for releasing the Snapdragon that was finally performing enough despite these companies paying them a lot of money.
They seemed quite happy to destroy their eco system if they won.
https://www.rcrwireless.com/20251001/business/qualcomm-arm-2
And GBA emulators. And before that, BBC Accorn ones with Risc OS.
better yet, Apple should make it open-source on github.
> Apple should sell Rosetta to Valve.
Isn't Rosetta kinda bad though? And won't get much better because it's not open source?
Rosetta performance is best in class to my knowledge, although they had the benefit of being able to add custom instructions and modes to the cpu to make some parts easier. Meaning Rosetta would not have helped valve unless they built the frame on apple silicon.
As for not improving, it is likely that Apple no longer feels the need to invest in Rosetta improvements now that Apple silicon is so dominant and software support is already very strong, but nothing is stopping them from investing in it if they need it for example for gaming
Rosetta is abandonware: https://developer.apple.com/documentation/apple-silicon/abou...
Why would a company on its way to the moon, entrust such an important project as translation layer between two major architectures to a single rinky-dinky corp that got rich selling common electronics marketed as luxury fluff, that's on the decline and has head so far stuck up its butt that it thinks it can do whatever it wants, instead of just write it themselves with support of the global developer community?
Apple could never do games because there are no luxury games. That's completely out of their zone of comprehensibility.
I don’t know if the two companies have such different futures.
The games industry as a whole is in potentially terminal decline, have you seen all of the redundancies lately?
The AAA games industry with their multi-million budgets and "being too big to fail" mentality is on decline. It seems that anything that is not a new Call of Duty is considered not worth by the industry.
But smaller games and indie studios are thriving. We got lots of very interesting indie games this year.
Games take years to make, as a consumer you’re seeing results from the past. Most indie studios are doing poorly, I know several that have closed and many friends looking for work.
Last I heard, they don't even have bosses there, a flat hierarchy. They vote on things and pick each other to work on teams and appraise performance. Perhaps that radical culture has merit to it?
How much did Gabe own Valve, 50%?
Gabe Ownership/co-founder:
- Valve - Yacht Companies - Starfish Neuroscience (Neuralink) - Submarine Companies
I've heard that to ship hl2 (or anything really) they had to stip some of that flatness somewhat.
Anything works when you have infinite money and the company is privately owned by a chill dude.
Helps that they are in dominant position and basically just need to not fuck up
It’s amazing what you can do when you have a business that prints money hand over first and you have no obligations to shareholders.
I would appreciate more if they also would take devs into SteamOS water, instead of relying on Microsoft kindness.
I tried out FEX on a modern ARM board with a discrete GPU. Really impressed with the performance.
https://interfacinglinux.com/2025/06/30/fex-emu-gaming-on-th...
FEX is a CPU JIT, so your GPU settings are irrelevant to it, it is translated but not by FEX, and there is no real perf hit for the GPU
The old games don't really matter with regards to FEX perf, so the only relevant bit is the semi newer games at 30/40 fps, which seems very slow to me, given that you are only running at 1080p/Medium, so you likely have a CPU bottleneck there.
I would keep in mind that the results reported there are likely quite a bit lower (in terms of CPU-side performance) than what you could achieve in practice, because it's running all of x86 Steam+Proton in the emulator. In a pre-configured environment (like SteamOS for ARM), the Steam client and Proton itself would be native ARM code, and emulation would stop at the win32 API boundary (or at certain critical libraries' APIs if you're using Linux apps).
Fancy seeing the Plagman here. Last time I saw you was on Freenode (R.I.P.). So you are still working for Valve? ;-)