Why Not Pentium III?

Word is out there that an individual is trying to develop Pentium III emulation as part of a fork of 86Box, regardless of how slow it is, in the name of “hardware preservation”. But why didn’t we do it in the first place? Why did we, developers of a PC emulator clearly aimed at the preservation of hardware and software, limit ourselves to the Pentium II and an underperforming competitor (the VIA Cyrix III), and why did we do these two knowing they’re already pretty slow to emulate? It’s story time.

Backstory: Orphans of Virtual PC

Our lead developer OBattler was a huge fan of Microsoft Virtual PC. Unlike other virtualizers such as VMware and VirtualBox, Virtual PC was fast while not being detrimental to the odd demands of legacy operating systems. It emulated a relatively sane 440BX machine with a Pentium II CPU core, which could run some Windows betas and other obscure software that competing virtualizers struggled to run.

But there was one problem: Virtual PC was unmaintained. Microsoft discontinued Virtual PC 2007 after Windows 7 shipped with the limited Windows Virtual PC, and Windows 8 with the even more limited Hyper-V. Nevertheless, the old Virtual PC released in 2006 still limped along; when Windows 8 broke it, some clever people managed to fix it by swapping a file from the VPC-based Windows Phone 7 SDK emulator. But then one day, Microsoft released a public beta version of Windows 10 that broke Virtual PC for good, never to be fixed again in the final version or one of the many updates.

Furthermore, our developer was becoming increasingly frustrated with Virtual PC limitations he could not address through patching; for instance, it could not take advantage of the full C8000-EFFFF memory range for Upper Memory Blocks (UMBs) due to a forced option ROM at E0000, limiting the amount of upper memory available for drivers to be loaded above conventional memory on DOS setups. These limitations, compounded with the aforementioned Windows 10 incompatibility, forced him to look for alternatives.

Making PCem better than Virtual PC

At the time (around 2014), PCem was a promising full system emulator which had just crossed into the Pentium era. Most importantly, it was open source, which meant that any issues could be patched with ease. With that in mind, OBattler started hacking around PCem, fixing an issue with the Japanese DOS/V, merging network emulation from another fork, and inviting other developers including your writer. These fixes were released to the public under a variety of names (such as PCem-Unofficial and PCem-X) and upstreamed to PCem author Sarah Walker; but things got to a point where our changes grew beyond the scope of what Sarah was willing to upstream, so we forked PCem and created the 86Box project.

If we had any goal early on (before taking on the 86Box name), it was to make a better emulator than Virtual PC was a virtualizer. We believed part of that goal could be achieved by developing Pentium II emulation, while hoping that the single-thread performance of future host CPUs would allow it to be emulated as reasonably fast as Virtual PC. Remember, Intel was a performance monopoly still happily tick-tocking away at the time; their 10nm troubles and AMD Ryzen competition were not a thing yet.

This Pentium II emulation was eventually shelved as generational improvements to single-thread performance stagnated (and even regressed with Ryzen at first), and also due to a very mysterious bug triggered by Windows XP’s use of the Pentium II’s SYSENTER/SYSEXIT feature; as AMD delivered a return to significant generational improvements in x86 and (ironically) PCem’s author found a fix to the aforementioned bug while independently developing their own Pentium II emulation, we took our version off the shelf in 2020 as part of 86Box v2.10, which would later become v3.0 released in late 2021.

Drawing the line

As all these years went by, we realized emulating faster CPUs than the Pentium II at practical speeds would not be achievable, not without a very big (even bigger than Apple’s M1 was) and unprecedented breakthrough in performance of either desktop CPUs or the dynamic recompiler we inherited from PCem; we knew an absolute beast of a CPU (which turned out to be the Ryzen 9 5950X) would be required to emulate the entry-level 233 MHz Pentium II at a speed good enough for games, let alone higher clock speeds.

A decision was therefore made to keep the Pentium II and Celeron CPUs, with lower off-spec clock speeds available for people with older and/or lower-end host CPUs that aren’t up to emulating the actual clocks these CPUs were released with at a reasonable speed, and to not develop any more iterations of the Intel P6 core or other faster cores, focusing any CPU-related efforts into improving the dynamic recompiler’s performance and closing our performance gap in relation to PCem. The VIA Cyrix III was an exception, as it’s significantly slower than a Pentium II clock-for-clock, and being based on the IDT WinChip, much of its infrastructure was already in place.

Misplaced childhood

Until, of course, one of our past contributors decided they wanted to emulate their childhood AMD Athlon system, no matter what speed it would run at. The AMD K7 core is well known to be a more advanced design delivering more instructions per clock than the P6, and therefore, even the lowest-end 500 MHz “Argon” Athlon was way off our radar. While we don’t know exactly which CPU that system had, it was quite possibly an Athlon XP, which would be at least twice as fast as the entry-level “Argon”.

Arguments ensued. After all, what is the point of emulating such a fast CPU at half speed, if not less? You can’t reasonably play games at such speeds, and if you just wanted to mess around with operating systems, a slower CPU at 100% speed will do the same job as a twice-as-fast CPU at 50% speed, without mouse lag, crunchy audio and the (uncommon but not unseen) risk of emulation desyncs; at least some of us in the team have endured installing Windows 7 on CPUs slower than a 233 MHz Pentium II just fine. More on running newer versions of Windows later.

After numerous disagreements with that contributor, including but not limited to their insistence on taking very tall orders like the Athlon and the notoriously complex and undocumented NVIDIA RIVA 3D accelerators (if any of you reading this were sold on 86Box by its supposed RIVA emulation, we’re really sorry, that person was making unfulfillable promises in our name), they’ve decided to fork 86Box and start developing emulation of the Athlon-competing Pentium III, as we already had the required P6 core and compatible Slot 1 and Socket 370 motherboards in place.

Stick to the Windows that’s best

It is widely known (and even shown in the cover of our v3.0 release post) that with a new enough Super Socket 7 or Pentium II setup, you can actually run Windows 7 on 86Box. But “running” is a massive overstatement: Windows versions beyond XP were originally designed for much newer hardware than 86Box can emulate at full speed on modern computers, even if you take Microsoft’s official minimum requirements into account. Windows Vista and 7 were never meant to even boot on Pentium 1 systems, but Microsoft was pandering to the embedded computing industry at the time by avoiding intentionally breaking support for these old CPUs, and sometimes even fixing it in updates. This changed with Windows 8, which required a late model Pentium 4 with the SSE2 instruction set and NX bit feature at a bare minimum; Windows 7 also eventually received updates which required a Pentium III with SSE at a minimum.

As a result of this, we’ve been getting many requests to emulate newer CPUs so that 86Box can “run Windows 8 and 10”. Even if such CPUs were to be implemented, the user experience would be extremely painful; as outlined earlier, there is no host system in existence which can consistently keep up with the fastest CPUs we already emulate, let alone faster ones. Running newer versions of Windows on 86Box is just as much of a questionable endeavor as it is on an equivalent real system: it’s a fun experiment maybe worth making a YouTube video about, and nothing more. Everything will be so slow you won’t even want to open a web browser (if they run at all due to CPU requirements). Just stick to Windows 98, maybe 2000 or XP if your host system is capable; for newer versions, virtualizers exist, you know.

While we have fixed emulation bugs explicitly related to newer Windows versions (STI interrupt blocking during SYSENTER/SYSEXIT, incrementing of RDTSC in dynamic recompiler mode, etc.), it was all done on principle: there might be another older operating system or application out there which runs into the same bug. Theoretically, you don’t need to be running Windows XP to stumble upon incorrect STI behavior, or Windows 7 to hit a division by zero caused by RDTSC returning the same value twice.

This is fine, we’re just telling our side

We take no issue with forking 86Box. We know at least two other forks are also floating around, though they’re not quite up to date in relation to the upstream 86Box code. We understand why people may disagree with our ideals, because our project got started after we disagreed with the ideals of PCem’s author, even though they weren’t as welcoming to the concept of forking their code.

However, we also have the duty to inform the general public about our side of the story, before misinformation starts spreading around and people end up bashing on 86Box because “it doesn’t have the Pentium III that this other emulator does”. We’ve dealt with quite a bit of misinformation (and possibly even disinformation) over the years about how we’ve supposedly mistreated PCem’s developer and supposedly misled the public with the unattainable RIVA emulation, neither of which we have done. The last thing we want is more misinformation hindering our project’s growth.

We don’t deny the fact that not emulating such fast CPUs was our choice, and that choices have consequences. We don’t expect higher-end Pentium II or faster CPUs to be emulatable at a good speed in the near future, unless some CPU maker pulls a miracle off (everyone is now rooting for an M1-level comeback by Intel), or someone somehow takes on the job of bolting an inaccurate virtualized CPU core to the relatively accurate 86Box hardware emulation, which we wouldn’t be surprised if someone tried to do after reading this post…