4 ms·

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 markete

by derefr 3y ago

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.

solardev 3y ago
Wouldn't it be simpler to do all this in software? What's the advantage of doing it in hardware like this?
- derefr 3y ago
  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.
lproven 3y ago
[Author/submitter here] > 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 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 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 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.
- snvzz 3y ago
  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.
bitwize 3y ago
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.
- derefr 3y ago
  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.
  - bitwize 3y ago
    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.
  - cjdell 3y ago
    Would that not just be something like a Raspberry Pi Compute Module running an emulator full screen and a custom IO breakout host board?
    - 3y ago
yjftsjthsd-h 3y ago
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.
- derefr 3y ago
  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.
  - AnthonyMouse 3y ago
    > 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.
helf 3y ago
[dead]
johnklos 3y ago
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.
Pxtl 3y ago
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.

by derefr 3y ago

solardev 3y ago

Wouldn't it be simpler to do all this in software? What's the advantage of doing it in hardware like this?

derefr 3y ago
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.

lproven 3y ago

[Author/submitter here] > 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 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 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 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.

snvzz 3y ago
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.

bitwize 3y ago

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.

derefr 3y ago
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.
- bitwize 3y ago
  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.
- cjdell 3y ago
  Would that not just be something like a Raspberry Pi Compute Module running an emulator full screen and a custom IO breakout host board?
  - 3y ago

yjftsjthsd-h 3y ago

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.

derefr 3y ago
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.
- AnthonyMouse 3y ago
  > 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.

helf 3y ago

[dead]

johnklos 3y ago

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.

Pxtl 3y ago

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.