In 1987, Xetec
released a supplemental device, a Multiplexer
(MUX) unit. The MUX unit provides the
means of connecting multiple C64 or C128
Commodore computers (each with Host Adapters)
to a single hard drive. This capability was
useful in a business environment or school computer
lab. The MUX unit was also used by BBS SysOps
to connect multiple computers (each having
their own modem) to one drive, which provided
a multi-phone line BBS system with one
central storage device.
You can connect up
to four Commodores to a single MUX unit
and gang a total of four MUX units together,
which provides the capability of connecting
sixteen (16) Commodores to one hard drive.
No other Commodore hard
drive system manufacturer ever offered
'computer multiplexing' capability for their
As mentioned in
the Host Adapter section, the host adapter
is fitted with a 4-position DIP switch
used to set the Binary 'number' of the Host Adapter
- 0 through 15. This 'address' is identified as
the Port Number (seen in the F3 page in "config").
When connecting multiple Commodores (with different Port numbers)
to a Mux unit, one of these computers must have its Host Adapter set
to Port address Zero. This computer then becomes a kind of Administrator's
station because Port Zero has more control in hard drive Configuration.
For example, only Host Adapter
Port Zero can change LU sizes and Activate an LU while all Port numbers
can change their own screen colors. However, one of LK DOS routines
(SWPOUT) uses the Port Number to define a different 'Port buffer' on the
disk for data transfers. Therefore, if two or more Host Adapter's Port
Number are set the same, this would cause SWPOUT to write data to the same
buffer resulting in one of the identically IDed stations to crash.
In the same way Host Adapters need
to be set to different Port Numbers, The Mux unit also has an internal
Address switch. The Mux address switch is actually a set of four different
jumper pins, labeled M1, M2, M3 and M4. Therefore, if you were
using four Mux units, each would be set to one of four different Mux
unit numbers. If you are using only one Mux unit, there is no performance
difference if you set the Mux unit to M1, M2, M3 or M4 address.
does it works:
As shown in the
photo below, the MUX design is fairly
simple. All 8-Bit Data and SCSI Control lines
are all connected via Mux circuitry to each of the
DB-25 connectors. There are four Host
Adapter inputs (referred to as Slave 1 - 4;
note that Slave 1 is the Master Host Adapter),
one Input from another MUXer unit (referred
to as Multiplexer Output) and one input from
the hard drive referred to as Drive Input (Multiplexer Input). Computer
configurations where more than one MUXer is used,
the 'Multiplexer Input' would connected to
the 'Output' of the other MUXer (instead
of the hard drive). Regarding Mux power, each unit
is powered by its own power supply (9vdc
@ 500ma - center positive).
Simply stated, The
MUXer uses a round-robin access to the hard drive to
prevent simultaneous drive access. It does this by using
an internal free-running Counter that decodes control to one Host Adapter
at a time. If this hard drive accessible time-slot is grabbed
by a Host Adapter, the Counter stops and exclusive hard drive access
is given to that Host Adapter. When SCSI communication is finished,
the Counter continues and other Host Adapters are offered drive access.
itself knows nothing about Host Adapter Port numbers,
just that there are different Host Adapters connected.
The Mux unit manipulates the SCSI control lines
in a way that gives each computer a period of
exclusive access to the drive's
SCSI bus that extends from the MUXer
to the hard drive. This action is totally transparent
to the computers. Electronically, MUXing would
work even if all Host Adapters were set to Port
00. However, LK DOS would
overwrite data in All like-numbered Port Number Buffers - causing data corruption
or a system crash!
Where the Port
number assignments become important is in
preventing simultaneous writes to
common data areas on the drive. The LTK DOS,
in an incredibly glaring oversight, did not
have any provisions for preventing a simultaneous
write situation. It is the lack of write
conflict arbitration that can result in LU
and/or file corruption on a multiplexed system.
Amazingly enough, none of the BBS developers
ever addressed this aspect of the LTK DOS,
which meant they couldn't get their programs to
work right on MUXed systems.
However, if you
use multiple computers and assign each to a different LU section
of hard drive storage, the system works perfectly! The only
problem that could occur would be if Any
computer operator decided to run 'config'
and change storage to someone else's in-use LU#!
For detailed Mux unit troubleshooting
instructions, schematic and timing diagram, click HERE.