Solbournes are truly the forgotten SPARCs: innovative systems that lived and, briefly, thrived during the early to mid 1990s before their demise and disappearance. Although they always lived in the shadow of Sun Microsystems, those of us who had the privilege of using them (I had access to a Series6 server during my undergraduate years, and many years later put together my own stable of IDT systems) found an impressive series of system designs offering all the advantages of SunOS in a much more capable hardware platform. Sadly, political considerations, technology gaffes and the inevitable cracks in management doomed the company to a footnote in the history of RISC workstations. This page aims to be that footnote.
I've also included an updated copy of Stephen Dowdy's Solbourne Shack, which was at one time the most authoritative resource on these machines and arguably still is. This page has disappeared from its original resting place and many of the files are scattered or missing from the Wayback Machine, but fortunately I had a local copy from long ago and was able to reconstruct most of it, and Stephen Dowdy himself was able to provide the rest of what was missing. Thanks, Stephen!!
Many thanks to Stephen Dowdy, Miod Vallat, Al Kossow (who got me lots of fun KBus boards to play with), Scott Manley, and several former Solbourne engineers and staff: Warner Losh, who knows all the right doors to knock on; Stan Hanks, who explained what happened to Solaris, Tom LaStrange, who gave me the scoop on the Solbourne window manager; Dan Julio, who provided neat insights and answered many silly hardware questions; and last but hardly least Dieter Dworkin Müller, who besides being the knower of virtually all things Solbourne got me started on my IDT addiction by providing an installation kernel I could netboot my first S4100 with many, many years ago. Last modified 18 January 2023.
|Are you getting rid of Solbourne equipment or peripherals? Please don't throw it away! E-mail me and let's see if we can give it a new home! Let me know your desired arrangements, and it goes without saying that I will gladly cover any shipping, time and inconvenience.|
To achieve profitability, Solbourne's overall focus was not (merely) cloning existing Sun-4 designs, but instead developing systems that were more powerful yet compatible. Their biggest innovation was bringing symmetric multiprocessing to the SPARC platform, beating even Sun themselves to the punch with the groundbreaking Series4, Series5 and Series6 multiprocessor systems. These systems used Solbourne's high-speed circuit-switched interconnect for multiple Sun MBus boards which they christened KBus, hitting up to 128MB/sec of bandwidth. Since SunOS did not yet support multiprocessing, Solbourne licensed the operating system and added SMP and support for its custom MMU directly to it, christening it OS/MP. To get this to function required the rest of the hardware to be compatible with SunOS, which turned out to be highly advantageous: the machines could run SunOS applications more efficiently than real Sun server hardware and users had to make little compromise to do so. The largest systems could run with as many as eight CPUs, which was a staggering number for the time.
The very first Series4 systems upon their launch in January 1989 were, ironically, based on Fujitsu CPUs; Solbourne did not yet have a working CPU of their own. Solbourne rapidly moved to Cypress processors and Weitek FPUs with the Series5 systems in October 1989 and the Series5E in July 1990. Matushita manufactured these systems at their factories overseas, and these early Sols were relatively successful in the high-performance market with substantially better price:performance ratios than competing Sun hardware. Solbourne shipped them in an array of configurations ranging from a oversized desktop all the way up to rackmounts and large server cabinets.
By this time, however, Matsushita wanted to capitalize on what they had originally funded MacGregor for: a CPU of their own to get them into the market too. MacGregor had big plans for this chip, a fully 64-bit implementation well over a year before the SPARC V8 specification would be finalized. As engineers worked on the design of what was irreverently christened the Kick-Ass Processor (KAP), a sea change occurred: Sun's introduction of the highly successful SPARCstation line in 1989 brought lower-end SPARC workstations to the desktop in large numbers, dramatically altering the scope and demands of the RISC workstation market. Solbourne did not want to be left out of this new market segment, and Matsushita was tired of waiting for a SPARC of their own, so the not-yet-finished KAP was demoted to 32-bit and pressed into service for the new IDT "pizzabox" SBus-based workstations. The pizzaboxes launched with the S4000, which by running the new KAP MN10501 CPU at 33MHz were able to just squeak by the SPARCstation 1+ upon introduction in October 1990. Lighter, smaller and simpler than the previous 500 series chassis, the combination of (barely) superior performance and a favourable price made the S4000 at least initially a modest success.
KAP, however, had serious scaling problems and a number of significant design flaws. It never made the 64-bit jump; the chip was notoriously bug-ridden, especially early mask versions, and required many workarounds in the kernel; and its integer and FPU performance were noticeably weaker than competing implementations. Although the KAP's integrated MMU has physical translation window bits for shared memory, which should have made multiprocessing possible, the uniprocessor implementation had too many issues to even consider it. More worrisome was that KAP could not reach 40MHz despite MacGregor's public promises: the chip was just not reliable at the faster speed and KAP hit a ceiling around 36MHz. Engineers pleaded with management to use another off-the-shelf CPU while KAP was treading water, but political considerations with Matsushita would not permit it. Although the 36MHz S4100 was able to improve KAP's performance with an external 256K L2 cache in 1991, it was too late to beat the 40MHz SPARCstation 2 which was already on the market. Solbourne's price advantage over the SPARCstations was not enough to overcome its performance deficiencies and the workstation line tanked after millions of dollars in sunk design costs.
In mid-1990, after dismal market performance, Doug MacGregor resigned and the entire workstation line was subsequently jettisoned. By now Solbourne represented 2.5% of the total SPARC market, dwarfed by Sun's 93.3% share. Solbourne turned back to the enterprise market with the Series6 machines in September 1992, adding special support to OS/MP to specifically favour Oracle database environments such as improved context-switching. The KAP was also cancelled and replaced with the Texas Instruments SuperSPARC, yielding substantially better performance on the high end. Despite the retooling, however, Solbourne was never able to recapture its lead in high performance innovation and Sun eventually surpassed its competitor in that market as well. The planned Series7 systems, which would have leapfrogged Sun with up to 20 CPUs, were never sold and only two CPU boards were ever made. Solbourne also lost customers who were unable to transition from the BSD-based SunOS OS/MP to compatibility with the new SVR4-based Solaris, effectively leaving the Solbourne's only operating system frozen in time. (Reportedly this was because Sun refused to offer Solaris licensing terms to any SPARC clone maker, least of all Solbourne, apparently due to Solbourne systems cornering the more profitable upper tier of the market.)
Facing mounting losses, the computer hardware business was shut down in 1994 and support moved to Grumman Systems Support Corporation, and Solbourne switched exclusively to Oracle consulting work (ironically the company that would later acquire Sun, their competitor). In 2008, this remaining portion was sold to Deloitte and the company ceased to exist as an independent entity. Grumman themselves ceased support on 1 January 2000, having served only as a clearinghouse for patches and repairs under contract, marking the final end of what was once an auspicious and innovative computer company's legacy.
In general, OS/MP is highly compatible with SunOS 4 and most applications will run unmodified. I use regular SunOS binaries on my Solbournes and even a later SunOS libc. See below about finding SunOS 4 software.
Bitsavers has the OS/MP patches and other useful things.
The concept was apparently part of Unisys' short-lived effort to move their product lines to SPARC, which ultimately never got off the ground either (modern Unisys systems are either custom CMOS ASICs or Xeon-based).
I am told a Solaris 2 port existed at one point for the IDT systems, but it was third-party and never released either.
(Note to pedants: although SunOS 4 was sold at least at some point as "Solaris 1," it IMHO ain't Solaris sensu stricto.)
The black and white cards (the monochrome KBus card and the SBus bw20) also have a 1600x1280 mode. This requires a monitor capable of a 89Hz horizontal frequency.
That said, I have been told by others who have tried that Sun SBus display cards won't work in the IDT systems either.
The S3000 has some interesting history. Matsushita wanted a smaller-footprint system for Japanese desks, so Solbourne took the S4000 board and mounted it vertically, and added the flat screen to the front. The screen can tilt and is very ergonomic, considering. Plus, it's also a lot lighter than an S4000 and a monitor!
The S3000 even came with a black nylon carrying case with pockets for the keyboard, mouse and optical mouse grid.
The author's S3000, upgraded with an S4100 KAP+L2, SCSI2SD and SBus RAM expander card, in OpenWindows (borrowed from SunOS 4).
PILOT has both Panasonic and Solbourne logos and was the closest thing that ever existed to a Solbourne laptop, as well as its only colour portable. Per Dieter (via Warner Losh), it was most likely a customized IDT logic board -- see below for more about the common S3000/S4000 board -- with a unique case, keyboard, dedicated "Rotational Hand Controller" and 15" colour LCD display, and was probably designed and fabricated by Matsushita's Federal Systems division under contract instead of at Solbourne Longmont. It was billed as 40MHz, but Warner thinks "this may have been aspirational" given all the troubles with KAP, and had "32M[B] RAM, 20M[B] disk space for PILOT" installed (here are some additional details from its architect). A floppy disk drive and green power switch are on the left and two circular ports, possibly serial, are on the right, but the rear of the unit can't be seen in any available photograph. A contrast control is to the right of the LCD.
PILOT first flew on STS-58 in October 1993, and thence on (at least) STS-61, -62, -63, and -65, making its final known recorded journey on STS-67 in March 1995. There were probably several PILOTs made but it doesn't seem like there were very many in existence. It is not exactly clear per Scott's research how many missions PILOTs flew and they may have been on more missions after that, but the system was eventually replaced by IBM ThinkPads running more conventional software and the ThinkPad line went on to have a long, rather better known tour of duty in orbit.
A similar portable unit called the Matsushita
P2100 was announced in 1992, also a 40MHz unit with 32MB of RAM. Although
its operating system was called "Pan-OS/S" [sic],
presumably standing for Panasonic, it was
stated to be "binary compatible with SPARC applications derived from Solaris
1.0" (my translation) which sounds an awful lot like OS/MP, though the
timing would have been rather
odd given the recent market failure of the IDT workstations. It is similarly
notable that Solaris 1.0 (i.e., SunOS 4) is mentioned, not Solaris 2.0, which
Sun refused to license. If this is the
same unit alluded to in this
1992 announcement, then it was designed in affiliation with Solbourne,
and may be either a repackaged
PILOT or a commercially oriented successor. However, no
one so far has ever seen a P2100 sold and no PILOTs are currently known to be
in collectors' hands.
The Sun-3 optical mouse (with the RJ-11 plug) can connect to the "Cherry" Solbourne 102691 keyboard and will work, but needs adjustment due to the lower resolution.
If you have the first revision, the only way to do this is a complete logic board swap. (You may also need to swap the ROMs back after; you should be running the most current ROMs you can get. The last version was 2.1.)
If you have the second revision, you have a choice. If you can stand the fact the CPU will still run at 33MHz, you can simply pull a KAP+L2 assembly from an S4100 and install it. It is designed to stand off somewhat from the CPU socket; it will not fully sink into it. To enable the motherboard support for the cache, there are three jumper blocks on the S4000/S4100 board, two near the KAP and one near the SBus slots. Move the jumpers to the cache position and you're done. No changes to OS/MP are required. If you want the full 36MHz, however, you will either have to swap the logic board or desolder and swap the crystals. This oscillator is located near the KAP socket.
Because the CPU pins are longer than the CPU socket, the KAP+L2 assembly will stick out. This isn't a big deal on the S4000 since it's flat, but I found it technically disgusting on the S3000 where it's vertical and I was worried the pins would bend over time, so I fashioned some small plastic shims on the bottom to brace it against the SIMM slots below it.
Is this worth doing? At least for the S3000, hell yes. Even at 33MHz, my second revision S3000 jumped from a Dhrystone VAX-MIPS of 14.6 to 22.3, a jump of 53 percent. For an S4000 this is less clear because the S4000 and the S4100 have the same form factor, so if your only source is a working S4100 you might as well just use the S4100 since it's 36MHz to boot and otherwise the same. On the other hand, if you have a busted S4100 with a working CPU and a working S4000 to accept it, then swap it now!
For the IDT machines, 8MB of RAM is invariably present on the board in pre-installed SIPPs (a few may have 32MB here instead). Unless you have a really mangled system, that memory is always available. Additional RAM can be installed onboard using the 8 SIMM slots with 100ns or faster 30-pin ECC SIMMs. The SIMMs must be the same type; you cannot mix them. The maximum amount of onboard memory is 40MB, no matter how much you have in SIPPs, so assuming you have the most typical 8MB configuration and you put 8 4MB 30-pin SIMMs in, you are maxxed out. (Allegedly S4100 systems with 32MB in SIPPs can take 32MB in the SIMM banks as well for a total of 64MB in the base configuration. I have never seen such a system, and none of my S4100s are set up like that.)
A very hard-to-find SBus expander card allows an additional 64MB of RAM for a total of 104MB, using the same SIMM spec. My "S3000DX" has one of these cards now (from Stephen's old workstation, thank you!), which has 16 SIMM slots that can be filled with either all 1MB or all 4MB sticks. Mine has 16 1MB sticks, so it has 16MB of RAM, giving my system 56MB. Note the screws on the left highlighted in red. It is strongly advised you remove the screws in the standoffs before trying to insert the card; you'll need the screws to maintain the mating with the connectors on the motherboard. You may need to temporarily remove the floppy drive as well since the bottom edge of the card slots into a shelf under the floppy drive and it's hard to manoeuvre it into position with the floppy still in place. The S3000 card depicted here is skinnier than the card for the S4000/S4100 due to the restrictions of the form factor even though they are electrically compatible.
The SIPPs can go bad just like any other type of RAM. If that happens, usually the easiest way to deal with it is simply to remove them (which can be a real pain if they are soldered in, which may be the case in early IDT machines). Since SIPPs are the same as SIMMs minus the card edge, there is the potential for soldering in SIMM slots there too, but I'm not that crazy.
If that doesn't work, odds are very good it's the hard disk. Pretty much all of the Solbournes I've used had ticking timebombs for root disks that eventually crap out and won't start. Assuming the device has a Unix File System volume on it, you can try to get a directory listing from the PROM monitor with ls sd.si() (if you think the drive is on another SCSI ID or LUN, add it: ls sd.si(,1,) accesses controller 0, ID 1, LUN 0). If that doesn't work, assume it's toast or some incompatible non-bootable format. You can replace it with another compatible disk, but these days a better solution is a SCSI2SD. See below.
If you want to fool around with it and see how far you get from the PROM monitor, there are other settings and commands you can mess with.
If you can't even get that far, here are POST codes for the IDT systems.
ROM> boot sd.si(,6,)Install.S4000
Series5/5E and Series6/6E machines should use Series5 and Series6 for XXXX respectively. The Series4 cannot boot from CD-ROM.
Parenthetically, the OS/MP CD-ROM is not an ISO 9660 filesystem and the Solbourne cannot boot from one. It is, in fact, a SunOS Unix File System volume, which in /etc/fstab is called 4.2 (after BSD 4.2's Fast File System, which of course it is). Do not burn an ISO 9660 filesystem to a CD and expect the PROM monitor to boot from it, even though you can mount such a CD when OS/MP is booted.
Booting from the network is a little trickier since the Solbourne PROM monitor only speaks RARP (not even BOOTP, let alone DHCP) and TFTP. Set up a server with rarpd to give your Sol an address and tftpd to offer a bootable kernel (the same machine must be running both services); I have a NetBSD Macintosh IIci configured specifically for this purpose. Then, substituting Install.XXXX for whatever the name of your kernel is, you should simply be able to do this:
ROM> boot tftp.ei()Install.XXXX rarp: using IP address 10.0.0.4 = A0000004 rarp: server at IP address 10.0.0.2 = A0000002 Boot: tftp.ei() ...
If you really do have a tape and want to boot from that, the boot command is slightly different: boot st.si(,5,)Install.XXXX
The reason I've been using install kernels here is that you can then
mount the filesystem after the kernel boots. If you're not going to
install the OS, all you need is the kernel itself to get in to what's
I can't set the clock to the year 20xx.
The built-in date command in SunOS 4.1 and OS/MP is not Y2K
compliant. Sun issued a later patch for this, but Solbourne never
did so. Fortunately, the gettimeofday(3) call can help, so you can
compile a tiny tool to get you to the right year, and go from there.
Alternatively, you can use ntpdate -s once you install NTP (which is probably a good idea if you have a local time server).
Alternatively, if that's too much work, here's a Perl script I use that gets an RFC 868-compliant time value from a local server (replace oslo with yours) and compiles a once-off tiny tool like the above to set the clock. This technically has a race condition between getting the time value and the actual execution of the compiled setter, but it's good enough to get you in the ballpark. (You can get Perl 5.003 from the linked archive below.) I have this script in /etc/rc.local to refresh the time in case the battery dies.
Do note that the time is a signed 32-bit integer on systems this
old, so in the
year 2525, if any Solbournes are still alive (after 2038), you'll have to
pick some other reference year, or rebuild libc, or ...
How do I get OS/MP networked? (Dude, what's up with DNS?)
(Dude, do I have to run YP/NIS?)
This is really a SunOS 4 question and not an OS/MP-specific question, but
here is a partial answer.
An obvious caveat: SunOS 4 has multiple remotely-exploitable
vulnerabilities. If you must connect it to a network,
an OS/MP host should always be behind a very, very,
very, very restrictive firewall.
If you are looking for a more complete answer to this question, I strongly
suggest consulting an older system administration text with a section on
There are a number of ways to skin this cat. The "proper" method is to populate all the various configuration files and let the OS discover its address and netmask from them (here is one way; here is another). This is the process that the OS/MP post-installation tool does for you.
The "improper" method is to edit /etc/rc.local and simply put in an ifconfig line with your address and netmask in the appropriate place before starting network services. Typically your interface is enumerated during the dmesg (on an IDT system, for example, it is invariably ei0 unless you have some other SBus Ethernet card you want to use). I'm incredibly lazy, so I use the "improper" method on systems I'm not rebuilding from scratch. Here is an "improper" method that has a bit more detail.
Note that you cannot (at least not without a lot of changes) make SunOS 4 work as a DHCP client; you need to give it a static IP address.
Unless your SBus or KBus card provides a regular 10BaseT ("RJ-45 style") jack, you will need an AUI transceiver to connect it to a modern Ethernet network, and some switches with autonegotiation may freak out. Interposing a 10Mbit hub between the Solbourne and your switch will usually solve the problem.
SunOS 4 has two ways of handling DNS, mostly because SunOS 4 really, really, really wants to be connected to a YP/NIS server. The hard way is to install and replace various system libraries (and/or relink the executables that statically link against them) so that YP/NIS isn't used. The easy way is just to turn your host into a YP server for itself that forwards queries on to DNS. Again, I'm lazy, so I went with the easy way. Here is how I did it, but there are other ways:
domainname floodgap.com ; domainname > /etc/defaultdomain
You should have a DNS server around for your OS/MP machine to talk to that still supports IQUERY (for example, BIND 8 with options fake-iquery; in named.conf, or BIND 4), or reverse DNS queries will fail. If you need to run a BIND 4 or 8 server for this purpose, remember that these old versions of BIND have many well-known vulnerabilities, and you shouldn't let anything else talk to it.
With clever juggling of PATH and LD_LIBRARY_PATH you can actually have all three installed and move from one to the other on the same machine. I'll leave this as an exercise to the reader.
Solbourne did develop their own X server and window manager called
(drumroll) the Solbourne window manager, or swm. This was a
separate product from OS/MP. Tom
LaStrange, earlier the author of twm in 1987
(Tom's window manager, later
the Tab Window Manager), developed it at Solbourne in 1990 using Solbourne's
custom Object Interface library in a very early form of C++ compiled with
Cfront. No copies of this have survived, but we're looking.
Where can I find SunOS 4-compatible tools?
What about a browser?
There aren't many sources of pre-compiled software for SunOS 4 (and
precious few that are current). Rob Braun has a collection of some
available, including OpenSSL/OpenSSH,
gcc and bash. (You may need to install
gtar and gunzip first -- see below.)
In addition, I have a collection of SunOS 4 tools that I know work with the Solbourne on the gopher server. xgopher can access it, as well as many other period-contemporary browsers. (If your web browser doesn't speak Gopher, there is a Firefox add-on.)
In this archive I include g(un)zip, gtar, tcsh, a couple versions of Perl, some browsers, and a tarchive of the patches for 4.1C, among other things. There is also a copy of libc.so.1.9 that fixes the annoying version errors with the libc.so.1.8 that comes with OS/MP running some lately compiled binaries for SunOS 4. If you install this, remember to run ldconfig after and/or reboot.
The last version of Netscape for SunOS 4 was 4.61 (both the Navigator and Communicator flavours). NCSA Mosaic 2.7b5 is also known to work, though Chimera is a bit nicer and has a more streamlined interface.
In addition, here are some remembrances from Dan Julio, a very helpful fellow who was a former Solbourne engineer, as well as some pictures of what he worked on.