Like this one?

Sun had a whole range of SunPC (SBus) and SunPCI (PCI) x86 add-in cards that let you run what amounted to a PC in a Solaris window. The earlier SBus cards shared a lot more resources with the host system than the later PCI cards, which had their own RAM, VGA and other I/O, and basically only shared HDD with Solaris - they were really complete SBC cards connected to the host system by a PCI bridge. Advantage of the SBus versions was greater integration, but at the expense of performance (everything other than cache went over SBus and had to timeshare with the SPARC) and some compatibility - although both Win3.1 and Win95 were supported and most DOS stuff ran. The PCI versions were huge and expensive but ran at native speed with native x86 hardware, so only HDD access was shared. Irritatingly, Solaris support for these beasts is very narrow - a particular card can usually only run with one or two Solaris versions. I recall being able to hack a SunPCI with K6-2 on it that was only supported on Solaris 7 and 8 to run on Solaris 9 by manually renaming files, but you really should match card to desired Solaris version.

This card is the last SBus SunPC, with an AMD 5x86 and 256kB of L2 cache. I've been intending to get it up and running in my SparcStation 20 for some time now, but I've not been able to get the OpenBoot to boot from any Solaris 2.5 or 2.6 image I've been able to burn to CD. Complicating factor is that I don't have a known-good CD drive that can handle the 512kB block mode for these SPARCs so that might be the problem. Eventually I gave up and started building a netboot environment for it on my server, but other priorities intervened. Maybe this long weekend I might find time again to finish that... 😀

There were PC compatibility cards for pre-x86 Macintoshes.

dionb wrote:

Like this one? […]
Show full quote

Like this one?

Cool. It'd be nice to see some pics of systems like that.

Grzyb wrote:

There were PC compatibility cards for pre-x86 Macintoshes.

It'd be nice to see some systems up and running.

Caluser2000 wrote:

[...]

Cool. It'd be nice to see some pics of systems like that.

If I get it running I'll post here 😀

Had the opportunity to get a couple of Sun systems but the guy selling them did a runner with my money. Couldn't be found. Next big thing was Acorn Risc systems. Always wanted a RiscPC when they were new. Didn't cost much more than a 486 at the time. Kinda went silly and now I have a stack of them as well as Acorn A4000s. Have five RiscPCs that cost less than my original 286/16 cost new 🤣. Never interested in Macs at all. I could have a Gui(GeoWorks) on my 286 AND colour.

there is a whole big thread on vcfed about non x86 computers with x86 addons. you should check it out.

Yeah I started it http://www.vcfed.org/forum/showthread.php?462 … 86-add-on-cards

Cool! I remember a slightly older thread from here called "PC compatibility cards", too. 😀

The main two that come to mind for me is the Amigas with bridge boards and Acorn RiscPCs which a dedicated slot for x86 co-processor cards.

The Acorn BBC Master 128 also had an x86 add-on, making it the Master 512. The kit consisted of an 80186 board and DOS Plus/GEM.

Grzyb wrote:

There were PC compatibility cards for pre-x86 Macintoshes.

And before PC cards there was MacCharlie - addon for running DOS software on early Macintoshes which was connected akin to Amiga Sidecar.

I suppose the irony of it all is that there were many superior computer systems, that tried to gain marketshare by offering DOS compatibility (from very early on, I might add, as many of these solutions date from the mid-80s), hoping to eventually make DOS obsolete and become the leading hardware platform.
While in the end, it's the x86-machines that made everyone else obsolete.

There's the PC Transporter for the Apple IIgs, too.

One of my RiscpC systems running GeoWorks Pro v1.2:

Scali wrote:

I suppose the irony of it all is that there were many superior computer systems, that tried to gain marketshare by offering DOS compatibility
(from very early on, I might add, as many of these solutions date from the mid-80s), hoping to eventually make DOS obsolete and become the leading hardware platform.
While in the end, it's the x86-machines that made everyone else obsolete.

Yup. I believe that at some point of view, DOS kind of was legitimated to take over the professional/industrial fields, though. It was the spiritual sucessor of CP/M, after all.
If some developers didn't focus on IBM so much, in particular on the IBM PC, then maybe DOS would have had become more of a vendor and platform independant OS.
There are some hints that this was amiong Microsoft's original intentions. From reserving the rights to sell DOS on its own to the other customers to the
fact that MS provided source code for PC makers of MS-DOS up to version ~3.0. Early x86 PCs were describing themselves as "DOS compatible", also.
PCs like the Victor 9000/Sirius 1, BBC Master 512 or Sanyo MBC-555 never wanted to be copycats of the IBM PC, originally.

I imagine PC manufactureres initially still believed that the personal computing world would continue the tradition of which merely the OS core
(BIOS in case of CP/M) would have had to be adapted and user software would continue to rely on API (ABI) calls (more or less).
Unfortunately, the times had changed from the old CP/M days and it was nolonger pratice to adapt an OS to the individual PC, but rather to clone a reference hardware.
By contrast, in the 1970s, it wasn't uncommon to select the terminal device (ANSI, VT100) inside the application.

Edit: Who knows, if things went differently, maybe DOS would have gotten a simple graphics API, even.
Like CP/M Plus or MP/M later got with the GSX system.. Who knows ? 😀

Jo22 wrote:

[...]Yup. I believe that at some point of view, DOS kind of was legitimated to take over the professional/industrial fields, though. It was the spiritual sucessor of CP/M, after all.

More like a quick & dirty rip-off. Even in its later incarnations it was less mature than CP/M. It just did sort of the same job, sort of well enough.

If some developers didn't focus on IBM so much, in particular on the IBM PC, then maybe DOS would have had become more of a vend […]
Show full quote

If some developers didn't focus on IBM so much, in particular on the IBM PC, then maybe DOS would have had become more of a vendor and platform independant OS.
There are some hints that this was amiong Microsoft's original intentions. From reserving the rights to sell DOS on its own to the other customers to the
fact that MS provided source code for PC makers of MS-DOS up to version ~3.0. Early x86 PCs were describing themselves as "DOS compatible", also.
PCs like the Victor 9000/Sirius 1, BBC Master 512 or Sanyo MBC-555 never wanted to be copycats of the IBM PC, originally.

Thing is, DOS could never have become platform-independent because it didn't do any hardware abstraction whatsoever. All applications had to talk directly to hardware, or go via BIOS routines, which were part of the platform, not the operating system. Consequence is that yes, you could theoretically have the exact same user interface on other platforms as you did under x86, but all application code would have to be specifically written for/ported to the other platforms, meaning you wouldn't gain any advantage in portability. Even with considerable modification and more abstraction that would still apply - take a look at Window NT - it was ported to both MIPS and Alpha platforms, but binaries were not portable, which was one of the main reasons the ports flopped. Having a Windows desktop was interesting, but with no software there was no compelling reason to run it. Even today with Windows 10 Arm vs x86 apps aren't interchangeable.

You can only achieve that with completely virtual environments like Java, which is miles away from what DOS was.

I imagine PC manufactureres initially still believed that the personal computing world would continue the tradition of which mer […]
Show full quote

I imagine PC manufactureres initially still believed that the personal computing world would continue the tradition of which merely the OS core
(BIOS in case of CP/M) would have had to be adapted and user software would continue to rely on API (ABI) calls (more or less).
Unfortunately, the times had changed from the old CP/M days and it was nolonger pratice to adapt an OS to the individual PC, but rather to clone a reference hardware.
By contrast, in the 1970s, it wasn't uncommon to select the terminal device (ANSI, VT100) inside the application.

As late as 1995 it was perfectly normal to select the sound hardware from within the game running under DOS.

Thing is, this is just about selecting whatever hangs on the end of an I/O port. You can't do the same for the guts of a machine. 68000 is a totally different architecture to x86, software couldn't run to the point of being able to select it. They even read their bytes the other way round... even within a given CPU the system architecture is unique and limiting. A PC binary cannot run unmodified in native Sun/386 for example, not even far enough to choose which one to use. And even assuming someone could do just that, a developer would essentially have to develop two completely different applications that get called after that switch.

Edit: Who knows, if things went differently, maybe DOS would have gotten a simple graphics API, even.
Like CP/M Plus or MP/M later got with the GSX system.. Who knows ? 😀

I believe it did. We called it "Windows" or rather "DirectDraw" 😉

dionb wrote:

Thing is, DOS could never have become platform-independent because it didn't do any hardware abstraction whatsoever. All applications had to talk directly to hardware, or go via BIOS routines, which were part of the platform, not the operating system.

I beg to differ.
It was *never* the intent of DOS to let the applications talk directly to the hardware. You had the BIOS for low-level access, which normally only DOS would need. And DOS provided all the necessary routines for disk and console I/O.

This meant that the BIOS and DOS APIs were standardized, and as long as applications stuck to using these APIs only, applications could be portable between systems (as long as they used an x86-compatible CPU obviously, since there was no abstraction of the CPU. But CP/M had the same limitation, except being tied to the Z80 CPU of course).

Early DOS came in OEM versions, where each OEM would provide their own low-level routines for their hardware. And the BIOS was also provided by the OEM, so as long as it supported the calls required by DOS, it didn't matter what hardware was used exactly, and it certainly did not have to be IBM-compatible. This would be exactly like how CP/M was used in practice.

Thing is, applications wanted to get the maximum performance, so they would bypass DOS and sometimes even the BIOS.
That's what broke the idea of DOS being hardware-independent.

There are some examples of early DOS PCs that are DOS-compatible, but make no attempt at being IBM-compatible. The Tandy 2000 is a good example, as is the Philips : YES.

It would have been cool to see the reverse, non-x86 add-on boards for x86 machines. Sadly we seem to use software emulation exclusively now.

Sun Blade 100 / UltraSparc IIe 500Mhz with SunCo ProcessorCard Penguin AMD K6-2 CPU 450Mhz 😀

Running Solaris along with Windows 2000 on the SunPCI Card

Scali wrote:

I beg to differ. It was *never* the intent of DOS to let the applications talk directly to the hardware. You had the BIOS for lo […]
Show full quote

I beg to differ.
It was *never* the intent of DOS to let the applications talk directly to the hardware. You had the BIOS for low-level access, which normally only DOS would need. And DOS provided all the necessary routines for disk and console I/O.

[...]

There are some examples of early DOS PCs that are DOS-compatible, but make no attempt at being IBM-compatible. The Tandy 2000 is a good example, as is the Philips : YES.

Indeed. But:

1) the BIOS *is* the platform; that's my Sun/386 example - it's a bog-standard 386 but with firmware unlike PC BIOS, so effectively a completely different beast even if the CPU could run the same code; the code would run, but would be meaningless with completely different architecture.
2) direct hardware calls were always part of the DOS concept - DOS + BIOS covered the bare minimum of I/O, anything over that had to talk straight to the hardware, and was facilitated in doing so by the original PC design.

However we don't need to nit-pick over whether or not direct hardware access was a fundamental part of the design, a necessary evil or just software developers being naughty. Once again, look at Windows NT, which was most definitely not designed to allow direct hardware calls. Even there, there was effectively zero code portability between platforms. Even if no DOS developer had ever written directly to a peripheral, it still wouldn't have mattered, code for PC would not have run on other platforms.