86Box emulates an old PC at the hardware level. CPU timing, chipset behaviour, ISA and PCI buses, graphics chipsets, sound devices, and disk controllers all matter to getting period software to behave properly. That does not guarantee identical performance to the original hardware, as the Cinebench results below illustrate. Frankly the project is fascinating and the effort has me in awe, but that accuracy is expensive, and almost all of the cost lands on a single host thread.

The practical consequence is quite straightforward in that core count barely matters here. What really matters is how fast one core can run, and how long it can hold that speed without throttling. Luckily for the Mac Mini here that's exactly where Apple Silicon has been strongest, and where the M6 shines.

Every 86Box test uses the same machine configurations, the same disk images and emulated hardware. The comparison set is:

• Mac Mini M6 (12-core CPU, 24GB, this review unit)
• Mac Mini M4 (base 10-core CPU, 16GB)

Testing was using a slightly modified build of 86Box 6.0, released on May 31, 2026. The team improved CPU emulation performance on ARM hosts and added an ARM64 just-in-time recompiler for Voodoo graphics. That second change is particularly relevant here, since the Windows 98 machine is running an emulated Voodoo 3. Some credit certainly belongs to the software, Apple Silicon has fast cores, but 86Box is also getting better at using them.

I have not measured the uplift from an older 86Box version, given this is a review of the M6 and not 86Box.

86Box reports an effective emulation speed as a percentage of its target speed. 100% means the host is keeping pace with the emulator's timing model, so anything less is a genuine problem. It does not guarantee that a benchmark will score exactly as it would on a physical CPU at the same clock.

Consistency also matters more than the average here. Even brief dips produce audible artefacts because sound hardware is fed in real time and starved buffers are heard as brief dropouts which are irritating. Basically any 86box setup that regularly dips below 100% will not feel right, and having adequate headroom on the system to comfortably emulate the target speed will be a much more stable experience.

The result is that turns each host machine into a ceiling rather than a score, and for any given emulated configuration there is a maximum CPU clock the host can sustain at a flat 100%. Because almost all of that work falls on one thread, single-threaded performance moves this ceiling substantially, which is the whole reason the M6 is interesting for this.

To find the ceiling, I made a custom build from the same commit as the 6.0 release (build 9001), extending the frequency tables in 50MHz steps up to 800MHz. The Deschutes frequency table patch is available if you want to try it yourself against that tagged release. It adds 500–800MHz entries with memory and cache timings scaled to retain approximately the same access latencies, and keeps the AT bus at 8.33MHz. The emulation code is otherwise unchanged. Both Macs used this build for the extended tests.

Some might argue a Pentium II at these speeds is not era appropriate. I argue it is just a little overclock!

The emulated machine is otherwise fixed across every run:

• Slot 1 motherboard with Pentium II (Deschutes), clock varied per run
• 256MB of memory
• Voodoo 3 emulated VGA with 16MB of video memory (2 threads)
• Windows 98 SE

The load is deliberately a little awkward, Cinebench 2000 running its CPU test while Winamp 2.76 plays a 16-bit 44,100Hz PCM WAV in the background. The audio is a bit of an achor as it's a real-time consumer of the emulated hardware, so any moment it falls behind is immediately audible.

The pass condition is ultimately subjective but strict. If I hear a dropout, or the reported emulation speed falls below 100% at any point, the run fails.

The base M4 Mac Mini holds 500MHz, with both Macs extremely stable throughout the full Cinebench 2000 and 3DMark 2000 SE runs at that speed. At 550MHz, the M4 starts to hitch. They are slight interruptions in Cinebench, but more noticeable during the 3DMark demo, and enough to fail the run.

The M6 passes 550MHz and 600MHz, which is incredible. At 600MHz it held a flat 100% through both Cinebench 2000 runs and the 3DMark 2000 SE demo, the latter giving it 7–8 minutes of uninterrupted testing. That makes the highest passing clock 20% higher than the M4's in this setup.

The CB2000 scores, for anyone who cares:

Those scores describe the emulated CPU at each clock. A completed render is not enough to pass, the 10.08 CB result at 650MHz came with one or two audible underruns. In reality, I think I may be being too firm on that run, and background activity could have caused the hitches. But staying true to the methodology, 600MHz is the result and leaves a lick of headroom. The 800MHz option is there to extend the test range but clearly not a speed either Mac can sustain.

There is an interesting wrinkle when comparing these scores with real hardware. An Ars Technica forum thread collecting Cinebench 2000 results includes the following user-reported figures:

Our emulated 450MHz Pentium II scores 7.02 CB, about 61% higher than that physical PII 450MHz result. At 300MHz the gap is larger still, with 4.62 CB against 2.38 CB. Bizarrely, our 600MHz result of 9.28 CB lands almost exactly alongside that 800MHz Coppermine. These are individual forum submissions from different systems, so they provide period context rather than a controlled comparison, but the discrepancy is substantial. It's also worth a mention this benchmark version is very old and long before it became the popular benchmark it is today.

I do not yet know why, it's possible memory bandwidth and cache timing within the emulated machine might have something to do with it. There is some relevant history in 86Box's v3.0 release notes, which explain that P6 emulation was not fully accurate because of the complexity of out-of-order execution and L2 cache behaviour. Deschutes timings were tuned to get reasonably close to real hardware. But yeah, not sure.

The discrepancy is already present at 300MHz and 450MHz, below the entries added by my patch. For this review, 600MHz remains the highest passing setting in this 86Box configuration, with a 20% higher stable clock than the M4. The CB2000 scores are useful for showing how that configuration scales, but I would not use them to claim equivalent performance across software on a real Pentium II or Pentium III.

Even the M4's 500MHz is remarkable alongside the overclocked 9950X3D demonstration I was using for context. I do not have a matched x86 run on this custom build, but the base M4 was already a much more capable retro machine than the original 450MHz limit let me establish.

The video below is from the earlier 450MHz run on the M6, where OBS was also compositing and encoding 720p30 H.264. It documents that run, rather than the new 600MHz result.

86Box parks the work on two 'super' cores, visible as cpu6 and cpu7, with the rest of the package largely idle. On the M6 those two cores average about 4,483MHz during the 450MHz Cinebench 2000 run and about 4,710MHz during the 600MHz run, peaking at 4,788MHz. Core activity climbs with the emulated clock too, from roughly 41% on each busy core at 450MHz to 45 to 49% at 600MHz, so there is still real headroom left at the highest passing clock. Whole package usage never passes 26%.

The M4 running the same configuration keeps its busy cores closer to 3.7GHz, and that gap is likely most of the reason it stops at 500MHz.