Mux Serial Port driver v1.A for NeXTSTEP and OPENSTEP for intel.

How to install this driver:
	1) Acquire the Mux.1.A.I.b.pkg.compressed or equivalent. It would
	   also be helpful to install Opener.app available from:
		ftp://next-ftp.peak.org/pub/next/apps/archiveutil/Opener/
	   but not absolutely necessary.
	2) Double click on the file or enter:
		$ open Mux.1.A.I.b.pkg.compressed'
	   from a terminal window. If you do not have Opener.app, then from a
	   open Terminal window, enter the following sequence:
		$ cd /tmp/
		$ compress -dc <Mux.1.A.I.b.pkg.compressed | tar -xvf -
	   which should unpack the package.
	3) Now, as root, double click on the unpacked package. OpenSesame,
	   which is supplied with NeXTSTEP and OPENSTEP, can be utilized. If
	   you did not have Opener.app, then in the above terminal window
	   enter the following sequence:
		$ su root
		Password: ******
		# open Mux.pkg
	4) Follow the instructions within Installer.app.
	5) Run Configure.app after the package is installed to fine tune any
	   of the parameters. The Mux package will auto-install one instance
	   of itself, either for an available PCI serial device, or for the
	   first free standard ISA serial port address. If an instance
	   of the Mux driver already exists, or Configure.app is running
	   during the above procedure, then no auto-install of one instance
	   occurs.
	6) Reboot to activate the driver.

How to compile this driver:
	1) You need the Development system for NeXTSTEP for Intel. If you only
	   have a user version, I believe some of the archives *should*
	   contain a compiled version of the package as it would end up in
	   Mux.config. Contact me (mark@bohica.net) to get the binaries
	   if you have limited access.
	1a) Openstep 4.0's project builder is evil, to run it to build the
	   Mux driver will add horns to the beast and cause cats and dogs to
	   sleep with each other.
	1b) Openstep 4.2 and Prelude to Rhapsody require the following files
	   from the NS 3.3 development system:
		/lib/libsys_s.a
		/lib/crt0.o
	   It is recommended move the OS4.2 crt0.o to crt0.o.4.2, the NS3.3
	   crt0.o to crt0.o.3.3 and do a hard link from crt0.o.3.3 to crt0.o.
	   Being able to statically compile is a plus for other applications.
	1c) For the adventurous that insist on using OS4.2, install NS3.3 on
	   a disk, then copy the NS3.3 install image into a development
	   subdirectory on your OS4.2 machine, or use the disk mounted to
	   some development subdirectory. Acquire chroot(1) and set the
	   root to the development directory and perform your compiles.
	2) Unpack into a working source subdirectory (You must have done this
	   to have extracted this README file).
	3a) if you do *not* have a SerialMouse (a Bus Mouse instead), then
	    you can replace the SerialPorts driver completely. The
	    Default.table file as shipped will work fine for adding single
	    ports with single interrupts and you need not read as dilegently.
	3b) if you *need* a SerialMouse, then you will need to set up an
	    instance to the SerialPorts driver to handle just the mouse.
	3c) if you are setting this driver up to talk to a multiplexed serial
	    card, then you will also need to edit the Instance?.table files
	    because the default configuration inspector is not up to the task
	    graphically. Expert mode will be needed.
	3d) if you need to tailor the buffer sizes, edit the Instance?.table
	    files directly after configuration, or in Expert mode. But we
	    talk too fast.
	4) Edit the MuxParm.h file for your system. Typically the only
	   configuration option that you will need to change is the
	   _NX_KERNEL variable to match your OS revision. All the variables are
	   (supposedly? :-) well documented in the file. You may wish to
	   alter some of the constants and conditional compile switches in
	   MuxParm.h if you appear to have troubles with a specific
	   application using the project.
	5) Either through the Project builder (Note: Do not use the project
	   builder under OpenSTEP 4.0 PR1 or PR2, it damages the Makefiles and
	   does not recognise driverkit projects properly), or from a terminal
	   command line in this directory, `make bundle' to ensure that the make
	   goes without problems (see below, not on kern/lock.h bug in the
	   development system). This step is optional, and is only to build
	   confidence. make.pkg can be used to generate the packages.
	6) If the make went without a hitch, become root (either by re-invoking
	   Project Builder through the OpenSesame service, or by su in a
	   terminal window) and `make install'
	7) Install the Mux driver using the Configuration.app if it is possible
	   for your specific configuration. Even so, Configuration.app may
	   be used and then the brave can go on to editing the Instance?.tables,
	   or use the `Expert' button.
	8) For *each* IRQ, set up a separate instance of the driver, unlike the
	   SerialPorts driver which reserves two IRQs for it's initial instance.
	   Look at the Info.rtfd file for a general idea of what this means.
	9) Sound simple? I have a bridge I can sell you. If I spent less time
	   improving the performance and testing this driver, I would have
	   written an all seeing all dancing Configuration inspector for this
	   driver. As you see, you get what you pay for ...

	< Sales Job, Why would you want to do this to yourself? >

This serial driver is used to add additional ports. I have managed to get
reliable 115200 Baud (fixed rate) operation with this driver under
NeXTSTEP/FIP with the 16550s of either a single additional port, or
on the multiplexed 4 or 8 port DigiBoard cards. I ran four ports simultaneously
to USR 33.6bps Courier Modems at an interface rate of 115200 Baud.

I have had reports of speeds into the 5300c/s region for this driver! I get
only 870ch/s from the SerialPorts driver, and my machine crashes if I try
using it at 19200 Baud (on a 486/66) ... I can calmly say: 500M of news flow
at 115200 Baud (to a 33600bps modem), has not crashed the machine!

You are free to use this source in any way you wish, but credit must be given
to California Regents Berkeley, Carnegie Mellon University, Olivetti (for their
original work) and Mark Salyzyn.

This driver is designed to work as a DigiBoard and AST Style multiple serial
I/O cards, LAVA PCI serial card, single port *any* address *any* interrupt, or
multiple port (no mux register) shared interrupt (use a 470 ohm resistor in
parallel with a diode to provide the wired-or [active high] connections for
the IRQ lines).

Hayes ESP support is also available in the driver, but can be optionally
compiled.

Bugs:

The Default Inspector does not work adequately on multiplexed boards except to
set the interrupt, it has no concept of multiple port addresses (except in NS3.3
and higher using the Expert button). If you use it to set up the port, it will
work adequately for a single port card added into the system though. Under
NS3.2, It is recommended to use an editor to manipulate the
/NextLibrary/Devices/Mux.config/Instance0.table (but keep in mind that you do
this at your own risk, drop me a note if you want some confidence pills ...)
yourself after the Config Application is finished and saved to add in the
additional ports on a Interrupt Multiplexed card, or to adjust other
characteristics of the driver. An address range of 1 or 2 bytes is assumed to
be the multiplex register, and must be stated last in the set of serial port
ranges (with a range of addresses of 1[AST] or 2[DigiBoard]).

The SerialMouse driver doesn't like this driver at all because of hard coded
checking done within the Configure and Loading of the driver application to
ensure that the SerialPorts driver is loaded. Since a 1200 Baud serial mouse
hardly is a problem for the original SerialPorts driver, a `cook book'
arrangement is documented to set the system up in the Configurations
subdirectories. When mixing the SerialPorts and Mux drivers, one must be very
careful about the NXString variables associated with device paths.

I would recommend using a single instance of the PortServer for the Serial
Mouse in NS3.3 and higher.

With the addition of the RTS side of the RTS/CTS handshaking, the driver
no longer overloads the Kernel beyond TTYHOG on streaming protocols. You can
control the size of the Receive and Transmit buffer by editing the
Instance?.table files, or using the Expert button in the configuration
application under NeSTSTEP 3.3, but once again, I remind you that you do this
at your own risk (This driver in itself may void any warantees and service
contracts).

If anyone wishes to write an inspector that can handle multiple port cards, I
have just started on a *.nib for it in the Mux.tproj directory (out of date
now that I have added buffering). Idealy, the Default Inspector should be
able to handle this ... the code is 50% written, and can be turned on with
a change in one manifest constant in the MuxParm.h file.

Bugs:

Compile error (NS3.2 and NS3.3):
} /NextDeveloper/Headers/bsd/sys/user.h:40: header file 'kern/lock.h' not found

This is a NeXT bug, since kern/lock.h is included in bsd/sys/callout.h,
bsd/sys/user.h and bsd/sys/ux_exception.h. The message is supposed to be
a warning since it should pull in NextDeveloper/2.0CompatibleHeaders/<blah>,
but some have complained that the warning steps up to an error message (?)

The fix, edit the above files changing kern to kernserv, or link kernserv
to kern in the /usr/include directory.

Please send ALL bug reports (and any code fragments you wish added) to
mark@bohica.net (Mark Salyzyn). I am interested in any work you feel
will improve this project.

Legal ease(sic):

If you feel compelled to donate an amount that would appear to compensate me
for my efforts in writing and maintaining this driver, I would appreciate
receiving said funds. Contact me at mark@bohica.net for my current fixed
address.

Ciao -- Mark Salyzyn