Solbourne KBus systems
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 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
- NOTE :
- 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)
- 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.
- ZOW :
- 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)
The I/O card
click for nifty photo
This is the heart of the box. The I/O board interfaces the following
- Serial I/O (2 RS232C ports)
- Mono Console / Keyboard+Mouse
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
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
- Series6E (?)
- Same as the Series6, just using a 50MHz oscillator and 50MHz Viking and MXCC
- 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.
- 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.
- NOTE :
- 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:
i'm not sure what the max number of supported boards is, though i've
seen documentation suggesting only four (4).
- SCSI (Differential or Single-Ended)
- one 6U VME Slot
- SUPPORT NOTE :
- 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
# MCAB SCSI
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
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
- GOTCHA :
- watch out on the standard X server which finds the console
port for /dev/bwtwo0 first, and uses it, instead of your nice cg30
SOLUTION: move /dev/bwtwo0 to /dev/btwo0.off, 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
last modified on Wed Jul 4 20:29:07 MDT 2001