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


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

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 never completed moving OS/MP from SunOS 4 to Solaris. 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 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, in OpenWindows (borrowed from SunOS 4).

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

None of the Sun keyboards will work with the Solbourne and vice versa. At best they won't work; at worst you might short something, depending on the model. In addition to different signaling, the Solbourne keyboards have different scan codes and earlier ones have more keys as well.

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!

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

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

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?

No.

Cameron Kaiser