M4 Pro: The Emulation Beast

KingOfPain

Site Champ
Joined
Nov 10, 2021
Posts
736
I'm still at the process of testing some emulators on my new Mac mini (M4 Pro with 64 GB RAM), but from my first impressions this machine is really capable in terms of emulation (I cannot judge the basic M4, but I'm guessing if an emulator doesn't utilise more than 4 performance cores it should probably have similar performance).

I'll have to perform more testing with some of the more demanding emulators, but there are a few I won't be covering, because they already were more or less perfect on the M1. Therefore, I'll skip all 8 bitters, 16 bitters, and most 32 bitters, and even some 64 bitters (since Dreamcast and Gamecube run fine on an M1 with Flycast and Dolphin, respectively).

An honourably mention goes to the N64 emulation of ares. This was still somewhat choppy on the M1, but seems to run very smoothly on the M4 Pro even with UHD render quality enabled.
Unfortunately, my Xbox One controller isn't recognised by ares, and the primitive SNES-like controller that is recognised lacks an analog stick, which makes testing quite hard.
All other systems emulated by ares shouldn't have any problems, but with its general very low-level approach the N64 emulation is quite demanding here.

When I compiled a list of interesting emulators over 4 years ago, before I switched to the M1 MacBook Air, I was really hoping of running Windows 9x on DOSBox-X or PCem to play a few older games, in particular Jedi Knight (aka Dark Forces II). But using 3DMark2000 as a test, the Voodoo emulation in both was so atrociously slow and had graphics errors that they wouldn't be able to run any real game. Also, the Mac port of PCem was only an alpha, which never got updated, and the original maintainer of the mainline source for PCem, Sarah Walker, dropped development and it has been somewhat dormant since then, despite having a new maintainer.
Back then I didn't have 86box (a fork of PCem) on my radar, because it was Windows-only. But in a matter of three or four months it had been ported to Linux, then macOS, then native Apple Silicon.
I'm not using it to run Windows games, though, as CrossOver, Whisky, or Parallels are better candidates for this task (I actually managed to get Jedi Knight running with dgVoodoo2 on Parallels, and now it's even easier with DREAMM). And for DOS game, DOSBox-Staging is much easier to handle than real DOS on a PC emulator.
What I use 86box for is a bit of nostalgia by booting BeOS, which I used before I switched to macOS on a PowerMac G5. I configured the PC that I was using back then to run BeOS:
ASUS P2B board with 350 MHz Pentium II and a Voodoo Banshee video card. I couldn't remember which sound card I had (only that it used a Yamaha chipset), thus I simply used a Soundblaster 16 PnP for compatibility reasons. (I eventually upgraded my real PC with a 550 MHz Pentium III and an ATI Radeon card, but 86box doesn't emulate Pentium III and vanilla BeOS has no Radeon drivers).
On the M1 this setup somewhat worked, but the startup sound after reaching the desktop was a bit choppy, and IIRC the demo videos didn't play smoothly.
On the M4 Pro the startup sound is the just the way it should be, and the videos (of monitors being tossed off a roof) play smoothly. Playing both at the same time is getting choppy, though. I cannot recall if the real hardware was able to handle two videos at the same time over 20 years ago. BTW, I set the desktop resolution so high that BeOS warned me it could damage the "monitor".
Also, while playing the included demo songs, the music gets slightly interrupted when opening the photos of the composers. I'm guessing this is a timing limitation of the emulator not a performance problem with the M4. BeOS is famous for having a very quick response time and 86box might not be as precise.
Since the M4 Pro didn't seem to have any issues performance-wise, I cranked the clock of the emulated Pentium II from 350 to 450 MHz, and the emulated machine is still at 100%.
For a joke, I just installed Windows 98SE, a Voodoo Banshee driver, and DirectX 8.1 to run 3DMark2000. I was surprised to see the demo mode running smoothly and as far as I can tell without any graphics errors. The CPU utilisation ranges from slightly above 200% to occasionally close to 300% while running the demo. I suspect 86box might be able to run less demanding games even on a basic M4, but I think I'd still prefer the other options mentioned above, unless the game demands an original Windows 9x.

I almost didn't test the Xbox emulator xemu, because someone mentioned in a Youtube video that it doesn't run playable, even on the M4 (I cannot remember if it was a Pro or not). That was also my impression after testing it on the M1.
It took me a while to get it running again, because it has been a few years since my last test and it seems xemu has switched from normal ISOs to XISOs, which requires some conversion.
Surprisingly, Halo 1 runs perfectly playable for me (I completed the first two levels without any issues). On the M1 it started out OK, but had huge frame rate drops during explosions or with multiple enemies, but not so on the M4 Pro.
I also suspect there might have been large improvements in the emulator itself, since Halo 2 had big texture issues. This has been improved a lot, but I still wouldn't count it as playable (subpar frame rate, the HUD doesn't seem to work, and still some texture issues).
Riddick also has many issues (the main menu is practically all black), and Oddworld: Stranger's Wrath has the problem of textures occasionally not showing up, which makes it hard to play.
I still have to test Fable and KOTOR...
But if you want to see Halo 1 again, I can definitely recommend it. I doubled the internal resolution to make it look better. For some reason the textures don't look as dated to me as in a lot of other games, but that might just be nostalgia. But the M4 Pro is definitely getting hot here (over 100°C).

That's it for now. If you are looking for a specific emulator, I can recommend the following site:
 
More solid information on xemu:
Halo 1 actually only runs at 15 to 22 FPS. I guess I'm more tolerant when it comes to frame rates when it comes to emulators. Most gamers would not consider this playable.
Fable and KOTOR run much smoother, though, at 30 FPS and 30 to 50 FPS, respectively. I haven't retested the other games, since those had graphics issues anyway.

While the Playstation 2 emulator PCSX2 has a Metal backend now, it's still not Apple Silicon native and therefore has to run through Rosetta 2.
There is a native emulator called AetherSX2, but it's less compatible, closed source, and has been abandoned for a while.
On the M1 PCSX2 wasn't quite smooth, but on the M4 it seems to run everything I throw it it at full speed with 3x native resolution selected (1080p). The CPU utilisation ranges from 60% to 130%, which might explain the slight performance issues on the M1.
If your CPU is fast enough, go for PCSX2 because of the better compatibility. If speed is an issue, use AetherSX2 instead and hope that the games you are interested in are fully supported.

I wanted to also test an experimental build of the Wii U emulator Cemu with a Metal backend, but I still have some problems getting games to run.

Some eye candy of 3DMark2000 running on 86Box:
1735855790105.png
 
Quick update to solve the controller issue in ares:
Select SDL instead of Quartz as the Input Driver. (I knew I had that working before, but I thought it might have been a regression in this version.)

1738262320337.png
 
Readers with some insight might have missed a few more systems, but most of these are experimental and take more time to test.

I'v been waiting over a year for a native version of the Playstation 3 emulator RCPS3, ever since I saw LevelCap play Killzone 3 on a PC using it.
I wasn't totally sure why the Apple Silicon version took so long, even though there was a macOS version already. Since LLVM is used as the code generator of the DynaRec, this should be much easier than writing a bare-metal ARM64 code generator from scratch.
But there has been an experimental Apple Silicon build for a while:

Funnily enough, the big hurdle is not to find the PS3 BIOS, you can just download it from Sony and the update seems to be on every game disc as well.
The most problematic thing is getting the discs decoded. I ended up using a Windows tool called PS3Dec Simple GUI through Whisky, because everything else was just way too complicated.
If a game has/needs updates, there is another tool called rusty-psn, which seems to download the updates straight from the Playstation Network.

Compatibility is a bit spotty. I couldn't get some of the more interesting titles to work at all (i.e., so far I had no luck with The Last of Us or Uncharted).
Dark Souls started before I installed the game updates, but I wasn't able to leave the first room. After installing the game updates, the emulator hung during precompilation of the last code block.

If the games run properly, then performance is actually quite good.
I tried RCPS3 on my M1 MacBook Air before, and Killzone HD for the PS3 actually ran smoother than Killzone on PCSX2. But that's the big difference between a native emulator and one running through Rosetta 2.
One day I'll have see if I can test with one emulator if the a native interpreter-only version is faster or slower than a DynaRec running through Rosetta 2.

But RCPS3 is truly experimental. The build from two days ago always crashed during precompilation, while yesterday's version started working again.
 
Talking of non-native emulators, the Wii U emulator Cemu is another big one. I mostly tested it, because a colleague of mine wanted to know if I thought that it would work on the base-model Mac mini M4.
Compatibility of the standard Mac port apparently isn't that good, because like other emulators it runs into the limitations of MoltenVK.
But there is an experimental build, which adds Metal support:


The second link also mentions that an Android port of Cemu is being worked on, which means that we might actually get an ARM64 recompiler one day...
The biggest hurdle here was getting updates for games that refused to run without them. After I tried several options I had to resort to a Windows application, which recognised that it was launched under Wine but still crashed. In the end I ran it with Windows 11 on Parallels.

A few hints regarding the setup:
  • Under General settings / Graphics / Graphics API make sure that Metal is selected.
  • Under General settings / Audio / TV Device select your audio output and increase the volume. The preset is Disabled and 50%, i.e., you won't get any sound at first.
  • My Xbox Series controller did only work as a generic SDLController instead of the recognised Xbox controller, for whatever reason.
    Redefining the buttons is also non-intuitive, because the window doesn't show that you actually selected a setting to be changed. Simply single-click the setting and press the button on the controller.
    For most non-WiiU controllers I'd recommend emulating the "Wii U Pro Controller".
  • A lot more interesting bits are hidden under Options / Graphics packs, which are a lot more generic options and enhancements for specific games than the menu name suggests. But you'll have to download the latest community graphics packs first.
    E.g., for BOTW there is an option named FPS++ under Mods, which lets you increase the FPS limit way past the Wii U native 30 FPS. But 60 FPS is probably the most reasonable setting.
In terms of performance, Zelda BOTW is probably the most interesting title.
On the M4 Pro and with FPS++ enabled it rarely dips only very slightly under the 60 FPS, while Cemu eats about 400% CPU according to MenuMeters.
In this experimental build async compilation of shaders works, which means most of the time, you won't even notice that shaders have to be compiled. The only real slowdown was when one of the dormant robots woke up, fired its laser and turned the grass around Link into a sea of fire. I was busy getting out alive, but I'm pretty sure the slowdown was due to shader compilation.

The overlay output provides a bit more details on the performance:
1738502288570.png


Since it has five of the cores, which according to Activity Monitor are definitely performance cores, running at close to 66%, I'm somewhat doubtful that Zelda BOTW would run at 60 FPS on a base Mac mini M4, with only four performance cores.
The GPU also seems to be over 50%, therefore the M4 with with half the GPU cores would most likely be maxed out.
 
Last edited:
Update on the Xbox emulator xemu. While I was somewhat sure that some of my issues last time were due to less compatible graphics emulation and probably some timing issues, the one-line comments for each release since then didn’t really convey if any of these issues has been fixed or not.

Yesterday, I decided to give the latest version a quick look, which turned into a much longer session than anticipated, because a lot of problems were suddenly gone.
  • Halo 2 had graphics issues and was too slow to be playable. I would say it’s still not perfect, but the graphics looked good, and the frame rate was around 20 FPS most of the time, with the occasional slowdown. Definitely playable (at least how far I got), but I wouldn’t recommend playing above normal difficulty.
  • Riddick didn’t even display the initial menu correctly, because it has a fancy 3D metal look. This time the menu was actually usable and the game was playable. Unfortunately, no FPS statistics, because the debug output showed 1 FPS all the time, despite that fact that the game definitely ran faster than that.
  • Oddworld Stranger’s Wrath wasn’t playable last time, because often the floors were simply missing. There were still some slight graphics issues with the new version, but I managed to play through the full tutorial without any big problems.
You’ll still need a beefy machine (I tested on a M4 Pro), but it seems a lot more titles are actually playable now, although they might not reach 30 FPS. But it was a surprising big step ahead that I didn’t expect.
 
Last edited:
Two consoles of the 5th generation are notoriously difficult to emulate.
For the N64, the culprit is the complexity of its two chips, especially its "Reality Coprocessor". This might have been finally conquered with the aforementioned ares emulator.
The other system is the Sega Saturn. In this case the problem most likely isn't the complexity of the individual chips but rather the fact that there are about 8 of them interacting with each other.
While Mednafen has provided decent Saturn emulation for a while, it has no GUI and is quite a hassle to use.
Roughly one month ago was the first release of Ymir (named after one of Saturn's moons), and the third release added macOS compatibility as well as binaries for Intel and Apple Silicon.
The negative points first:
  • It's not a proper macOS application yet: It puts files and folders in the home directory instead of Preferences and Application Support. Also, double-clicking the binary opens a terminal windows, which then opens the actual emulator window.
  • According to its description and the source code, the emulator should support CHD images, but it doesn't seem to work. So it's CUE/BIN for now.
  • 3D games have noticeable interlacing and there is no hardware rendering (yet?).
    The question is, if the fact that Saturn doesn't use triangles blocks the possibility of hardware rendering. Maybe one of our local graphics specialists has better insight.
The good news:
  • The emulator is a lot more compatible than I would expect a month after the first release.
  • While Saturn 3D graphics are unorthodox, some of the 2D games show very impressive multi-layering.
  • Although the emulator has no dynarec, the performance is quite good, about 40% to 60% CPU use on my M4 Pro.
  • My Xbox Series gamepad was recognised without any issues.
  • While I haven't tested it that extensively, I'm positively surprised that the emulator hasn't crashed once.
This is definitely one to watch. Hopefully, there will be interesting updates in the future.

 
Correction:
Ymir 0.1.3 did not support CHD, but the latest 0.1.4 release does.
Unfortunately, the GUI seems to be broken in 0.1.4 on macOS, rendering more or less unusable. I already deleted the settings to eliminate the possibility of incompatibility between the two versions, but I still have the GUI issue.
 
Saturn ran great on my M1 Pro - OpenEMU for the win, using one of the Saturn back ends. Ran like butter for what I tried.
 
Saturn ran great on my M1 Pro - OpenEMU for the win, using one of the Saturn back ends. Ran like butter for what I tried.

I'm pretty sure OpenEmu is using Mednafen for Saturn emulation. I've mentioned Mednafen above, and pure it's a bit hard to use. It probably works good with a frontend like OpenEmu, but I'm a bit of a purist and thus not the biggest fan of multi-system emulators or GUI frontends. (I'm making an exception for ares, since that has the best N64 emulation at the moment.)

Therefore, Saturn emulation isn't exactly new, but getting that kind of compatibility from Ymir a month after its first release is quite impressive.
Unfortunately, it's GUI is still broken on macOS with versions after 0.1.3.

Did you use the official build of OpenEmu under Rosetta 2, or the unofficial Apple Silicon build?
 
I forget, think it was a beta, not sure if apple silicon.
Screenshot 2025-06-11 at 10.14.15 am.png


edit:
actually it's intel - checked in system information.
 
Slight tangent, I use Silicon-Info to quickly see in the menu bar if an application is native or not. The tool hasn't been updated for quite a while and now opens an empty setting window after a reboot, but otherwise it still works:

In the meantime there has been an Apple Silicon build of Cemu:

But two days ago the Metal build of Cemu also became native as well:

A quick test shows that the native build uses only slightly less CPU resources compared to the Intel build running through Rosetta 2. I suspect that ARM64 dynarec isn't well optimised, because switching to native builds showed much more dramatic changes for Dolphin or Flycast, for example.
But the good news is that the frame rate seems to be more stable now.
 
Ymir 0.1.5, which was released today, not only fixes the display scaling bug that was introduced with version 0.1.4, but also added the graphical features deinterlacing (which helps a lot with games like Virtua Fighter) and transparent meshes (which turns net-like textures into more appealing semi-transparent textures).
 
Late update: Ymir 0.2.0 is now a proper macOS app, which also means that settings and ROM files end up where they belong (in Library).
But xattr -cr app is necessary for it to start.
Supposedly, there has been a big compatibility leap, but I was too busy with other stuff to test properly.
 
I tested UTM/QEMU in the early days of my MacBook Air M1 (roughly 5 years ago).
It was partly a joke, because I wanted to make a screenshot with MacOS 6, 7, 8, 9, 11, and 11 running at the same time.
OS9 ran OK-ish, OSX sluggish, and Windows XP took several minutes to boot, therefore I did not try UTM on the M4 Pro again until yesterday.

Either UTM/QEMU got better, or the new wizard picks better options than I did 5 years ago, or the M4 is really that much faster. But Windows definitely runs better now. While I've had some odd hangs during booting and shutdown (where QEMU is using only 10% of the CPU), these are rare and normally Windows XP boots in half a minute.

Since version 5.2 of 86Box has an integrated manager now, which meant I had to set up the machines again, I wanted to run some comparison between 86Box and UTM.
I used CrystalMark for benchmarking, but I'm suspicious of the results. I'm not totally sure what the benchmark values mean, but I timed UTM just one or two seconds faster in the CPU benchmark (out of roughly a minute total). Maybe QEMU has imprecise timer emulation, which results in these differences.
Also, due to emulating the Voodoo Banshee with 86Box, the 3D graphics are definitely smoother, although this isn't reflected in the marks at all.

Some tips for installing Windows in UTM:
  • The Intel i440FX presets seem to be OK for Windows 98.
    Since the "Default" CPU was recognised as a Pentium II, I tried setting "pentium2" explicitly, but that seemed to run slightly slower. If in doubt, stick to "Default".
  • I couldn't get Windows 2000 to install at all. It resets near the end of the hardware installation and then starts all over again.
  • For Windows XP, start with the Intel i440FX, but make the following changes:
    • Turn off the RNG device (there is no driver for it).
    • Change the NIC from ne2k to rtl8139.
    • Use AC97 instead of SB16 for the sound.
  • For Windows 7 or newer, use Intel ICH9. I didn't deviate from the presets here.
  • VirtIO-Win is apparently only supports Windows 8 or newer, which I couldn't test.
Now to the benchmarks... I ran these in relatively low resolutions, because the Windows 98 driver for the Cirrus Logic chip that QEMU emulates cannot handle that much and I wanted to keep things fair (I had a much higher resolution in 86Box initially, which made the graphics quite slow).

Further up in the thread I ran 86Box with a 450MHz Pentium II, but I had to clock it down to 400MHz, otherwise version 5.2 didn't manage to emulate 100% CPU and the sound became choppy.

1763142723335.png


Same operating system (98Lite = Windows 98 SE base, but Explorer replacement from Windows 95) on UTM.
CrystalMark claims that the CPU is quite a bit faster, which I don't really see with the stopwatch.
Disk IO is similar, 2D is worse, 3D is just wrong, because the Voodoo Banshee emulation of 86Box is definitely smoother, although still choppy.

1763142996103.png


Windows XP without UTM tools is supposedly the fastest:

1763143046399.png


Windows XP with UTM tools (and a second CPU core) is slightly slower, in terms of disk IO sometimes substantially:

1763143131441.png


Last but now least Windows 7 with UTM tools and 4 CPU cores. CPU slightly slower, sequential IO much slower, but random IO faster.
This was actually the 64-bit version of Windows 7, not x86 as CrystalMark claims.

1763143243349.png


For Windows 98 or older, I would probably still recommend 86Box, since it's the more accurate emulation, and there are more hardware options, especially Voodoo 3D, which QEMU doesn't have.
Starting with Windows 2000, UTM automatically integrates the mouse even during installation without any tools installed, i.e., no explicit mouse-grab necessary.
If you have an older Windows XP or 7 license, and you want to run some older software (no 3D games!), then UTM might be a good alternative to CrossOver or Parallels.
Starting with Windows 8, the VirtIO drivers might accelerate some things (hopefully graphics), but I assume the CPU emulation will become the bottleneck.
For more demanding Windows software, CrossOver or Parallels with Windows 11 on ARM are likely the best options.
 
Some more testing...
Even with different workarounds mentioned on the Internet, I did not get Windows 2000 to install, which is a bit of a bummer, since I enjoyed its look more than that of XP.
According to the official UTM guide, one is supposed to use the 64-bit Intel ICH9 for Windows XP, but I never got it past a certain blue screen, no matter how many settings I adjusted. Stick to the settings that I mentioned above, and it should work fine.

I deleted most of the "VMs", since I gave them hardly enough hardware to install any software.
I reinstalled Windows XP with two CPUs and actually played some Star Wars Galactic Battlegrounds on it, since the game ceased to work with CrossOver a while ago, and it only needs 2D graphics.
The game ran absolutely playable, some occasional stutter when scrolling, but nothing annoying, and the sound was rock-solid.

I noticed that the Intel ICH9 default configuration that I'm using for Windows 7 is not using the standard Cirrus Logic graphics chip emulation, but virtio-vga-gl, which explains the possibility of higher resolutions and mostly better 2D performance compared to the 32-bit Windows installations.
Unfortunately, the 3D acceleration will not be working, since the VirtIO-Win drivers require at least Windows 8.
I thought it still might provide enough of an upgrade to make Galactic Battlegrounds run even smoother. But apparently this graphics selection does not support DirectDraw, which means most 2D games will not run.
I also installed Service Pack 1 for Windows 7, which took maybe two or three hours.

Which brings me to my preliminary verdict:
  • Use CrossOver or Windows 11 on ARM for games that are not at least 25 years old.
  • 3D emulation on 86Box for older games might be possible, but I wouldn't hold my breath.
  • Windows XP on UTM might be a good option for some 2D games. Probably with higher compatibility than CrossOver or Windows 11 on ARM.
  • Windows 7 could be good for some older applications, but gaming is most likely out of the question.
I also tested OSX 10.5. The installation took ages, then complained about a problem with the partition, but when I thought I had to do it all over again, it just booted.
Booting takes one whole minute (compared to half a minute for Windows XP or 7). Then you are stuck with 800x600 resolution, somewhat sluggish reactivity, and it doesn't let you fake multiple G4s (no G5 emulation). Strange, I remember the PowerMac emulation running better on the M1 than Windows emulation.
It's nice to see 10.5 again, but I don't really know what to do with it.
I also believe that PowerMac emulation in QEMU hasn't been improved for years. Without guest addons to improve resolution and performance, I don't see that much use for it.
I'll probably get rid of it soon, because it eats up over 12 GB for a little glimpse of nostalgia.
 
Some more updates from the Windows on UTM front...

Windows 2000 actually is installable, but it takes both options cpu=pentium-v1 and -global ide-device.win2k-install-hack=on for the installation to finish.
Afterwards, the global argument can be deleted and the CPU can be changed to "Default".
The first click on the Start menu after the initial boot doesn't work properly and the OS has to be shut down via Ctrl+Alt+Del.
Overall, Windows 2000 is less impressive than I had it in memory, and due to it needing the Cirrus Logic graphics chip emulation, it also doesn't have the best resolution.
BTW, 32-bit Windows XP on the i440FX chipset actually works better with a standard VGA emulation.
EDIT: I had to go back to the Cirrus Logic, because with VGA Galactic Battlegrounds gave me the same error that DirectDraw is not supported that I got in Windows 7.

During my search for solutions for the Windows 2000 problem, I stumbled across these Windows installation guides, which gave me a few more ideas to try:

As it turns out, Windows XP does work on the 64-bit Q35 chipset, but one needs to install additional drivers from floppy before the installation starts.
The result is a bit underwhelming, especially the disk access is much slower than expected with a VirtIO driver installed. I still think that Windows XP works better with the i440FX chipset.

I also tried Windows 98 with SoftGPU installed. I'm guessing it works better with VirtualBox or VMware, where it can use 3D passthrough.
With only software emulation, the main advantage is higher resolution and color depth as well as 2D acceleration.
3D works in theory (i.e. 3D applications will start), but it's way too slow to be of any use. The benchmark tool 3DMark actually just froze.

Then I remembered that the guest add ons supposedly provide 3D acceleration for Windows 8 and up, when virtio-vga-gl is used as the graphics card.
I installed Windows Embedded 8.1; I'm not sure if its due to the embedded variant, but it boots in roughly 10 seconds, and yes, that is the emulated 64-bit version.
Unlike Windows 7 it asked me if I wanted to install DirectPlay, when I tried Galactic Battlegrounds on it. Therefore, it started, but it was unplayable, because it was missing the mouse pointer in-game.
The 3D performance, unfortunately, isn't great. 3DMark2000 was really choppy, and gave it a rating of 152. 86Box with Voodoo Banshee emulation managed a rating of 1247 in the same benchmark.
But unlike with the other Windows versions, 3D isn't totally out of the question. Maybe it it's something primitive, it would actually work.
I'm not a fan of Windows 8, and 8.1 is only slightly better, but combined with the fastest boot time and what seems like the highest compatibility, this might be the best option for UTM, before switching to Windows 11 on ARM.

The CrystalMark CPU score isn't the highest, but not bad, and the disk and 2D benchmarks push the overall rating higher than all the other ones I tested.
(BTW, I had to lower the RAM below 4 GB, otherwise 3DMark2000 complained that I needed more than 64 MB.)

1763403169341.png
 
Last edited:
Back
Top