That you can plug legacy x86 extension hardware into the board, and have it find a bug-for-bug-compatible x86 system to talk to on the other end. A major use-c

That you can plug legacy x86 extension hardware into the board, and have it find a bug-for-bug-compatible x86 system to talk to on the other end. A major use-case being embedded systems — e.g. industrial control systems. These systems use a combination of 1. custom hardware — usually in the form of peripheral cards — built to speak old legacy x86-only bus protocols like ISA; and 2. old custom software, designed to run on an x86 CPU (usually in DOS), and to speak directly to that hardware over that bus. You can't just find some USB adapter for the old hardware's bus, because the software won't take it. And you can't just replace the old software, because the new software (whether a newer version of the old software, or software from another vendor) won't control the old card; and the card speaks an even lower-level (probably analogue!) protocol specific to the industrial system. Often, on these old systems, the custom peripheral card is still working due to it being solid-state (and thank god for that; the card's vendor is probably long-gone!) but the old x86 box the card lived in for the last 40 years is dying of various old-computer maladies — or just can't be made to fit into a new form-factor forced by a newer generation of the industrial system being controlled. In such a case, you ideally want to find a new embedded host system, made of new parts that will last you the next 40 years, but which can nevertheless still talk in very specific, custom, low-level ways to your existing peripheral card. And you also want that new embedded host system to be as cheap as possible — because your factory-or-whatever, might have 400 of these embedded systems all over the place. --- Though, that being said, here's a completely different use-case. Consider "retro consoles" with cartridge slots, like the Retron 5. A lot of people don't like these, because they don't really do what it seems like they should do. If an Electrical Engineer sees a "retro console" with e.g. a SNES cartridge port, then they'd assume that the console talks to SNES cartridges over all the pins on the cartridge-system bus, just like a SNES does, to perform its functions — that each synchronous virtual bus-read of the virtual CPU, would translate to a real bus-read to the bus that routes up to "cartridge address-space"; where anything in the cartridge could then service that bus-read. And that SNES cartridges with custom chips in them, that override functionalities of the console on a per-bus-read basis, would therefore "just work" the same way they do on a real SNES. But our hypothetical EE will soon be disappointed to learn that these "retro consoles" mostly† don't work this way at all. They only implement enough of the cartridge-system bus to do a one-time rip of cartridge's ROM banks on boot, loading them as a ROM image into system memory; and from then on all emulation occurs in-system, without the cartridge being involved at all. if the cartridge requires a co-processor, well, you might get the effect of using it because the emulator deduced the need for it from analyzing the ROM image, and so turned on an emulation of that co-processor. But you'll never get such a system to make use of any cartridge component that didn't have support for it explicitly implemented into the retro console's emulator at design time. Ever seen this video (https://www.youtube.com/watch?v=ar9WRwCiSr0 https://www.youtube.com/watch?v=ar9WRwCiSr0) about "reverse emulating" the NES? This custom NES cartridge with an RPi in it, can only possibly work on a "real NES." You can't put that cartridge into a Retron 5 and have it work. But this cartridge would work on a board that is bus-compatible with a NES. For the purposes of the trick, such a board would be a "real NES." † There are FPGA retro-consoles that do work this way! (The MiSTer, the Analogue Pocket, etc.) The MiSTer is very much a (hardware-accelerated) bus-compatible emulator. My only problem with it is that its own multi-platform flexibility means that it's extremely high-BOM — rather the opposite of the point here, which is to use emulation to decrease BOM.