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) and two former Solbourne engineers: Dan Julio, who provided neat insights and answered many silly hardware questions, and Dieter Dworkin Müller, who got me started on my IDT addiction by providing an installation kernel I could netboot my first S4100 with many years ago. Last modified 15 September 2016.
|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 1991, after dismal market performance, Doug MacGregor resigned and the entire workstation line was 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 irked customers with a very slow transition from the old BSD-based SunOS OS/MP to compatibility with the new SVR4-based Solaris, effectively leaving the Solbourne's only operating system frozen in time. 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.
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.
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 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, in OpenWindows (borrowed from SunOS 4).
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. I have never seen one of these cards. The S3000 card is skinnier due to the restrictions of the case.
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.
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.