---
layout: post
title: "Why Not Pentium III?"
description: "When does “preservation” in emulation become impractical?"
authors: ["richardg867"]
image: "/assets/images/whynotp3/hero.png"
---

{% include imageheading.html url="/assets/images/whynotp3/hero.png" separator=" " %}

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**](https://github.com/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](https://en.wikipedia.org/wiki/Upper_memory_area) (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**](https://github.com/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](https://en.wikipedia.org/wiki/Tick%E2%80%93tock_model) 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]({% post_url 2022-01-07-pcem-migration-guide %}#performance-will-be-different) in relation to PCem. The [VIA Cyrix III](https://en.wikipedia.org/wiki/Cyrix_III) was an exception, as it's significantly slower than a Pentium II clock-for-clock, and being based on the [IDT WinChip](https://en.wikipedia.org/wiki/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](https://en.wikipedia.org/wiki/List_of_AMD_Athlon_microprocessors#Athlon_\(Model_1,K7_%22Argon%22,_250_nm\) 'Which matched or beat the 500 MHz "Katmai" Pentium III in most benchmarks') 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]({% post_url 2021-12-01-86box-v3-0 %})\) 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](https://www.google.com/search?q=%22Vortex86%22+%22Windows+7%22 "Vortex86 is a Pentium 1-class CPU from the Windows 7 era") at the time by avoiding intentionally breaking support for these old CPUs, and [sometimes even fixing it in updates](http://web.archive.org/web/20110814164028/http://support.microsoft.com/kb/980358 "KB980358 fixes a BSOD when booting Windows 7 RTM on a Pentium 1"). 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](https://www.youtube.com/watch?v=Zs8-rQKvptM) 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 **dis**information) 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...
