Non-PC compatible x86 computers (2007)
lproven.livejournal.com
lproven.livejournal.com
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."
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.
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's precisely why consumer SBCs — that include all the nice-to-have features like a GPU — aren't already SBR compliant!
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 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.
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.
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. ;-)
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.
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?
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:
And the BBC Master 512, of course...
They did "high memory" and iirc had slightly higher resolution text modes, which made them wonderful for spreadsheets.
For example - Seibu SPI https://github.com/mamedev/mame/blob/master/src/mame/seibu/s...
https://en.wikipedia.org/wiki/Convergent_Technologies_Operat...
But they had a special (even proprietary) floppy disk format. You couldn't format your own floppies. You couldn't even purchase any floppy brand. You had to order from DEC at $5 apiece, and you got a paltry 400K 5.25" floppy that you couldn't even format.
This was corrected later but then the damage was done and the Rainbow never took off.
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).
(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.
It didn't go well for IBM.
Kinda sorta, ish.
I loved the PS/2 range. I still own 2 of them, a top-spec Model 80 and a Model 55SX.
But they were PC compatibles. They ran DOS, Windows, OS/2, and NT 3.x no problem at all. They were highly compatible... just with a totally different expansion bus.
If one said that a modern PC with PCI-e slots was not compatible with a decade-old PC because the old box had PCI and the new one has no PCI only PCI Express, I think most people would unhesitatingly say that was wrong.
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.
All 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.
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...
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.