[Hosted by Floodgap Systems]

The Solbourne Solace @ Floodgap Retrobits

featuring a blessed, updated copy of Stephen Dowdy's Solbourne Shack

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.

What's a Solbourne? What happened to them?

Solbourne Computer was founded in 1986 by Douglas MacGregor in Longmont, Colorado with substantial funding by Japanese conglomerate Matsushita (who had a 52% stake). Matsushita's interest came from complex origins, including exploration of the growing high-performance RISC market of the late 1980s, but also attempting to outflank competitor Fujitsu, who at that time was an early licensee of the then up-and-coming SPARC architecture. (Fujitsu still is today the major producer of categorical SPARC architecture systems apart from Oracle.) Matsushita particularly wanted an easy path to market for a competing RISC design of their own, something that would come to haunt the new company later, and MacGregor's experience designing the very popular Motorola 68020 convinced Matsushita management the new startup would be a good bet since he had the proven chops to do it. SPARC itself seemed like the right fit: it was trendy, it satisfied Matsushita's strategic goals, and it had room to grow. Solbourne became a licensee in 1988.

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.

What models exist?

Note that most KBus boards could fit into other model chasses, even if Solbourne didn't actually sell that specific configuration. The specific series enumerated below were to indicate which chasses were being documented as sold for a specific series, not that those were the only chasses the system boards would physically fit (or work) in.

[Solbourne 5/500, from spec sheet.]

What's OS/MP?

OS/MP is Solbourne's custom operating system, essentially SunOS 4.1.x with added patches for multiprocessing and memory management. 4.1 correlates with 4.1, 4.1A with 4.1.1, 4.1B with 4.1.2 and 4.1C with 4.1.3. The KAP and Series6/6E machines require at least 4.1A. Even the uniprocessor systems must run OS/MP due to their custom MMUs and, in the case of the IDT machines, various irregularities with KAP.

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.

[Scanned photograph of a Unisys S2000.

Are there Solbourne clones?

There weren't Solbourne clones per se that I know of, but Unisys did (at least plan to) rebadge the IDT workstations as the Unisys S2000 line, as did Tandon. This was only authorized in Europe and Asia, and it isn't clear if any were actually sold; the scan at left is from an Italian computer industry magazine at the time. Notice that other than a Unisys badge slapped on the front, it's exactly the same.

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).

Why can't I run Linux on it? This sucks! You suck! Waaaah!

Solbourne didn't lose any sleep on documenting the custom MMU and KBus features, so it was never supported even when Solbourne still had market relevance. You can try to run OpenBSD/solbourne on your IDT machines, but it has major userland problems, and the Series4/5/6 machines have no support from any open-source operating system at all. If you're looking for a cheap SPARC to run Linux on, don't buy one of these.

Why can't I run Solaris on it? This sucks! You suck! Waaaah!

Solbourne was never able to move OS/MP from SunOS 4 to Solaris because Sun withdrew license terms from all SPARC clone makers, per Stan Hanks, "science advisor" at Solbourne from 1987 to 1990 (Apple would later pull the same stunt with Mac clones and Mac OS 8). Ostensibly some support for the Series5 and Series6 KBus systems is present in Solaris 2.3, but not in any later version, and it is unclear how functional it is. Solbourne never made a public release of this code themselves.

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.)

What type of monitor do I need?

Most Solbourne video cards emit a 1152x900 display with a vertical frequency somewhere around 66 to 69Hz (the Solbourne spec sheets say 69Hz for monochrome and 66Hz for colour). If your monitor can accept that, you're golden. Like Sun cards, Solbourne display cards use either BNC or 13W3 video connectors, and converters for Sun systems will work for Sols as well as most Sun monitors of the era. I personally used a 4-BNC Sony GDM-1604-15 with my S4100 (sga20 graphics), which Sun also rebadged. Parenthetically, while it's a nice monitor, it's also freaking huge, freaking bulky and freaking fixed frequency.

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.

Can I run the system multiheaded?

I've never tried this with the Series4/5/6 systems (I only have one KBus video card), and I've never attempted it with an S4x00, but the results with an S3000 are decidedly mixed. When I put a colour SBus video card (an sga20) into it, leaving the built-in plasma display card installed and running, the machine went haywire. On the other hand, Stephen was able to install a second bw20 in his, so maybe you can only dual-head black and white cards.

That said, I have been told by others who have tried that Sun SBus display cards won't work in the IDT systems either.

Does the S3000 really have a plasma display?

Yes. It appears to the system as a bw20 ("bwtwo") black and white display with a total resolution of 1152x900. It is a flaring, hot (literally: it can cast off a fair bit of heat) orange gas plasma display which is quite unique and unlike pretty much any other RISC workstation. The flicker can bother some people, though I've never personally had any problems using it.

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.

Here's my system doing serious business.

[Author's S3000.]

The author's S3000, upgraded with an S4100 KAP+L2, SCSI2SD and SBus RAM expander card, in OpenWindows (borrowed from SunOS 4).

What was the PILOT laptop? Did it really go up in the Space Shuttle?

Thanks to Scott Manley for originally spotting this system in NASA photos. PILOT was the Portable In-flight Landing Operations Trainer and was commissioned by the U.S. National Aeronautics and Space Administration as a portable simulator to ensure that the Shuttle commander and pilot, while in orbit, maintained "the highest level of proficiency for the end of mission approach." It ran a ported version of NASA's Shuttle Engineering Simulator on OS/MP 4.1A.

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.

Why don't Sun keyboards work? What about mice?

None of the Sun keyboards will work with the Solbourne and vice versa. Per Dieter (via Warner), the signalling is the same but the pinouts are different, an intentional d*ck move by Solbourne to force you to buy their own peripherals. Some keyscan codes may also differ. Converters did apparently exist at one point but I've never seen one personally.

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.

[Brain surgery on an S3000, of a sort.]

Can I upgrade an S3000 (or an S4000) to an S4100? (S4000DX?)

Yes, if you have the right logic board revision. The IDT machines share a common board with two revisions: the original 33MHz board (labeled "IDT-CPU") used in the earlier S3000 and S4000 systems, and a later revision (labeled "S4000/S4100") which has support for the cache. S3000 and S4000 machines manufactured after the introduction of the S4100 use the same board, just with a 66MHz crystal (divided down to the 33MHz CPU speed) instead of a 72MHz crystal (divided down to 36MHz).

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!

[Installing the memory expander card in an S3000.]

Can I put more RAM in?

Maybe. For the KBus machines, you just install more (or bigger) KBus RAM boards. Some of the largest systems can take KBus RAM boards as large as 1GB, which was a staggering (and staggeringly expensive) amount of memory then. Mind the total addressing space supported by the installed CPU board(s).

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.

Can I mix KBus CPU board types in the same chassis, like a Series5E with a Series5?

I don't have multiple KBus CPU board types myself, but my suspicion is no, or at best you'd get weird problems with the OS.

I found this Solbourne and it appears to power up but it won't boot.

You might be lucky: the settings might just be scrambled. If it's sitting at a ROM> prompt and just looking at you, try typing boot and see how far you get. If that tries to boot from the network (see below), reset the machine or stop it with Stop+A and try boot sd.si()

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.

Okay, I got it to boot, but I don't have the root password.

Boot an installation kernel from an OS/MP CD (or tape, I guess, if you have one), or the network, then use the install menu to mount the filesystem and get a root shell, and remove the password from /etc/passwd.

Fine then. How can I boot it from CD? (Or the network?)

Solbournes expect certain SCSI devices in certain places: CD-ROMs must be on device ID 6 and be Sun-compatible (i.e., capable of 512-byte block transfers), and tape drives are expected to have an ID of 5. You may be able to get it to start with the device configured differently, but the boot kernel will start to do weird things when it comes to configuring and installing onto your root disk. Assuming you do that and the OS/MP CD-ROM is loaded, you can simply boot the OS with a modified boot command like boot sd.si(,D,)Install.XXXX where D is the device ID and XXXX is the model. (All IDT systems should use S4000 as the model, since they have a common logic board.) For example, to boot my "S3000DX" from CD, I type:

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 = A0000004
rarp: server at IP address = 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 already there.

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 SunOS 4.1.

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:

Since your machine is now under YP/NIS control (just its own), certain things like adding user accounts will now need to be YP-aware. One way is to follow the steps under adduser(8), edit the password file with vipw and then do a make under /var/yp to force the update.

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.

There's stuff missing. How do I reinstall OS/MP? (I just put a SCSI2SD in it. How do I install OS/MP?)

Here's my OS/MP installation guide. It assumes some basic Un*x knowledge, but very little SunOS 4 knowledge. I've included some instructions for the SCSI2SD.

sunview sucks. Can't I run OpenWindows? Or X11R6?

I rather like sunview (which comes with OS/MP), but OpenWindows actually can run X applications and is "more Sun-like." Fortunately, if you have SunOS 4 install media, you can simply unpack the OpenWindows tarchive from that onto your root disk and it will "just work." My S3000DX is set up exactly this way. There is also a separate, later build of X11R6 for SunOS 4 which will run essentially unmodified on the Solbourne as well.

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 older precompiled archives 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.

Where can I find out more about these really cool computers?

Continue on to the Solbourne Shack.

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.

Are you willing to sell any of your Solbourne systems or peripherals?


Cameron Kaiser