I was wondering whether the information was distributed into other articles. If all the mentioned computers had their own articles, this one can be turned into a list.
I'm going to guess this article was deleted because of the no original research rule (https://en.wikipedia.org/wiki/Wikipedia:No_original_research). Much as I hate Wikipedia deletionism/deletionists, this is usually a good reason not to keep articles.
Probably, even cite this post on HN as well and go for the double - reference it and guarantee be some YT vids as well that go into this era of history.
Not even low-tier in 2024. Money is scarce. I can think of some very big newspapers that will include articles for cash these days. You can find contacts to get this done for you in certain forums :)
Wikipedia prefers secondary sources to primary sources (as befits an encyclopaedia), and the blog post is a primary source for most of its content, so it would still be frowned upon.
This would be a secondary source -- the primary source would be the manufacturers themselves. Secondary doesn't mean that there is no original research; in fact it's the opposite. Primary contains facts but no analysis or synthesis, secondary references facts established elsewhere but adds context.
Yeah and it reads like a blog post and not encyclopedic. Stuff like this sentence:
> Aside from its low hardware specification, perhaps the biggest perceived "design flaw" of the IBM PC was the what is nowadays called Upper Memory Area [...]
IDK what the correct wikipedia response to that would be but probably citation required and NPOV. It could be made more neutral by rephrasing just to "The IBM PC architecture located I/O pages at the top of memory, limiting available RAM to 640 KiB. Alternatives such as the Victor located I/O pages at the start of memory allowing for 800-900 KiB of RAM". Let the reader come to the conclusion that they did this to try to improve the architecture, and don't assert that those architecture choices were qualitatively better, don't assert any opinions.
It just sounds like the author is pleading a bit for the reader to see that other alternatives made qualitatively better choices.
I have moved my blog to Dreamwidth and don't post on LJ any more, but I have a registered account and use uBlock Origin. I don't know what "that" means but to me it looks like an ordinary web page and does nothing clever or weird.
The LiveJournal article hijacked the back button, so that instead of returning me to HN it jumped to a random spot in the article. I had to long-press the back button to get back to HN. This on Firefox Mobile on Android with no adblockers.
Although PC-98 was not PC-compatible, Microsoft did support it in DOS and Windows. Programs that just went through DOS or Windows and didn't make lower level BIOS calls directly or try to manipulate hardware directly would frequently just work out of the box on PC-98.
The biggest difference between PC-98 and PC compatibles the DOS/Windows didn't hide that I remember, and that I remember being the biggest source of DOS/Windows programs failing even if they weren't doing low level calls was drive letter assignment.
On PC-98 A: was the drive you booted from. If your system had a floppy drive and a hard drive, and you booted from hard drive then A: would be your hard drive. B: would be your floppy.
In a PC-compatible A: would be the floppy and C: would be the hard disk regardless of which of the two you booted from.
Quite a few programs turned out to have "C: is the first hard drive" hard coded in.
There's a great channel on Youtube called Basement Bros that goes over a lot of the games available at the time for the PC-98 (and other outmoded Japanese home computer platforms) and also touches on how these machines were used day-to-day. Definitely worth a look, especially if you have any interest in the history of Japanese game development as a lot of very high-profile people got their start writing games and applications for the PC-88, PC-98, MSX, etc.
While a useful document, it's really not a Wikipedia article. It's making an argument, has a thesis statement, doesn't reference anything, and doesn't have a neutral point of view.
Interestingly, there are PC motherboards using PS5/Xbox SoCs that can run Windows so there must be decent PC compatibility in the SoC even if the consoles don't use it.
The Zenith Z100 series, Dec Rainbow, and Epson QX-10+ would have been interesting to include. There was a very, very rich set of non-IBMPC MSDOS machines in the period. IIRC MS-DOS early on included tools written in a variant of Forth so that portability was easy and memory use was tight.
How about the opposite: PC-compatible non-x86 computers?
Like how the Transmeta Crusoe was an x86-compatible CPU... but moreso.
The Crusoe was a thing marketed as a "CPU", that was actually internally an SoC (with the CPU inside it being non-x86.) This SoC had its own internal RAM and storage, and booted itself into internal software that then emulated an x86 CPU. All of the "CPU" data pins on the Crusoe SoC, routed to the virtual CPU inputs and outputs of this software. So, as far as other devices in the system were concerned, they were speaking to an x86 CPU.
Did anyone ever try taking this concept further? Maybe in the context of an industrial embedded computer?
I could imagine someone taking e.g. a modern ARM SoC with onboard RAM + eMMC; setting it up to boot into e.g. Bochs to emulate a virtual x86 (CPU + BIOS + other memory-mapped ROMs + platform controller hub + IO controllers + timer chips + TPM + etc — all the stuff on an x86 motherboard) — and then just setting up the SoC's GPIO pins to directly expose all the virtual buses of that virtual motherboard. You could then take such a chip, and design a physical "motherboard" for it to sit in, that's just a bunch of ports (e.g. PS2) and slots (e.g. ISA or maybe very slow PCI) routing directly to the SoC's GPIO pins.
This would be a very effective strategy, I think, for producing low-cost host platforms for the many industrial-automation ISA cards that still exist. So I have a feeling some OEM has at least tried to do this.
Probably there wouldn't be enough GPIO pins for most busses — x86 CPUs have tons of pins compared to almost any other architecture. So I wouldn't consider it cheating to feed parallel busses out serially at higher clock rates than those busses natively run at, and then to require the use of an external ser/des chip or two to flatten the signals back out. As long as it's the SoC itself speaking the protocol and the chip is "dumb", I think that'd still count.
Also keep in mind that unlike with the Crusoe, an "x86-on-ARM SoC" wouldn't need to have GPIO fast and wide enough to talk to external DRAM — as any memory could be internal to the SoC without breaking the contract. So the main constraint bottlenecking the Crusoe's CPU performance, wouldn't apply here. This thing could actually perform decently well — possibly well enough to run hard-realtime industrial control software coded in the 1990s, and to speak to ISA cards built in the 1990s. Which is all it would need to be able to do, for the obvious use-case.
People are already doing this. The PiStorm is a daughtercard that takes a Raspberry Pi running a 68000 emulator and exposes the pin-level interface of the 68000 to the host system. You can drop one into an Amiga's CPU socket and have an instant performance boost, plus the PiStorm is running additional software that lets you access the Pi's file system and operating system from the Amiga side. Compatibility for old Macs and Atari STs is coming soon as I understand it.
The things Amigaheads will do to keep their old hardware running and useful in the current era are... kind of insane.
What you're describing here is still CPU emulation (same as the Crusoe), not system emulation.
The Amiga equivalent for what I'm hypothesizing exists here, would be something that allows you to throw out the entire guts of your Amiga and replace it all with a freshly-printed PCB that has all the same ports/socket, but just one (modern, easy-to-source) chip on it, that internally emulates not only the 68000 but also all the other chips on the Amiga motherboard. And then anything you plugged into the original Amiga, would plug into this replacement board and work the same.
In most designs I've seen for projects like this, the "custom IO breakout host board" isn't really just a breakout board — it has a lot of bus controller chips of its own, because most modern bus protocols are just too fast/expensive to be run over GPIO pins. These extra chips usually raise the BOM past the point where it's worth it to build such a system; as at that point it's cheaper to just source old x86 parts (controller chips, sometimes CPU as well) from e-waste.
You want as much of that "motherboard logic" to be handled internal to the SoC as possible. Ideally, the board should only have the one SoC chip on it, plus jellybean parts and passives, plus ports and slots.
Also, let's lean on your example of video for a moment: "running an emulator full screen" isn't nearly the same thing as emulating the host busses — in that it results in the host describing that screen down its own SoC pins using something like HDMI. Whereas we don't even necessarily want a precomposed description of the screen on a signal line.
Remember, we're emulating the CPU and motherboard (and RAM, just because it's impractical not to) inside the SoC — but video support isn't actually an inherent part of an x86 motherboard. OEMs might integrate support for it onto a motherboard — but that "support" is just an embedded PCI-bus device, not some separate VGA bus.
Perhaps the system this board would revitalize, does something special with the communicated changes to the video data, such that pre-composed VGA (let alone HDMI) wouldn't solve the problem. For example, what if the system uses a custom PCI video card, that takes its VRAM and renders it out each frame, by compositing it together with another input video signal (ala the "video toasters" of the era)?
The only way to make that kind of thing work, is to emulate the PCI bus such that you can just plug the custom video card into one of the board's PCI sockets, and the emulated system will pick it up and use it.
It's emulating more than just the CPU if it exposes the RPi filesystem to the Amiga. With access to the CPU bus, you can pretend to be a number of other peripherals as well, or lots and lots of RAM and every ROM version available on the Pi side.
My point was more that there's no part of this project that actually emulates "a number of other peripherals", so it still needs to plug into a board that has working instances of all these other (no longer produced! rare! expensive!) chips on it.
In the instance above, the board was able to be revived — but only after swapping out a few chips with spares! Spares that need to be sourced!
But there are Amigas discovered in far worse internal condition. In those cases, the board itself is basically shot. Along with most of the chips. Often legs of DIPs are just corroded off, etc.
Having a single-SoC bus-compatible board, that you could use to entirely replace the internals of an Amiga, would mean that in that particular case, you could just shake the scraps of rust that the board has become out of the case, clean up the case and peripherals (which are likely still fine), and then build a "new" Amiga by putting that new SoC board in.
---
This is already a very common approach you'll see in e.g. the Gameboy modding scene — as so many gameboys are found as e-waste or in a ditch somewhere. Though the focus there isn't usually on decreasing parts cost with a one-SoC board, but rather getting perfect fidelity, since the target market is collectors who are willing to pay a high price and so a high BOM isn't as much a problem.
Also, amusingly enough, as there are people creating not just new bus-compaible GB/GBC/GBA boards, but also new custom buttons + shells, and even new non-IP-restricted BIOS ROM code, a "repaired gameboy" might actually contain no Nintendo-original components whatsoever. It's more a "generic" gameboy (by analogy to generic pharmaceuticals) at that point.
> no part of this project that actually emulates "a number of other peripherals"
It does - it's just that none of the emulated things go through the motherboard to be emulated. There is an Apple II HDMI board that can output Apple IIgs graphics from a II+ because it watches the peripheral bus for the signals a 65816 would make to setup a IIgs screen. Lots of Apple II accelerators emulate a number of things on-board and only use the socket to push peripheral IO.
> then build a "new" Amiga by putting that new SoC board in.
I really like this idea. A lot of the experience of a retro machine is the physical device. I've been toying with the idea of making Atari ST and Amiga keyboards with USB ports just so that the emulators would "feel" more real.
I have a PC-122 keyboard and using it in combination with a 3270 emulator feels just right (even when the mainframe is running on an RPi)
> I really like this idea. A lot of the experience of a retro machine is the physical device. I've been toying with the idea of making Atari ST and Amiga keyboards with USB ports just so that the emulators would "feel" more real.
THEC64 got a lot of love and goodwill from the retro community, just by having a breadbox case and a keyboard with real C64 layout and feel. It's still an emulator on an ARM computer, so it's not going to be cycle-accurate or even particularly low latency. But damn it, the feel of the thing is pretty close to booting and playing with a real C64 for 98% of the things you might do with it!
I know. I have one. That's what triggred this realization - that the physical interface is much more important than absolute fidelity to the original's internal logic.
The Atari 2600+ may be closer to what you were talking about. It is an SBC running an emulator, but it has external interfaces for the real Atari 2600 cartridge and joystick ports. There are some drawbacks; the system snarfs the entire ROM image into memory in a way that's not (yet) compatible with bank-switched ROMs or more exotic carts with extra hardware like Pitfall II, rather than just mapping the ROM into the 6502 address space. But when it works it feels more authentically Atari 2600-ish than many of the emulation boxes that have been released previously.
>According to Sun documentation the "... coprocessor card is not just PC-compatible, it is an actual PC that is constructed from real PC components and follows the de facto and emerging PC hardware design standards."
For a few years my work computer was a Sun Ultra 5 with a SunPCi card in it to handle email and office automation tasks. Both Solaris and Windows ran extremely slow on the system. It was truly a horrible thing.
I was a student Unix systems administrator back then. We had ultrasparc workstations, with a SunPCi card. I believe a number of us hooked up a monitor to the VGA connector on it, and used x2vnc to have a continuous virtual screen.
Not at all surprising, considering that the earlier Commodore C-128 had both a MOS 8502 chip and a Zilog Z80 chip -- latter was purely for a separate CP/M boot environment, it never ran concurrently.
I've also been interested in a different kind of "PC-compatible non-x86", as in building a standardized architecture with all the normal pieces and just swapping out the CPU. It is 100% possible to make a machine with an arch64 CPU that boots using UEFI, handles device enumeration like a PC, has the usual buses and everything, lives in an ATX case, and in every way it looks and acts like a regular PC that just happens to have a different CPU.
I think the x86 "standardized architecture" is an example of Conway's law: it's a natural outgrowth of the way the x86 hardware ecosystem evolved, with CPU, motherboard, and "card" manufacturers all being different companies that need formal standards to enable post-production integration (first by dedicated system builders setting DIP switches; then later at runtime with "plug and play"); and with each party being incentivized to swap out partners / "commoditize their complement", and therefore wanting constrained standards that ensure that they can design/code once to the standard's spec, and then switch suppliers without re-work.
Other architectures that came into existence more recently — ARM mainly, but possibly RISC-V is going this way as well — are mainly employed to produce integrated devices in a more supply-chain-oriented way, with vendors producing and licensing designs for "IP cores", and then device integrators combining these "IP cores" to fab SoCs.
Conway's Law (and game theory) predict that such an arrangement would have no need for API standards. It's pretty hard to force an ecosystem to do something, when they have no natural incentive to do it.
> It's pretty hard to force an ecosystem to do something, when they have no natural incentive to do it.
You don't need an ecosystem to do it, you only need one manufacturer, because the competing ecosystem already exists.
Suppose someone produced an ARM or RISC-V system board in an ATX form factor with BIOS or UEFI and standard PCIe and memory slots etc. That's all you need -- then you use the same chassis, power supply, memory, expansion cards, etc. as any commodity PC without having to establish a new ecosystem for any of those things.
The problem isn't with the hardware compatibility for the external components, but with software compatibility for the internal components.
"Adhering to x86 standards", would imply that the software of such a device, must be able to do unified management of hardware components — both external and internal — through x86 facilities like ACPI. As, even if you've got a system built out of (some) x86-compatible components, if you can't make use of software — like drivers and OS subsystems — designed to assume the x86 system architecture on it, then what's the point?
So, for example, the SoC's GPU IP-core.
Until about eight years ago, SoC-internal GPUs were just something directly memory- and IO-mapped at addresses hardcoded into proprietary device-specific drivers given by the IO-core developer to be (arbitrarily modified and then) compiled by the integrator. And even today, with DeviceTree, the DeviceTree descriptor for each of these devices is still something handed over out-of-band along with the core, and burned into the device's NVRAM or OS base-image by the integrator.
But now, in getting that same GPU to support "the x86 system-level architecture", the GPU would instead have to be "registered" somewhere inside the SoC in order for the SoC CPU to probe and discover it as a PCIe device — with an ACPI DDST available within a UEFI-discoverble boot-ROM address mapping, that can be used to power-manage it correctly (including complex things like the CPU being able to put the GPU or its individual cores into particular sleep-states through ACPI); with a PCIe HW device ID, that binds it to generic drivers when available, rather than allowing for device-specific driver customization; etc. And all of the ensuing device initialization that the driver does, would have to occur through ACPI and PCIe. Even though the core is internal to the SoC!
Support for complex ACPI hooks, and a driver impl that's flexible enough to be runitme-configured to serve various devices' needs without integration-time customization (so that it can be upstreamed into OSes), are both things that the IP-core vendor would have to implement. Currently, they are not implementing those things — and mostly wouldn't even know how. Being an IP core vendor — where you're running a job-shop producing designs to spec for specific downstream integration projects — isn't at-all the same job as being a peripheral card vendor in an ecosystem, where you actually have to deal with all these concerns. The IP-core vendors would have to learn how to do these things.
And if you don't do this — don't require this kind of software-visible x86-platform-ization for the internal IP-core hardware — then what you end up with is a hybrid system that needs its OS to manage both external PCie ACPI devices with generic drivers, and internal DeviceTree devices with device-specific drivers — potentially also virtualizing one as the other whenever needed (by e.g. making up PCIe device IDs for the DeviceTree devices). And not even Linux knows how to deal with that[0].
[0] If you're curious — https://docs.kernel.org/arch/arm64/arm-acpi.html#booting-usi.... As stated, ARM BSA/BBR devices are expected and required to use solely ACPI-registered device descriptions; such systems don't use DeviceTree at all. This severely restricts ARM SBA/BBR OEMs' choices of IP-core vendors, as those vendors, mostly know nothing about how to produce cores compliant with ACPI, nor drivers generic enough to be signed, sealed, and used in ACPI environments — let alone upstreamed. This is what I mean by "an ecosystem problem"! And it&#x...
That's assuming you're trying to mix and match ecosystems and put the GPU in the ARM SoC. But if the thing supports generic PCIe cards, you don't inherently need an iGPU, you can put a Radeon or GeForce in a PCIe slot, or use any of the smaller GPUs from the x86 ecosystem as you might find on a server system board.
Moreover, the assumption is that the company doing it is one of the ones making chips for phones rather than e.g. Nvidia or AMD. Nvidia already has the expertise to deal with ACPI and PCIe from making PC GPUs. AMD has more than that, they could pair ARM or RISC-V cores with their existing Radeon iGPUs and slot it into their existing CPU sockets, potentially with as little as a firmware update for existing system boards.
>Suppose someone produced an ARM or RISC-V system board in an ATX form factor with BIOS or UEFI and standard PCIe and memory slots etc. That's all you need -- then you use the same chassis, power supply, memory, expansion cards, etc. as any commodity PC without having to establish a new ecosystem for any of those things.
You mean, like the Milk-V Oasis[0]?
Full disclosure: TBA this summer, so not yet available.
This is basically what the Arm SBSA does (UEFI + ACPI) and essentially how all arm64 (and arm32) devices that support Windows work. SBSA doesn't solve the dismal lack of drivers for hardware in consumer devices, though, so just because there are arm64 devices that can be booted with UEFI+ACPI doesn't mean they "just work" like we expect amd64 machines to.
Yeah, I was actually thinking of SystemReady when I wrote my comment, and I have some vague understanding that Microsoft is all-in on it because ex. even their phones used UEFI, which is kind of beautiful. So the pieces are there, but sadly not nearly-universal like with x86 PCs:\
Separately, I will grant that drivers are their own sticking point, but I would like for them to be approximately the only sticking point. And even on x86 drivers are a problem; Linux generally has good mainline coverage of most networking cards, even wifi is good these days, but fingerprint readers have always been hit-or-miss. I just wish we could get to the point where once the drivers are upstreamed everything does Just Work and we can be free of "well this distro has a Raspberry Pi image but if you want to try an Orange Pi you need to find an OS that supports that exact board..."
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) 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 <...
There were lots of computers in the '80s which claimed official MS-DOS compatibility through emulation or added hardware. There were the Solution and Conqueror emulators for the Sinclair QL, there was Amiga Transformer from Commodore for the Amiga, there were ST Outlook and pc-ditto for the Atari ST.
Not long afterwards, hardware made MS-DOS compatibility much better because the speed of MS-DOS could easily be as fast as or faster than real IBM hardware. There were many options including the Sidecar, BridgeBoards, KCS PowerPC, and more on Amigas. Later, there were DOS compatibility cards for Macs.
Often these options had advantages over having a separate DOS compatible computer, like the ability to still run the native system at the same time, and often to share files / drives and other resources. It was an interesting time, for sure.
I mean MS is selling Arm based Windows machines now and I assume they're going to have to offer some kind of compatibility framework for legacy software.
> Did anyone ever try taking this concept further?
Well, yes, they did, but not on x86.
ISTM, from your later responses, that you have not fully defined what your idea is.
So the answer, based on what you said later, is both "yes" and "no."
No, it has not been done on x86. It is not likely to: x86 is still comfortably as fast as just about anything else out there, so there is no candidate host.
Crusoe chips did not do x86 emulation for performance reasons. They did it for power consumption reasons. They could run x86 code reasonably fast, but on much less electricity while producing much less heat.
They sold. I tried one. It was good. Benchmarks are very misleading and so are most of the comments here: its performance was pretty good on second and subsequent runs of whatever the test was, as the first run was used for performance profiling and generation of code for the emulator.
Result: first run slow, second run much faster, entirely separate from any disk caching.
But it drew Intel's attention and Intel responded by making much more power-efficient CPUs.
However, what you are asking, emulating x86 for performance -- that isn't going to happen. Even Apple Silicon Macs aren't that quick... not yet.
Entire new motherboards that emulate the original CPU? Sure. There are lots.
It could happen. Say, what if AMD released some chip using a popular new ISA, but offered acceleration for running code written for its legacy x86 ISA (which they have the rights to) as a differentiating feature.
This is IMHO a likely scenario as AMD tries to stay competitive while the world moves away from legacy x86 to a new ISA.
I had a couple of Sirius (AKA Victor) machines that were cast offs from my father's office given to me to play with. The first one was twin floppy, and the second had a 5MB hard drive. When I got the second one I think the first one got binned. When the second one broke, I bust it up to use the PSU and HDD on another computer. Of course, I really wish now that I'd kept at least one of them, but you never know at the time what would have value in the future and what is just junk.
My first exposure to "real" computers was with Victor machines. I may well have one in a pile somewhere still. I worked for a shop that was a Victor dealer, they had the fabled "PC compatible floppy drive" in a machine there. Later I was one of the few people with a PC that could read Victor disks; Copy2PC card For Tha Win there.
They did "high memory" and iirc had slightly higher resolution text modes, which made them wonderful for spreadsheets.
When jumping in to suggest how this violated Wikipedia guidelines, note that this predates WP's current Policies and guidelines page (1, 2010) and the COPO essay describing core content policies (2, Nov. 2007).
The Five Pillars page has changed quite a bit since 2007.[3] My favorite change, and only slightly tangential to the topic, is replacing this from 2007:
> [[Wikipedia:Be bold|Be '''bold''' in editing, moving, and modifying articles]], because the joy of editing is that, although it should be aimed for, [[Wikipedia:Editing policy|perfection is not required]]. And do not worry about messing up. All prior versions of articles are kept, so there is no way that you can accidentally damage Wikipedia or irretrievably destroy content. But remember — whatever you write here will be preserved for posterity.
with this in the current policy:
> [[Wikipedia:Be bold|Be bold]], but not [[Wikipedia:Reckless|reckless]], in updating articles. And [[Wikipedia:Editing policy|do not agonize over making mistakes]]: they can be corrected easily because [[Help:Page history|(almost) every past version of each article is saved]].
An unintentionally accurate transition in how it felt to participate then and now, subtly excising any mentions of the joy of publicly but safely messing up and replacing them with assurances that you and your contributions can simply be erased from history if you make any mistakes.
The article was deleted because wikipedia is mostly run by a clique who uses rules to discourage anyone else from editing while being above those rules at the same time.
> Intel's 80386 processor was the first to include memory management hardware and thus be capable of running a full UNIX operating system
That's not correct. The 80286 had sufficient memory management hardware for full Unix. What it did not have was sufficient memory management hardware for reasonable demand paging, but it was fine for swapping systems.
AT&T USG has a port of System V Release 2 for 80286, for example. There was also Xenix, which has enough licensed code in it from AT&T that I'd count it as a Unix.
There was also System V Release 3 fro 80286, but I don't think that was ever released. When AT&T was developing SVR3 for their own 3B line of processors they wanted to also port it to Intel processors. They hired Interactive Systems Corporation (ISC) to do that, with the contract calling for porting to both 80286 and 80386.
I worked at ISC at the time and was on the 80286 port team. We did get it working, but where having problems getting the scheduler to behave reasonably under heavy load.
Somewhere in the middle of trying to figure out what the heck was going on with the scheduler, we and AT&T realized (1) 80386 was so much better than 80286 that a lot of 80286 Unix users would upgrade to 80386 systems, and (2) those that are happy with the 80286 Unix systems and not planning on leaving 80286 probably would not find upgrading from SVR2 to SVR3 to be worth the effort. It wasn't all that clear that there was much of a market for 80286 SVR3.
The 80286 port was then dropped. I was moved to work on the 80386 port and also to a newly formed team to add support for running 80286 SVR2 binaries on 80386 SVR3. That was a fun project. Kind of like Wine, but easier because (1) it was just going from SVR2 Unix to SVR3 Unix instead of Windows to Unix, and (2) we had full source code to SVR2 and SCR3 unlike the Wine developers who don't have Windows source.
How do you define "Full UNIX"? Technically, even the 8086 can run Unix (or at least Unix clones like Coherent or even Xenix), just sans protected mode.
The 80286 had sufficient memory management hardware for full Unix. What it did not have was sufficient memory management hardware for reasonable demand paging, but it was fine for swapping systems.
> That's not correct. The 80286 had sufficient memory management hardware for full Unix. What it did not have was sufficient memory management hardware for reasonable demand paging, but it was fine for swapping systems.
Oh my word. A correction for something I wrote, what, 18 years ago?
I hope you will forgive me if I don't go edit it. ;-) I barely remember writing it.
TBPH I think that the distinction between swapping and paging is a subtlety that is beyond even most Linux hackers these days. I take your point but it is a small terminological inexactitude IMHO... no?
In this context it is referring to a specific product called "Personal Computer" made by IBM.
Just like when someone says they bought a record on compact disc, they are referring to Red Book Compact Disc Digital Audio Standard. They're not referring to any other discs that are small.
Ha haaa! NO, I have a decent-sized 45 collection and there's no confusion about their awesomeness! Most of them sound better than the dynamically-compressed-to-shit streaming "remasters" of the same songs today.
I also have a few 3-inch CDs, which were supposed to be the successor to 45s but record companies just weren't down for seriously selling singles at that point.
Another historical curiosity: I have a couple of "video CDs," which were regular-sized (5-inch) CDs with a digital section containing the song (playable on any CD player) and then an analog video section with the video for the song (playable on later LaserDisc players).
> Another historical curiosity: I have a couple of "video CDs," which were regular-sized (5-inch) CDs with a digital section containing the song (playable on any CD player) and then an analog video section with the video for the song (playable on later LaserDisc players).
That is a "CD Video" or "CD+V", which supported up to 20 minutes of CD audio and around 5 minutes of LaserDisc-style analog video. There was also a variant that skipped the CD audio and was just LaserDisc video on a CD-size disc called "Video Single Disc".
"Video CD" or "VCD" was a later all digital format that used MPEG-1 compression while also disabling error correction for more data capacity to fit more or less the same amount of VHS-ish quality video on a given disc as it could support CD audio. VCD never even reached the level of success of LaserDisc in the US but most standalone DVD players could play them. I believe they were a lot more popular in parts of Asia.
Fair enough; I didn't go hunting around for my discs to check the order of "video" and "CD" in the moniker.
"Video-CD" was widely used in China long after DVDs came out, lasting almost until the HD era (when the Chinese attempted to introduce their own HD disc format that still used a red (insert "communist" wisecrack here) laser.
I always thought that those Chinese discs were CD-I, which failed miserably in... well, everywhere else. But in fact CD-I was a bastardization of Video CD that was incompatible, although it offered slightly higher (but still crappy) resolution. In the end, the format that prevailed all those years in the east was presumably Video-CD.
Oh yeah, I have a few examples of yet another obscure disc variation: the 8-inch LaserDisc. If I remember correctly, I have "I Want to Break Free" and "Radio Ga-Ga" by Queen, and "Salt in My Tears" by Martin Briley. The back sides of those are opaque white plastic.
> Fair enough; I didn't go hunting around for my discs to check the order of "video" and "CD" in the moniker.
Yeah, sorry, I forget how to people sometimes. Just a nerd who burned a LOT of VCDs back when DVD burners were expensive yet DVD players that read VCDs were cheap so it's one of those details buried in my brain that just came out.
A wild inclusion would be the IBM PCjr, which wasn't quite PC compatible. IBM didn't sell many, but Tandy sold a ton of PCjr clones, the Tandy 1000 et al.
Oh, good point. I didn't even think about embedded devices. The Cisco PIX firewalls were originally PCs w/ Intel motherboards (SE440BX, I believe) before becoming embedded x86 designs. I don't know how far the x86 legacy continued into the ASA and Firepower follow-up devices.
I seem to recall that USRobotics Total Control (dialup servers, ISDN PRI E1 (E1 for me in EU) / T1) to ~30ish dialup lines/ISDN BRI used x86 in the form of 80386ex (386 without real mode).
Whether it was 386ex or just a 386 is a bit hazy as it has been 25+ years since i last opened one up.
I think each line card that supported analog modems up to 4x 56kbit per card had one, along with some DSPs.
Also old Lucent WaveLAN (802.11 era, possibly even the non-standard predecessor) access points had a x86 processor sbc in them.
It's a horrible title. "PC" means personal computer. It may be a bit pedantic, sure, but if you're going to write an article that talks about technical things, it really smarts to read such a glaringly non-technical title.
Back in the old days, everyone understood what "[IBM] PC compatible" meant. PC meant something specific, not just a generic "personal computer", see https://en.wikipedia.org/wiki/IBM_PC_compatible.
To be honest I didn't live through that "even older days" era. I went straight from a Commodore 64 to a PC XT clone, and by then (the 80s) "PC" meant "IBM PC" to everyone I spoke to.
"PC compatible" was a common shorthand reference to "IBM PC compatible" which was referring to a specific architecture compatible with IBM PC software, and later, that platform's descendants. There were many personal computers at the time but colloquially, the IBM PC was the PC.
Prior to the IBM PC, a personal computer was called a "personal computer", not a "PC". I assumed that IBM came up with the "PC" name, but after a few minutes of research, it seems that IBM called their system the "IBM Personal Computer" in the original ads and documentation, rather than the "PC". As far as I can tell, PC Magazine created the name "PC". At first, the magazine referred to the IBM "PC" (with quotation marks around PC), which suggests that this wasn't standard usage. I'm a bit surprised by the idea that the "PC" name was invented by the magazine, and I'm not 100% sure of this, but maybe someone can confirm or deny. It wouldn't be the first time a magazine has created the terminology; "electronics" apparently comes from the magazine, not vice versa.
Intergraph[1] workstations based on the Fairchild Clipper CPU included a 80186 for booting into PC-DOS. At $30K in '80s dollars that might have made it the most expensive way to run DOS. But I think when booted into UNIX the 186 was used for I/O processing.
Another fun one: the original OLPC XO-1 (2007?) had an AMD Geode, but ran on Open Firmware and had ad-hoc controllers and drivers for things that would have gone through ACPI, etc. Microsoft claimed they had Windows XP booting on one, but I've yet to see how that would have worked.
One nice machine I remember is the Siemens PC-D series. They eventually became PC compatible, but the ones I used were running some sort of terminal software and a GUI called Collage connected to a SINIX (Siemens-branded Xenix, IIRC) machine.
There were lots of machines with 8086's as coprocessors - the Zenith Z-100 had one, and there was a board for Apple IIs that predated the Applied Engineering one (that was a PC on an Apple II card, with PC floppy ports).
123 comments
[ 1.6 ms ] story [ 162 ms ] threadAll the computers are a matter of historical record, for instance.
I think I wrote it in 2006 and it was deleted in 2007. The spur to write it was the release of the first Intel-based Macs, which was 2006.
> Aside from its low hardware specification, perhaps the biggest perceived "design flaw" of the IBM PC was the what is nowadays called Upper Memory Area [...]
IDK what the correct wikipedia response to that would be but probably citation required and NPOV. It could be made more neutral by rephrasing just to "The IBM PC architecture located I/O pages at the top of memory, limiting available RAM to 640 KiB. Alternatives such as the Victor located I/O pages at the start of memory allowing for 800-900 KiB of RAM". Let the reader come to the conclusion that they did this to try to improve the architecture, and don't assert that those architecture choices were qualitatively better, don't assert any opinions.
It just sounds like the author is pleading a bit for the reader to see that other alternatives made qualitatively better choices.
I have moved my blog to Dreamwidth and don't post on LJ any more, but I have a registered account and use uBlock Origin. I don't know what "that" means but to me it looks like an ordinary web page and does nothing clever or weird.
(I turned UBO off specially to test.)
True. I didn't know anything very solid about them at the time -- and not much now, TBPH.
NEC version of Alto: PC-100 https://en.wikipedia.org/wiki/NEC_PC-100
And their competitor FM-Towns https://en.wikipedia.org/wiki/FM_Towns
These are used x86 CPU.
The biggest difference between PC-98 and PC compatibles the DOS/Windows didn't hide that I remember, and that I remember being the biggest source of DOS/Windows programs failing even if they weren't doing low level calls was drive letter assignment.
On PC-98 A: was the drive you booted from. If your system had a floppy drive and a hard drive, and you booted from hard drive then A: would be your hard drive. B: would be your floppy.
In a PC-compatible A: would be the floppy and C: would be the hard disk regardless of which of the two you booted from.
Quite a few programs turned out to have "C: is the first hard drive" hard coded in.
I can't stand videos for getting info myself, but this is good info for others.
If only there were some kind of collaborative wiki-type site this could be group edited into something Wikipedia eligible. ;-)
https://en.wikipedia.org/wiki/Wikipedia:Five_pillars
Like how the Transmeta Crusoe was an x86-compatible CPU... but moreso.
The Crusoe was a thing marketed as a "CPU", that was actually internally an SoC (with the CPU inside it being non-x86.) This SoC had its own internal RAM and storage, and booted itself into internal software that then emulated an x86 CPU. All of the "CPU" data pins on the Crusoe SoC, routed to the virtual CPU inputs and outputs of this software. So, as far as other devices in the system were concerned, they were speaking to an x86 CPU.
Did anyone ever try taking this concept further? Maybe in the context of an industrial embedded computer?
I could imagine someone taking e.g. a modern ARM SoC with onboard RAM + eMMC; setting it up to boot into e.g. Bochs to emulate a virtual x86 (CPU + BIOS + other memory-mapped ROMs + platform controller hub + IO controllers + timer chips + TPM + etc — all the stuff on an x86 motherboard) — and then just setting up the SoC's GPIO pins to directly expose all the virtual buses of that virtual motherboard. You could then take such a chip, and design a physical "motherboard" for it to sit in, that's just a bunch of ports (e.g. PS2) and slots (e.g. ISA or maybe very slow PCI) routing directly to the SoC's GPIO pins.
This would be a very effective strategy, I think, for producing low-cost host platforms for the many industrial-automation ISA cards that still exist. So I have a feeling some OEM has at least tried to do this.
Probably there wouldn't be enough GPIO pins for most busses — x86 CPUs have tons of pins compared to almost any other architecture. So I wouldn't consider it cheating to feed parallel busses out serially at higher clock rates than those busses natively run at, and then to require the use of an external ser/des chip or two to flatten the signals back out. As long as it's the SoC itself speaking the protocol and the chip is "dumb", I think that'd still count.
Also keep in mind that unlike with the Crusoe, an "x86-on-ARM SoC" wouldn't need to have GPIO fast and wide enough to talk to external DRAM — as any memory could be internal to the SoC without breaking the contract. So the main constraint bottlenecking the Crusoe's CPU performance, wouldn't apply here. This thing could actually perform decently well — possibly well enough to run hard-realtime industrial control software coded in the 1990s, and to speak to ISA cards built in the 1990s. Which is all it would need to be able to do, for the obvious use-case.
The things Amigaheads will do to keep their old hardware running and useful in the current era are... kind of insane.
The Amiga equivalent for what I'm hypothesizing exists here, would be something that allows you to throw out the entire guts of your Amiga and replace it all with a freshly-printed PCB that has all the same ports/socket, but just one (modern, easy-to-source) chip on it, that internally emulates not only the 68000 but also all the other chips on the Amiga motherboard. And then anything you plugged into the original Amiga, would plug into this replacement board and work the same.
You want as much of that "motherboard logic" to be handled internal to the SoC as possible. Ideally, the board should only have the one SoC chip on it, plus jellybean parts and passives, plus ports and slots.
Also, let's lean on your example of video for a moment: "running an emulator full screen" isn't nearly the same thing as emulating the host busses — in that it results in the host describing that screen down its own SoC pins using something like HDMI. Whereas we don't even necessarily want a precomposed description of the screen on a signal line.
Remember, we're emulating the CPU and motherboard (and RAM, just because it's impractical not to) inside the SoC — but video support isn't actually an inherent part of an x86 motherboard. OEMs might integrate support for it onto a motherboard — but that "support" is just an embedded PCI-bus device, not some separate VGA bus.
Perhaps the system this board would revitalize, does something special with the communicated changes to the video data, such that pre-composed VGA (let alone HDMI) wouldn't solve the problem. For example, what if the system uses a custom PCI video card, that takes its VRAM and renders it out each frame, by compositing it together with another input video signal (ala the "video toasters" of the era)?
The only way to make that kind of thing work, is to emulate the PCI bus such that you can just plug the custom video card into one of the board's PCI sockets, and the emulated system will pick it up and use it.
Consider a "field-found" repair of an Amiga, like this one: https://www.youtube.com/watch?v=V-wNbku3CeI
In the instance above, the board was able to be revived — but only after swapping out a few chips with spares! Spares that need to be sourced!
But there are Amigas discovered in far worse internal condition. In those cases, the board itself is basically shot. Along with most of the chips. Often legs of DIPs are just corroded off, etc.
Having a single-SoC bus-compatible board, that you could use to entirely replace the internals of an Amiga, would mean that in that particular case, you could just shake the scraps of rust that the board has become out of the case, clean up the case and peripherals (which are likely still fine), and then build a "new" Amiga by putting that new SoC board in.
---
This is already a very common approach you'll see in e.g. the Gameboy modding scene — as so many gameboys are found as e-waste or in a ditch somewhere. Though the focus there isn't usually on decreasing parts cost with a one-SoC board, but rather getting perfect fidelity, since the target market is collectors who are willing to pay a high price and so a high BOM isn't as much a problem.
Also, amusingly enough, as there are people creating not just new bus-compaible GB/GBC/GBA boards, but also new custom buttons + shells, and even new non-IP-restricted BIOS ROM code, a "repaired gameboy" might actually contain no Nintendo-original components whatsoever. It's more a "generic" gameboy (by analogy to generic pharmaceuticals) at that point.
It does - it's just that none of the emulated things go through the motherboard to be emulated. There is an Apple II HDMI board that can output Apple IIgs graphics from a II+ because it watches the peripheral bus for the signals a 65816 would make to setup a IIgs screen. Lots of Apple II accelerators emulate a number of things on-board and only use the socket to push peripheral IO.
> then build a "new" Amiga by putting that new SoC board in.
I really like this idea. A lot of the experience of a retro machine is the physical device. I've been toying with the idea of making Atari ST and Amiga keyboards with USB ports just so that the emulators would "feel" more real.
I have a PC-122 keyboard and using it in combination with a 3270 emulator feels just right (even when the mainframe is running on an RPi)
THEC64 got a lot of love and goodwill from the retro community, just by having a breadbox case and a keyboard with real C64 layout and feel. It's still an emulator on an ARM computer, so it's not going to be cycle-accurate or even particularly low latency. But damn it, the feel of the thing is pretty close to booting and playing with a real C64 for 98% of the things you might do with it!
In the case of the TheC64 Maxi, there is no lack of internal space.
>According to Sun documentation the "... coprocessor card is not just PC-compatible, it is an actual PC that is constructed from real PC components and follows the de facto and emerging PC hardware design standards."
https://en.wikipedia.org/wiki/SunPCi
The Integrated File Server, then Integrated Xseries Adapter
A card with a mini X86 Server inside, running Netware, OS/2 or Windows NT, that could use the AS/400's storage and peripherals.
https://try-as400.pocnet.net/wiki/The_Integrated_PC_Servers
https://fredrik.hubbe.net/x2vnc.html
Other architectures that came into existence more recently — ARM mainly, but possibly RISC-V is going this way as well — are mainly employed to produce integrated devices in a more supply-chain-oriented way, with vendors producing and licensing designs for "IP cores", and then device integrators combining these "IP cores" to fab SoCs.
Conway's Law (and game theory) predict that such an arrangement would have no need for API standards. It's pretty hard to force an ecosystem to do something, when they have no natural incentive to do it.
You don't need an ecosystem to do it, you only need one manufacturer, because the competing ecosystem already exists.
Suppose someone produced an ARM or RISC-V system board in an ATX form factor with BIOS or UEFI and standard PCIe and memory slots etc. That's all you need -- then you use the same chassis, power supply, memory, expansion cards, etc. as any commodity PC without having to establish a new ecosystem for any of those things.
"Adhering to x86 standards", would imply that the software of such a device, must be able to do unified management of hardware components — both external and internal — through x86 facilities like ACPI. As, even if you've got a system built out of (some) x86-compatible components, if you can't make use of software — like drivers and OS subsystems — designed to assume the x86 system architecture on it, then what's the point?
So, for example, the SoC's GPU IP-core.
Until about eight years ago, SoC-internal GPUs were just something directly memory- and IO-mapped at addresses hardcoded into proprietary device-specific drivers given by the IO-core developer to be (arbitrarily modified and then) compiled by the integrator. And even today, with DeviceTree, the DeviceTree descriptor for each of these devices is still something handed over out-of-band along with the core, and burned into the device's NVRAM or OS base-image by the integrator.
But now, in getting that same GPU to support "the x86 system-level architecture", the GPU would instead have to be "registered" somewhere inside the SoC in order for the SoC CPU to probe and discover it as a PCIe device — with an ACPI DDST available within a UEFI-discoverble boot-ROM address mapping, that can be used to power-manage it correctly (including complex things like the CPU being able to put the GPU or its individual cores into particular sleep-states through ACPI); with a PCIe HW device ID, that binds it to generic drivers when available, rather than allowing for device-specific driver customization; etc. And all of the ensuing device initialization that the driver does, would have to occur through ACPI and PCIe. Even though the core is internal to the SoC!
Support for complex ACPI hooks, and a driver impl that's flexible enough to be runitme-configured to serve various devices' needs without integration-time customization (so that it can be upstreamed into OSes), are both things that the IP-core vendor would have to implement. Currently, they are not implementing those things — and mostly wouldn't even know how. Being an IP core vendor — where you're running a job-shop producing designs to spec for specific downstream integration projects — isn't at-all the same job as being a peripheral card vendor in an ecosystem, where you actually have to deal with all these concerns. The IP-core vendors would have to learn how to do these things.
And if you don't do this — don't require this kind of software-visible x86-platform-ization for the internal IP-core hardware — then what you end up with is a hybrid system that needs its OS to manage both external PCie ACPI devices with generic drivers, and internal DeviceTree devices with device-specific drivers — potentially also virtualizing one as the other whenever needed (by e.g. making up PCIe device IDs for the DeviceTree devices). And not even Linux knows how to deal with that[0].
[0] If you're curious — https://docs.kernel.org/arch/arm64/arm-acpi.html#booting-usi.... As stated, ARM BSA/BBR devices are expected and required to use solely ACPI-registered device descriptions; such systems don't use DeviceTree at all. This severely restricts ARM SBA/BBR OEMs' choices of IP-core vendors, as those vendors, mostly know nothing about how to produce cores compliant with ACPI, nor drivers generic enough to be signed, sealed, and used in ACPI environments — let alone upstreamed. This is what I mean by "an ecosystem problem"! And it&#x...
That's assuming you're trying to mix and match ecosystems and put the GPU in the ARM SoC. But if the thing supports generic PCIe cards, you don't inherently need an iGPU, you can put a Radeon or GeForce in a PCIe slot, or use any of the smaller GPUs from the x86 ecosystem as you might find on a server system board.
Moreover, the assumption is that the company doing it is one of the ones making chips for phones rather than e.g. Nvidia or AMD. Nvidia already has the expertise to deal with ACPI and PCIe from making PC GPUs. AMD has more than that, they could pair ARM or RISC-V cores with their existing Radeon iGPUs and slot it into their existing CPU sockets, potentially with as little as a firmware update for existing system boards.
You mean, like the Milk-V Oasis[0]?
Full disclosure: TBA this summer, so not yet available.
0. https://community.milkv.io/t/introducing-the-milk-v-oasis-wi...
Separately, I will grant that drivers are their own sticking point, but I would like for them to be approximately the only sticking point. And even on x86 drivers are a problem; Linux generally has good mainline coverage of most networking cards, even wifi is good these days, but fingerprint readers have always been hit-or-miss. I just wish we could get to the point where once the drivers are upstreamed everything does Just Work and we can be free of "well this distro has a Raspberry Pi image but if you want to try an Orange Pi you need to find an OS that supports that exact board..."
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) 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 <...
Not long afterwards, hardware made MS-DOS compatibility much better because the speed of MS-DOS could easily be as fast as or faster than real IBM hardware. There were many options including the Sidecar, BridgeBoards, KCS PowerPC, and more on Amigas. Later, there were DOS compatibility cards for Macs.
Often these options had advantages over having a separate DOS compatible computer, like the ability to still run the native system at the same time, and often to share files / drives and other resources. It was an interesting time, for sure.
> Did anyone ever try taking this concept further?
Well, yes, they did, but not on x86.
ISTM, from your later responses, that you have not fully defined what your idea is.
So the answer, based on what you said later, is both "yes" and "no."
No, it has not been done on x86. It is not likely to: x86 is still comfortably as fast as just about anything else out there, so there is no candidate host.
Crusoe chips did not do x86 emulation for performance reasons. They did it for power consumption reasons. They could run x86 code reasonably fast, but on much less electricity while producing much less heat.
They sold. I tried one. It was good. Benchmarks are very misleading and so are most of the comments here: its performance was pretty good on second and subsequent runs of whatever the test was, as the first run was used for performance profiling and generation of code for the emulator.
Result: first run slow, second run much faster, entirely separate from any disk caching.
But it drew Intel's attention and Intel responded by making much more power-efficient CPUs.
However, what you are asking, emulating x86 for performance -- that isn't going to happen. Even Apple Silicon Macs aren't that quick... not yet.
Entire new motherboards that emulate the original CPU? Sure. There are lots.
Here's an example: https://en.wikipedia.org/wiki/ZX_Spectrum_Next
Here's a plug-compatible new computer compatible with an Amiga: http://www.apollo-computer.com/v4standalone.php
Here's one compatible with a Sinclair QL, called the Q68: https://www.qlforum.co.uk/viewtopic.php?f=2&t=2203
I think the PiStorm counts too, but it does need a working host motherboard.
But yes, it has been done, but not for x86 and won't be.
This is IMHO a likely scenario as AMD tries to stay competitive while the world moves away from legacy x86 to a new ISA.
They did "high memory" and iirc had slightly higher resolution text modes, which made them wonderful for spreadsheets.
http://www.oldcomputers.net/victor9000.html
The Five Pillars page has changed quite a bit since 2007.[3] My favorite change, and only slightly tangential to the topic, is replacing this from 2007:
> [[Wikipedia:Be bold|Be '''bold''' in editing, moving, and modifying articles]], because the joy of editing is that, although it should be aimed for, [[Wikipedia:Editing policy|perfection is not required]]. And do not worry about messing up. All prior versions of articles are kept, so there is no way that you can accidentally damage Wikipedia or irretrievably destroy content. But remember — whatever you write here will be preserved for posterity.
with this in the current policy:
> [[Wikipedia:Be bold|Be bold]], but not [[Wikipedia:Reckless|reckless]], in updating articles. And [[Wikipedia:Editing policy|do not agonize over making mistakes]]: they can be corrected easily because [[Help:Page history|(almost) every past version of each article is saved]].
An unintentionally accurate transition in how it felt to participate then and now, subtly excising any mentions of the joy of publicly but safely messing up and replacing them with assurances that you and your contributions can simply be erased from history if you make any mistakes.
1: https://en.wikipedia.org/w/index.php?title=Wikipedia:Policie...
2: https://en.wikipedia.org/w/index.php?title=Wikipedia:Core_co...
3: https://en.wikipedia.org/w/index.php?title=Wikipedia:Five_pi...
That's not correct. The 80286 had sufficient memory management hardware for full Unix. What it did not have was sufficient memory management hardware for reasonable demand paging, but it was fine for swapping systems.
AT&T USG has a port of System V Release 2 for 80286, for example. There was also Xenix, which has enough licensed code in it from AT&T that I'd count it as a Unix.
There was also System V Release 3 fro 80286, but I don't think that was ever released. When AT&T was developing SVR3 for their own 3B line of processors they wanted to also port it to Intel processors. They hired Interactive Systems Corporation (ISC) to do that, with the contract calling for porting to both 80286 and 80386.
I worked at ISC at the time and was on the 80286 port team. We did get it working, but where having problems getting the scheduler to behave reasonably under heavy load.
Somewhere in the middle of trying to figure out what the heck was going on with the scheduler, we and AT&T realized (1) 80386 was so much better than 80286 that a lot of 80286 Unix users would upgrade to 80386 systems, and (2) those that are happy with the 80286 Unix systems and not planning on leaving 80286 probably would not find upgrading from SVR2 to SVR3 to be worth the effort. It wasn't all that clear that there was much of a market for 80286 SVR3.
The 80286 port was then dropped. I was moved to work on the 80386 port and also to a newly formed team to add support for running 80286 SVR2 binaries on 80386 SVR3. That was a fun project. Kind of like Wine, but easier because (1) it was just going from SVR2 Unix to SVR3 Unix instead of Windows to Unix, and (2) we had full source code to SVR2 and SCR3 unlike the Wine developers who don't have Windows source.
Wasn’t 16-bit OS/2 demand paged on the 286?
https://apricot-archive.co.uk/xen
I distinctly remember that massive (and heavy) power supply!
Oh my word. A correction for something I wrote, what, 18 years ago?
I hope you will forgive me if I don't go edit it. ;-) I barely remember writing it.
TBPH I think that the distinction between swapping and paging is a subtlety that is beyond even most Linux hackers these days. I take your point but it is a small terminological inexactitude IMHO... no?
Just like when someone says they bought a record on compact disc, they are referring to Red Book Compact Disc Digital Audio Standard. They're not referring to any other discs that are small.
... Or maybe they were talking about a 45? :)
I also have a few 3-inch CDs, which were supposed to be the successor to 45s but record companies just weren't down for seriously selling singles at that point.
Another historical curiosity: I have a couple of "video CDs," which were regular-sized (5-inch) CDs with a digital section containing the song (playable on any CD player) and then an analog video section with the video for the song (playable on later LaserDisc players).
That is a "CD Video" or "CD+V", which supported up to 20 minutes of CD audio and around 5 minutes of LaserDisc-style analog video. There was also a variant that skipped the CD audio and was just LaserDisc video on a CD-size disc called "Video Single Disc".
"Video CD" or "VCD" was a later all digital format that used MPEG-1 compression while also disabling error correction for more data capacity to fit more or less the same amount of VHS-ish quality video on a given disc as it could support CD audio. VCD never even reached the level of success of LaserDisc in the US but most standalone DVD players could play them. I believe they were a lot more popular in parts of Asia.
"Video-CD" was widely used in China long after DVDs came out, lasting almost until the HD era (when the Chinese attempted to introduce their own HD disc format that still used a red (insert "communist" wisecrack here) laser.
I always thought that those Chinese discs were CD-I, which failed miserably in... well, everywhere else. But in fact CD-I was a bastardization of Video CD that was incompatible, although it offered slightly higher (but still crappy) resolution. In the end, the format that prevailed all those years in the east was presumably Video-CD.
Oh yeah, I have a few examples of yet another obscure disc variation: the 8-inch LaserDisc. If I remember correctly, I have "I Want to Break Free" and "Radio Ga-Ga" by Queen, and "Salt in My Tears" by Martin Briley. The back sides of those are opaque white plastic.
Yeah, sorry, I forget how to people sometimes. Just a nerd who burned a LOT of VCDs back when DVD burners were expensive yet DVD players that read VCDs were cheap so it's one of those details buried in my brain that just came out.
Makes me wish I had one back in the day. My first PC was an XT clone, and I never owned a Tandy.
I'm sure IBM was real happy about that.
https://en.wikipedia.org/wiki/Convergent_Technologies_Operat...
Whether it was 386ex or just a 386 is a bit hazy as it has been 25+ years since i last opened one up.
I think each line card that supported analog modems up to 4x 56kbit per card had one, along with some DSPs.
Also old Lucent WaveLAN (802.11 era, possibly even the non-standard predecessor) access points had a x86 processor sbc in them.
Back in the old days, everyone understood what "[IBM] PC compatible" meant. PC meant something specific, not just a generic "personal computer", see https://en.wikipedia.org/wiki/IBM_PC_compatible.
For example - Seibu SPI https://github.com/mamedev/mame/blob/master/src/mame/seibu/s...
https://en.m.wikipedia.org/wiki/RM_Nimbus
The Wikipedia article on the 80186 lists a bunch of forgotten, often not PC-compatible, machines using that CPU:
https://en.m.wikipedia.org/wiki/Intel_80186
[1] https://www.shapr3d.com/history-of-cad/intergraph
And the BBC Master 512, of course...
(very popular in British schools in the 80s and 90s and ran a lot of DOS apps)
Glad to see Sirius Victor on there. They were very popular in the UK before IBM ate their lunch.
There were lots of machines with 8086's as coprocessors - the Zenith Z-100 had one, and there was a board for Apple IIs that predated the Applied Engineering one (that was a PC on an Apple II card, with PC floppy ports).