Solbourne KBus systems

KBus machines

The KBus architecture consists of the 500, 600, 700, and 900 chassis', and the Series4, Series5, Series5e, Series6, Series6E, and (mythical, but really existed) Series7 cpus.

The KBus

The KBus is a synchronous 128MByte/sec backplane that has 32bits of address, 64bits of data, and 8 ECC bits. It's therefore a great improvement over the Sun VME bus (which is 32bits (address and data are multiplexed) and 25MB/sec). However, being proprietary, it's hard to get pieces for it, and if you've invested a lot of money in 128MB memory boards, you can only use 'em in Solbournes.


500 [Picture]
A 5 slot tabletop/deskside chassis which has space for one 3.5" internal SCSI disk. It could be placed vertically by using pedestal stands with the fans blowing downward (preferred mode to keep fan vents from clogging) or by setting it on the face to allow airflow through the sides)

you may place the I/O board in slot "5", or in slot "4". We have a system where slot "5" is bad, but the I/O board works in slot "4" since they are electrically equivalent for I/O boards signals

600 [Picture]
A 7 slot deskside pedestal. Had a large vertical SCSI tray that would hold like 4 full height 5.25" SCSI disk and one half-height 5.25" device (or a full-height SCSI tape drive)

ZAP!Cooling :
For Series6 boards, you'll want to clip and splice together the thermistor leads in the top front of the inside of the kbus section of the chassis. This will make the fans blow full-time at the highest speed. Also, you should check the squirrel cage where the blowers are and clean any built-up dust-bunnies out of the interior of the fan blades. I may take some pictures of where these things are/access panels soon...

700 [Picture]
A 7 slot rack-mount chassis with a horizontal configuration. Apparently was plagued by heat dissapation problems.
900 [Picture]
An 11 slot rack-mount chassis with virtually no restrictions.

some real old (maybe all) 16MB boards didn't support the concept of > 7 KBus slots (only 3 bits on the Slot ID selector) and will not work in the last few slots of the 900, but work fine in the first 6)

KBus Boards

The I/O card

click for nifty photo
This is the heart of the box. The I/O board interfaces the following subsystems:

The I/O board must be in slot 7 due to some fixed value in an early design stage. In the 900 chassis, slots are remapped in order that the I/O board being in physical slot "11" still appears to be in slot 7. Also, the 500 chassis maps physical slot "5" to slot 7.

There can be only one I/O board per KBus system (however the MCAB card is a limited I/O board, having an ethernet port, a SCSI port and a single VME slot (using multiple MCABs, you could build a pretty honkin' I/O server)

The I/O board revisions are important. If you have a multiprocessor VME system you should have at least revision DD (DE if you have a MUX). If you have a 500 single cpu system, you can use AJ and probably any of the Dx revisions. The DA-DC revisions are probably particularly bad for multiprocessor and/or VME configurations. Personally, i think you need at least "DF" to do VME on Series6.

Please see Incompatability Issues for problems i have discovered with I/O boards, etc.


Board     CPU              FPU           MHz     L1/L2 Cache  PhysAddr
-----     ---              ---           ---     -----------  --------
Series4   Fuji MB86900     Fuji MB86910  16.67   64KB         256MB
Series5   Cypress CY7C601  Weitek 3171   33      128KB        256MB
Series5E  Cypress CY7C601  Weitek 3171   40.1    128KB        1GB
Series6   TI Viking        [integrated]  33      1MB/16MB     ?
Series6E  TI Viking        [integrated]  50      1MB/16MB     ?
  (damn TI's oily hide for not including any info whatsoever on the Viking
  in their web pages)
Series7   ?                ?             ?       ?            ?
Series4 (Impulse)
Series5 (Warpdrive) click for nifty photo
Series5e (Warp+) click for nifty photo
Series6 (Cherry?) click for nifty photo
The Series6 board is built around the TI Viking chips. Even though it has an MBus connector on it, you can't add additional MBus modules. This is because the cache coherency logic doesn't support it. It is, however, possible to use the MBus connector to supplant the CPU on the board. You may need to physically remove the KBus boards' CPU and MXCC (cache controller) chips and/or set some jumpers. (so says some of the folks who worked on/near it). Someday, if i get an sun SM41 i'll try it. I'm pretty sure this is about the only one that might work as it has the SuperCACHE controller onboard which would be necessary on the Series6. Anyone else who gets this to work or tries it, please let me know.

With 16MB of 3rd level cache, and the 1MB 2nd level cache, this board really screams.

Series6E (?)
Same as the Series6, just using a 50MHz oscillator and 50MHz Viking and MXCC chip.
Series7 (?)
Only two of these were hand-assembled in engineering. If you have one, I wonder how you got it, and can i please have it?
As i understand it, this board had the cache coherency logic to allow multiple MBus modules onboard.

Memory boards

Most of these used 100ns ZIPPs, though newer ones have 80ns. Doesn't really matter as you couldn't access that fast through the KBus anyway.

some old 16MB boards can't deal with slots above 6 on a 900 chassis

300ns write cycle time

250ns write cycle time


click for nifty picture
The Multi-Channel Accelerator Board (MCAB or codename 'tyboard') is basically a limited I/O board, offering the ability to "multi-process" the I/O in addition to cpus across the KBus. It supported:
SCSI (Differential or Single-Ended)
one 6U VME Slot
i'm not sure what the max number of supported boards is, though i've seen documentation suggesting only four (4).

Officially (due to desire to reduce testing time), the MCAB is only supported in the 700 and 900 chassis. It should work fine in 500 and 600 chassis and in practice works just fine in a 5E/601 at CU. It is thus also a cool way to get VME onto your 500 system. Also, the only officially supported VME board is the IPI controller

To access the MCAB address space, the kernel configuration lines have an additional iobus specifier (basically, the I/O board is an implicit "iobus 0". So, for example, the MCAB SCSI, ethernet, and a VME IPI card controller specs for a system with one would be:

# I/O board SCSI
	controller	si0 at kbio ? csr ? priority 2
	device		sa0 at si0 drive 0
	device		sd0 at si0 drive 0x00 flags 0x4a
	controller	si1 at kbio ? iobus 1 csr ? priority 2
	device		sa1 at si1 drive 0
	device		sd8 at si1 drive 0x00 flags 0x4a
# I/O board Ethernet
	device		ei0 at kbio ? csr ? priority 3
# MCAB Ethernet
	device		ei1 at kbio ? iobus 1 csr ? priority 3
# MCAB IPI controller board
	device		xdc0 at vme16d16 ? iobus 1 csr 0xee80
			dma vme24d32_blk priority 2 vector xdintr 0x44


[Picture] CG30 color graphics board is a relatively fast device that software simulates the Sun CG2 interface. It consists of RGB BNC outputs as well as its own Keyboard/Mouse interface (you could drive multiple user "seats" from a single box)

watch out on the standard X server which finds the console port for /dev/bwtwo0 first, and uses it, instead of your nice cg30 card.
SOLUTION: move /dev/bwtwo0 to /dev/, or use the "-dev" option to the Xserver to force it onto /dev/cgtwo0
Additionally, i believe that the device selection code using multiple -dev flags and the XDEVICE ":" separator are fixed in the latest X11 patch tree


slower framebuffer that didn't have keyboard support (used the I/O board kbd)


There is now a seperate section for the KBus machine's VME.
last modified on Wed Jul 4 20:29:07 MDT 2001
Stephen Dowdy