The World of Computer Software/World_Of_Computer_Software-02-387-Vol-3of3.iso/t/turbocom.zip/INSTALL.TXT

Text File | 1991-06-04 | 26KB | 629 lines

(c) Copyright 1991  Bio-Engineering Research Laboratories, Berkeley, CA

This document may not, in whole or in part, be copied, photocopied,
translated, or reduced to any electronic medium or machine readable
form without prior written consent from Bio-Engineering Research
Laboratories.

        About your SINGLE USER LICENSE of TurboCom(TM)

TurboCom is a commercial product developed by John Loram at
Bio-Engineering Research Laboratories, Berkeley, CA.

TurboCom was developed on a speculative basis in response to
the perceived need for improved Asynchronous communications
capabilities under Microsoft Windows 3.0.

The Single User License, printed on the envelope in which TurboCom
is packaged, grants specific rights.  Please take a few minutes to
read and understand the extend of these grants.  We have tried to
make the elements of the Single User License as unencumbering as
possible  while protecting the substantial effort that has been
made to provide a useful product.

TurboCom is not a shareware product.  Please do not share it
with your friends and associates, even on a trial basis.  You
may of course test TurboCom on any system and as many systems as
you wish, so long as the Single User License agreement is not violated.

A copy of the Single User License appears at the end of this
document for your reference.

TurboCom is available under single user licenses, site licenses,
and licenses for bundling with other software and hardware
products.

Quantity discounts are available for single user and site
licenses. For further information contact John Loram at:

Bio-Engineering Research Laboratories
2831 Seventh St.
Berkeley, California 94710

[phone]





                       Basic Installation

Installing TurboCom is a five step process.  It may be accom-
plished while in Windows or DOS.


1) Copy the three files named TURBOCOM.DRV, TURBOVCD.386, and
TURBOBUF.386 from the TurboCom distribution disk into the
\WINDOWS\SYSTEM sub-directory. If your system is based on the
80286 processor you need only copy TURBOCOM.DRV.


2) Copy the file named TURBOCOM.SYS from the TurboCom distribu-
tion disk to the directory in which you keep your DOS .SYS files.
On many systems this would be the root directory of the boot
volume (e.g. C:\).  TURBOCOM.SYS is not required for IBM PS/2
Microchannel models 50 and above.


3) Append the contents of TURBOCOM.INI from the TurboCom distri-
bution disk to your Windows SYSTEM.INI file, which you will find
in your main \WINDOWS sub-directory.  Make sure that TURBOCOM.INI
is appended to the SYSTEM.INI file, not to one of the other .INI
files located in this sub-directory.


4) Find and modify the following profile strings in your
SYSTEM.INI file:

In the [boot] section of SYSTEM.INI:

  change profile string comm.drv=comm.drv to read comm.drv=TurboCom.drv

In the [386enh] section of SYSTEM.INI make two changes (unnecessary
for 286 machines):

  change profile string device=*vcd to read device=TurboVcd.386

  change device=*combuff to read device=TurboBuf.386


5) Add the following line to your CONFIG.SYS file:

DEVICE=TURBOCOM.SYS

This line must appear in the CONFIG.SYS file before any line
which loads a driver involving Com ports such as a serial port
mouse driver, or a serial port network driver.  It can be safely
placed as the first device driver in the CONFIG.SYS file.
TURBOCOM.SYS is not required for IBM PS/2 Microchannel models 50
and above.


                     How Does TurboCom Work

TurboCom works on three levels to greatly improved Windows and DOS
asynchronous communications performance.

Level 1 Improvements - Comm Port hang-ups and COM3/4 availability:
TurboCom.sys is a DOS device driver that extends the boot-time
system initialization functions of the ROM BIOS of your ISA based
system.  Few ISA ROM BIOSes make provisions to initialize COM3 and COM4
hardware and the associated ROM BIOS data area where comm port base
addresses are stored.  No ROM BIOS for ISA based system properly
initialize the 16550 UART.  The result of these limitations is that
many systems cold boot with their serial port hardware incompletely
initialized, and warm boot with their UARTs in unpredictable, often
inaccessible states.  TurboCom.sys performs proper hardware
initialization of 8250, 16450, and 16550 UARTs, and builds a
complete UART data table in the ROMBIOS data area of system RAM.
It then reports the results of its efforts and discoveries and
exits without taking up system RAM.

Level 2 Improvements - Windows Comm Port bugs and 16550 UART support:
TurboCom.drv and TurboVCD.386 comprise the two basic Windows Comm
Drivers.  TurboCom.drv is the Windows 3 Comm Driver.  It provides
the application program interface (API) for Windows applications
which use the serial and parallel ports, and the interrupt level
routines for Real and Standard mode operation.

Two bugs, one dealing with comm port hangups during high-speed full
duplex operations and another causing IRQ conflicts were corrected.
The interrupt level code was restructured to make it more efficient
standard UARTs, and take better advantage of the high performance
hardware features of the 16550 UART.

TurboCom brings new levels of performance to Windows Asynchronous
port usage by providing support for the hardware buffers in the
16550 high performance UART.  The sixteen byte transmit and receive
buffers of the 16550 UART make it highly resistant to the often
poor interrupt response time of multi-tasking environments like
Windows.  In addition, with the 16550 UART's ability to collect
multiple characters before issuing an interrupt, the receive and
transmit interrupt overhead can be reduced by as much as an order
of magnitude.

Level 3 Improvements - DOS Comm support and 16550 access:
TurboBuff.386 provides a RAM based UART buffer for DOS
applications running under enhanced mode Windows.  TurboBuf
collects characters from the UART into a system RAM buffer while a
DOS application is switched out.  When the application is switch
in during its time-slice, TurboBuf provides the collected characters
to the DOS application by simulating the UART, interrupts and all.



              Performance Tuning TurboCom
              Windows and DOS Applications

TurboCom provides a number of performance modifying parameters
which can be placed in the TurboCom section of the SYSTEM.INI
file.  Some of them are quite esoteric and will not need to be
change in most systems.  Others, will likely be changed by every
user.

First, a little about the purpose and structure of your
SYSTEM.INI file.

The SYSTEM.INI file is similar in function to the DOS CONFIG.SYS
file; it tells Windows which Windows device drivers to load, and
it allows those device drivers access to user supplied configura-
tion information.

The SYSTEM.INI file's contents are composed of sections in the
format of [SectionName] (note the square brackets) and profile
strings in the format of Profile=String (note the equal sign).

Profile=Strings are always associated with the specific
[SectionName] which proceed them.  Should another [SectionName]
inadvertently be placed between a Profile=String and its associated
[SectionName], the association is broken and strange unpredict-
able events will almost certainly occur, often at boot time but
sometimes much later.

Make a copy of your SYSTEM.INI file before you change it and keep
the copy in a separated directory.




          Identifying the Communications Device
               Windows and DOS Applications

COMxDeviceType=n, default n = 16, legal values = 0, 1, 2, or 16

If your system does not exclusively use 16550 style UARTs, you
will want to change one or more of the COMxDeviceType profile
strings to reflect your actual hardware configuration.

TurboCom does a good job of identifying which kind of communica-
tion devices (e.g., UARTs) are available in your system.  How-
ever, should you wish to turn off the use of the advanced features
of whichever device has been detected, you can.  TurboCom will
override inappropriate choices and tell you about it.  To force
device identification, change the following lines(s) of text in
your SYSTEM.INI file, in the [TurboCom] section.

COMxDeviceType=n

Where x = the Com port number 1, 2, 3 or 4, and n is the identi-
fier for the communications device:
    0 = unknown,
    1 = 8250 / 8250-B style UARTs,
    2 = 8250A / 16450 style UARTs,
    16 = 16550 style UARTs

For example;

COM1DeviceType=16 tells TurboCom that Com port 1 is a 16550 style
UART.

COM3DeviceType=0 tells TurboCom to treat the Com3 device as the
simplest of     communication devices, which is currently the
same as choice #1, the 8250 / 8250-B.




                    Setting High Baud Rates
                      Windows Applications

If you wish to use baud rates above the 19,200 limit imposed by
the standard Windows Comm driver, the COMxBaudX profile string allows
you to do so.

COMxBaudX=n, default  n = 1, legal values = 1, 2, or 3:

Most commercial Windows applications only provide for baud rate
settings of 19,200 baud and below.  This is because the standard
Windows Comm driver rejects any attempt to set a higher rate.

Since TurboCom performs well at 57,600 baud in fast machines, you
can multiply the nominal baud rate by a factor of two (2) or
three (3) on a per channel basis.

To multiply the baud rate set by your Windows application, change
the following line(s) of text in your SYSTEM.INI file, in the
[TurboCom] section.

COMxBaudX=n

Where x = the Com port number 1, 2, 3, or 4, and n = the baud
rate multiplier 1, 2, or 3.

For example;

COM2BaudX=3 will multiply an application set baud rate of 19,200
baud to an actual 57,600 baud for Com2.

COM4BaudX=2 will multiply an application set baud rate of 19,200
baud to an actual 38,400 baud for Com4.

TurboCom will reject attempts to set rates above 19,200 baud on
ports that do not have high performance hardware (e.g., 16550
style UARTs).

The TurboCom API allows a Windows application to directly set
baud rates up to 57,600 baud if the appropriate UART is avail-
able.




      Setting the Receiver FIFO Interrupt Trigger Level
                 Window and DOS applications

Note: This is really high tech stuff, and is here mostly for the
un-reconstructed hacker.  Unless you really enjoy tinkering,
there is probably no reason to change the Receive FIFO Interrupt
Trigger Level.

COMxRcvTrigLvl=n, default n = 8, legal values 1, 4, 8, or 14

The 16550 UART has two 16 byte fifos (First In First Out
buffers). One is for incoming (received) characters, and the
other for outgoing (Transmitted) characters.  These two fifos are
the 16550's distinguishing features, and are key to the perform-
ance enhancements that TurboCom provides.

Associated with the Receive Fifo, is the Receive Fifo Interrupt
Trigger Level.  This programmable value determines to what level
the receive fifo must be filled by incoming data, before the UART
will issue a service requesting Data Available interrupt.  You
may set this variable to one of its four legal values 1, 4, 8, or
14.  If your Windows applications lose incoming characters when
your system is very active, you might try reducing this variable
from the default of 8 to 4 or even 1.

If you are serious about dinking with this variable you should
probably become thoroughly familiar with the technical issues
concerning the 16550 UART (get a data sheet) and the interrupt
response time of you system.

To set this variable, change the following line(s) of text in
your SYSTEM.INI file in the [TurboCom] section.

COMxRcvTrigLvl=n

Where x= the Com port number 1, 2, 3, or 4, and n= the trigger
level 1, 4, 8, or 14

For example;

COM3RcvTrigLvl=14 means that the UART will not issue a Data
Available interrupt until it has collect 14 bytes of data.  It
can receive 2 more bytes before it absolutely must be serviced,
or a data overrun will occur.

If you're wondering what happens if just 13 characters come in,
the answer is that the UART has a timer.  That timer will cause
an interrupt if data sits in the UART for four character times
without another character being received or the fifo being ser-
viced.




            Setting the Transmit Fifo Filling Level
                  Windows and DOS Applications

Note: This is another item for the hacker.  Unless you really
enjoy tinkering, there is probably no reason to change the Trans-
mit Fifo Filling Level.

COMxTxDepth=n, Default n = 8, legal values 1, 2, 3......, 16

Each time the Transmit Fifo becomes empty, the UART issues a
service requesting Transmit Fifo Empty interrupt.  While an empty
Transmit Fifo could be filled with as many as 16 characters,
there may be times when this is not desirable.  Certain flow
control issues might make it desirable to stop transmitting
characters before the 16 byte fifo is empty, and there is no
mechanism in the 16550 UART to accomplish this.  The only option
is not to fill the Transmit Fifo so full.

To set the number of characters placed in the Transmit Fifo on
each Transmit Fifo Empty interrupt, place the following line(s)
of text in your SYSTEM.INI file, in the
[TurboCom] section.

COMxTxDepth=n

Where x = the Com port number 1,2,3 or 4, and n = the fill level
1,2,3....., 16
For example:

COM3TxDepth=12 means that each time the Com3 Transmit Fifo Empty
interrupt is serviced, the Transmit Fifo will be filled with 12
characters from the Transmit Queue, if that many are available.




                Setting the COMM Buffer Size
                      DOS Applications

If your DOS applications running under enhanced mode Windows are
experiencing character overruns (lost received characters) this
section is for you.

COMxBuffer=n, Default n = 128, legal values 0, 1, 2......, 10000

In traditional (UNIX, VMS, etc.) multi-tasking environments, inter-
rupt level services are provided by the operating system.  All
applications are required to use these services to access the hard-
ware.  Enhanced mode Windows is unique in that each Virtual Machine
(VM) provides its own hardware drivers.  The Serial Port Drivers,
(Comm Drivers) for the Windows VM (Comm.drv, or TurboCom.drv in our
case) are provided with the Windows package.  The Serial Port
Drivers for DOS applications running under Windows are provided
either by DOS or by the DOS application itself.  The question then
arises, what shall we do with a character received by a UART which
is "owned" by a VM (DOS application) that has been switched out.
TurboBuf provides an answer, by providing a buffer in system RAM for
each comm port.  TurboBuf collects characters from the UARTs, places
them in buffers, and then when the VM (DOS application) which owns a
comm port is active, TurboBuf delivers the characters by simulating
the UART, interrupts and all.  In this way even 16550 unaware DOS
applications benefit from its high performance features.

To set the number of bytes buffered for DOS applications, place the
following line(s) of text in your SYSTEM.INI file, in the [TurboCom]
section.

COMxBuffer=n

Where x = the Com port number 1,2,3, or 4, and n = the size of the
buffer in bytes, 0, 1, 2..... 10000

For example:

COM2Buffer=512 means that TurboBuf will provide a 512 byte buffer for
the COM2 serial port.  This buffer would be large enough to hold
about one half second's worth of characters at 9600 baud.  If you
assume that there are three VMs active, Windows and two DOS appli-
cations, and that the minimum time slice is set to the default value
of 20 milliseconds, then 512 bytes would be more than sufficient.



                 Setting the COMM Boost Time
                 Windows and DOS applications

If your Windows or DOS applications are experiencing sluggish comm
performance, character overruns (lost received characters), or loss
of keyboard characters under enhanced mode Windows, this section is
for you.

COMBoostTime=n, Default n = 2, legal value 0, 1, 2......, ?

This setting gives a VM addition time each time it receives an inter-
rupt from an comm port.  Since TurboCom and a 16550 UART result in
substantial reductions in interrupt overhead it may not be necessary
to ever increase this value.  If you give a VM too much additional
time using this method, it can quickly hog the whole system.  There is
only one COMBoostTime profile string for all comm ports.

To set the number of milliseconds additional time upon each owned
comm interrupt, place the following line of text in your SYSTEM.INI
file, in the [TurboCom] section.

COMBoostTime=n

Where n equals the number of additional milliseconds operating time
granted to a VM upon receipt of each comm interrupt.

For example:

COMBoostTime=5 will give the VM an additional 5 milliseconds of oper-
ating time each time it receives an interrupt from a comm port which
it owns.




Hardware: I/O Addresses, port availability, Interrupts, and Com
Port Lockups

If you have experienced difficulties with Windows' Message Boxes
that proclaim "The COMx port is currently assigned to a DOS
application.  Do you want to reassign the port to Windows?", and
then when you answer in the affirmative nothing happens.  Or, Com
ports that work one minute but not the next, this section is for
you.  It will give you some understanding of the roots of your
travail, and an explanation of how TurboCom will help.

I/O addresses and Port Availability:

A Windows Comm driver looks in a dedicated area of RAM to find
the addresses of your system's (up to) four Com ports.  This RAM
area is initialized by the system ROM BIOS at boot time.  Only a
few very recent ROM BIOSes are fully aware of Com3 and Com4 and
correctly initialize this data area.  If  the data area is not
properly initialized, and the address the Windows Comm driver
finds is ZERO, Windows will make assumptions that depend:

    upon whether Windows is operating in Real/Standard vs.
        Enhanced mode,
    upon whether it is looking for Com1/Com2 or Com3/Com4,
    upon whether the bus structure is the ISA vs. EISA/MCA,
    upon the Model and Submodel data in the ROM BIOS
    and finally, upon quantity and the base addresses of the
        Com ports in you system.

The permutations and combinations have created a great deal of
misunderstanding and confusion.

All of this is made more complex by a Com port addressing incon-
sistency between the Windows Comm driver COMM.DRV and the en-
hanced mode Virtual Machine Comm driver *VCD.

However, all the addressing and availability problems are re-
solved if the dedicated area of RAM has the correct information
about Com port addresses, and the addressing inconsistency be-
tween the Windows Comm driver and the Virtual Machine Comm driver
is corrected.

TURBOCOM.SYS is provided to properly initialize the data area and
TURBOVCD.386 corrects the addressing inconsistency.  TURBOCOM.SYS
is not required for IBM PS/2
Microchannel models 50 and above.

TURBOCOM.SYS, in part, acts as an extension of the ROM BIOS.
When loaded by the CONFIG.SYS file at DOS boot time, TURBOCOM.SYS
searches for four Com ports, places their addresses in the dedi-
cated RAM area, and reports its findings.

TURBOCOM.SYS also permits the user to optionally enter load line
arguments (switches) which extend the search for Com ports to
non-standard I/O addresses, and force a specific
physical-to-logical mapping of Com ports that are found.  Up to
four switches may be entered, one for each logical Com port.

For example, if your ISA system has four Com ports at the quasi-
standard addresses of 3f8h, 2f8h, 3e8h, and 2e8h, the
TURBOCOM.SYS load line in your CONFIG.SYS file might be:

DEVICE=TURBOCOM.SYS /3f8 /2f8 /3e8 /2e8

This would make the following assignments:
    Logical port        Physical port
    Com1:        =    3f8h
    Com2:        =    2f8h
    Com3:        =    3e8h
    Com4:        =    2e8h

You could reverse the Logical to Physical connection with the
following load line:

DEVICE=TURBOCOM.SYS  /2e8 /3e8 /2f8 /3f8

Which would make the following assignments:
    Logical port        Physical port
    Com1:        =    2e8h
    Com2:        =    3e8h
    Com3:        =    2f8h
    Com4:        =    3f8h

If you choose to use a non-standard arrangement of Com port
addresses, be aware that many DOS based communications programs
make their own Logical to Physical associations, and pay no
attentions to those provided by the ROM BIOS.  Conflicts of Com
port associations between Windows and DOS based applications lead
to great confusion and grief!

TURBOCOM.SYS is 16550 UART aware, and will properly initialize
these high performance devices.

Interrupt sharing and Com Port Lockups:
While simultaneous hardware interrupt sharing is not possible in
the ISA bus environment without special serial port hardware, it
should be possible to share hardware interrupts on a sequential
basis.  However, because of a conceptual error in the Windows
Enhanced mode Virtual Comm driver, interrupt sharing of any kind
with Windows in an ISA bus environment will lead to Com port
lockup.  Once a Com port has been acquired by a process (i.e., a
Windows or DOS application) the hardware interrupt associated
with that Com port will become permanently unavailable to the
other serial port sharing the interrupt.  If the other serial
port, which shares the interrupt, is subsequently activated it
will also claim the hardware interrupt.  At this point neither
port will operate, yet neither port will completely relinquish
the interrupt.  The only solution is a power off re-boot of your
system.  Even a warm boot is not enough because of limitations in
most ROM BIOS.

TURBOVCD.386 corrects this problem and allows serial ports to be
passed about with abandon, provide the one-at-a-time on an IRQ
restriction is observed.



The follow is a reproduction of the Single User License AGREEMENT
print on the sealed disk package in which TurboCom is shipped is provide
here for your convenience.  Should there be any difference between this
reproduction and the original on the sealed disk package, the original
shall prevail.

TURBOCOM LICENSE AGREEMENT

BY OPENING THIS SEALED DISK PACKAGE, YOU AGREE TO THE TERMS OF THIS
AGREEMENT WITH BIO-ENGINEERING RESEARCH LABORATORIES.  IF YOU DO NOT
AGREE TO THE TERMS OF THIS AGREEMENT, PROMPTLY RETURN THE UNOPENED
DISK PACKAGE AND THE ACCOMPANYING MATERIALS TO THE PLACE YOU OBTAINED
THEM FOR A REAL REFUND.  This agreement supersedes all prior agreements
and understandings between you and Bio-Engineering Research Laboratories
regarding the TurboCom driver.

SOFTWARE LICENSE

1. The enclosed software is protected by both United States copyright
law and international treaty provisions.  Therefore, you must treat
this software like a book, with the following single exception.  You
are authorized to make archival copies of the software for purposes
of backup to protect your investment from loss.  2. By saying "like
a book" we mean, for example, that this software may be used by any
number of people and may be freely moved from one computer location
to another so long as there is no possibility of it being used at one
location while it is being used at another.  Just like a book that
cannot be read by two different people in two different places at the
same time, the software may not be used by two different people in two
different places at the same time.  3. The software is licensed to you
and title to the software is retained by Bio-Engineering Research
Laboratories.  You may not rent or lease the software but you may
transfer the software and accompanying written materials on a permanent
basis provided you retain no copies and the recipient agrees to the
terms of this agreement.  If the software is an update, any transfer
must include the update and all prior versions.  4. You agree that you
will not reverse, engineer, decompile or disassemble the software.

LIMITED WARRANTY

5. Bio-Engineering Research Laboratories warrants the physical disk and
the accompanying physical documentation to be free of defects for a
period of thirty days from the date of purchase.  In the event of
notification within the warranty period of defects, Bio-Engineering
Research Laboratories will replace the defective disk or documentation.
The remedy for breach of this warranty is limited to replacement and
shall not encompass any other damages, including but not limited to loss
of profit, and special, incidental, consequential or other similar claims.
6. Bio-Engineering Research Laboratories specifically disclaims all other
warranties, expressed or implied, including but not limited to implied
warranties of merchantability and fitness for a particular purpose, with
respect to the disk, accompanying documentation, and the program license
granted herein.  In no event shall Bio-Engineering Research Laboratories
be liable for any loss of profit or other commercial damage, including
but not limited to special, incidental, consequential or other damages.

GENERAL

7. For purposes of licensing to any agency of the United States government,
the software and documentation are provided with RESTRICTED RIGHTS.  8. This
agreement is governed by the laws of the State of California and is enforce-
able by Bio-Engineering Research Laboratories and/or its resellers and
distributors.  The prevailing party in any action brought in connection with
an alleged infringement of proprietary rights in the enclosed software will
be entitled to recover its costs and expenses, including attorneys fees.

Bio-Engineering Research Laboratories - 2831 Seventh St., Berkeley, Califorina
[phone]