(c) Copyright 1991 - 1992  Bio-Engineering Research Laboratories

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, Ashland, OR.

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 
180 Beacon Hill Lane
Ashland, OR  97520

(503) 482-2744
Bio-Engineering Research Laboratories is a member of the 
Software Publishers Association.

                             INDEX

1)         Hardware Basics
2)         Basic Installation 
3)         How Does TurboCom Work 
4)         Performance Tuning TurboCom
5)         Identifying the Communications Device 
6)         Setting High Baud Rates 
7)         Setting the Receiver FIFO Interrupt Trigger Level 
8)         Setting the Transmit Fifo Filling Level 
9)         Setting the COMM Buffer Size 
10)        Setting the COMM Boost Time 
11)        Setting commport base address with COMxBase  
12)        Setting commport IRQ usage with COMxIrq 
13)        TurboCom and Windows 3.1



1)                       Hardware Basics

TurboCom defaults to using the following comm port configurations:

------------- PC-AT "classic" ISA style bus --------------------

Port Name - I/O address - IRQ usage

COM1:          3f8h          4 
COM2:          2f8h          3
COM3:          3e8h          4 
COM4:          2e8h          3

------------- PS/2 "Microchannel" style bus --------------------

Port Name - I/O address - IRQ usage

COM1:          3f8h          4 
COM2:          2f8h          3
COM3:          3220h         3 
COM4:          3228h         3

If your commports are not configured as above, be sure to read
sections 11 and 12 below.



 2)                     Basic Installation

We strongly recommend that you use the TurboCom installation
program  supplied on the TurboCom distribution diskette.  It
will perform the four following steps:

 A) 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.

 B) Copy the file named TURBOCOM.SYS from the TurboCom
distribution disk to C:\.  TURBOCOM.SYS is not required for IBM
PS/2 Microchannel models 50 and above.

 C) 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

 D) 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 Comm 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.



 3)                   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:
TurboBuf.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.



4)            Performance Tuning TurboCom
              Windows and DOS Applications

TurboCom provides a number of performance modifying parameters 
which can be placed in the [386enh] 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
configuration 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
unpredictable 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.



 5)        Identifying the Communications Device              
                Windows and DOS Applications

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

TurboCom does a good job of identifying which kind of
communication devices (e.g., UARTs) are available in your
system.  However, should you wish to turn off the use of the
advanced features of whichever device has been detected, you
can.  To force device identification, change the following
line(s) of text in  your SYSTEM.INI file, in the [386Enh]
section.  

COMxDeviceType=n

Where x = the Comm port number 1, 2, 3 or 4, and n is the
identifier for the communications device:
        
0  = Use TurboCom's automatic identification of UART,
1  = force identification as a 8250 / 8250-B style UARTs,
2  = force identification as a 8250A / 16450 style UARTs,
16 = force identification as a 16550 style UARTs.

For example;

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

COM3DeviceType=0 tells TurboCom to use its internal
identification capabilities.



 6)                  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  [386Enh] section.

COMxBaudX=n

Where x = the Comm 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
available.



 7)      Setting the Receiver FIFO Interrupt Trigger Level      
                       Window 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
performance 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 [386Enh] section.  

COMxRcvTrigLvl=n

Where x= the Comm 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
serviced.



 8)          Setting the Transmit Fifo Filling Level            
                      Windows Applications

Note: This is another item for the hacker.  Unless you really 
enjoy tinkering, there is probably no reason to change the
Transmit 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 [386Enh] section.

COMxTxDepth=n

Where x = the Comm 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.



 9)              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,
interrupt level services are provided by the operating system. 
All  applications are required to use these services to access
the hardware.  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
[386Enh]  section.

COMxBuffer=n

Where x = the Comm 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 applications, and that the minimum time
slice is set to the default value  of 20 milliseconds, then 512
bytes would be more than sufficient.



10)              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 additional time each time it receives an
interrupt 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 [386Enh] 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
operating time each time it receives an interrupt from a comm
port which  it owns.



11)        Setting commport base address with COMxBase          
                   Windows and DOS applications 

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, Comm  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:

The Windows Comm driver looks in a dedicated area of RAM to find 
the addresses of your system's (up to) four Comm 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        
Comm 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 Comm port addressing
inconsistency between the Windows Comm driver COMM.DRV and the
enhanced mode Virtual Machine Comm driver *VCD.  

However, all the addressing and availability problems are
resolved if the dedicated area of RAM has the correct
information about Comm port addresses, and the addressing
inconsistency between 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 Comm ports, places their
addresses in the dedicated RAM area, and reports its findings.

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

For example, if your ISA system has four Comm 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   

which is the default setting, 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 Comm port 
addresses, be aware that many DOS based communications programs 
make their own Logical to Physical associations, and pay no 
attention to those provided by the ROM BIOS.  Conflicts of Comm 
port associations between Windows and DOS based applications
lead to great confusion and grief!

If you are using Enhanced mode Windows, and chose NOT to use the
default I/O address listed at the begin of this document, you
must place a COMxBase= profile string, in your SYSTEM.INI file
in the [386enh] section, for each commport which is not  at its
default address.

For example:

COM1Base=2e8h COM2Base=3e8h COM3Base=2f8h COM4Base=3f8h

will let Enhanced mode Windows use the reversed
logical-to-physical connections as used in the example above. 

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



 12)        Setting comm port IRQ usage with COMxIrq             
                 Windows and DOS applications 

Windows applications running in the classic PC-AT ISA style bus
environment, require that COM1 and COM3 share IRQ4, and that 
COM2 and COM4 share IRQ3 (see section 1 above).  

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 Comm port lockup.  Once a Comm port has been acquired by
a process (i.e., a  Windows or DOS application) the hardware
interrupt associated with that Comm 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 usually 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.

When using Enhanced mode Windows, it is possible to assign
non"standard" IRQs to a commport.  Doing this will render the
port unusable by Windows applications, but DOS applications may
be able to use it.  This capability will be useful if you have
a DOS application running and don't want to tie up IRQs four or
three, which Windows applications can use.

For example: 

COM3Irq=5

will assign IRQ5 to COM3.  Windows applications will not be able
to use COM3, but DOS applications that can use a commport
assigned to IRQ5, will be able to use the port.  Since COM3 is
no longer sharing IRQ4 with COM1, COM1 will be available to
Windows applications even though COM3 is being used by a DOS
application.  (Don't forget to physically hook up COM3 port to
IRQ5!).



13)	          TurboCom and Windows 3.1

TurboCom is a full superset of the Microsoft supplied Windows
3.0 comm driver.  That is, it matches every feature, and adds
additional features.

Starting with Windows 3.1, Microsoft added features to the comm
driver some of which were not already in TurboCom.  The following 
describes four features.  

A) The Microsoft comm driver for Windows 3.1 provides limited
support for the 16550 UART receive FIFO but no support for
the transmit FIFO.  The support is provided only for Windows
applications.  There is no 16550  support for DOSapplications.  
The support for the receive FIFO is locked to a receive 
interrupt trigger level (see explanation above) of 14. The 
result is that at higher baud rates, Windows comm
applications are significantly more vulnerable to lost
characters (overrun errors) than necessary.

   TurboCom is a superset of these features.  16550 UART support
is provided for both the receive and transmit FIFOs, and for
both Windows and DOS applications.  TurboCom permits the user
to adjust the receiver trigger level and transmit fifo filling
level to meet their system's performance capabilities.

b) The Microsoft comm driver for Windows 3.1 introduced a new
software API for setting baud rates, and permits applications
implementing the new API to directly set baud rates above 19.2
Kbaud.  Applications created before Windows 3.1 are unable to
set baud rates above 19.2 Kbaud.

   TurboCom has always provided the ability to directly set
baud rates above 19.2 Kbaud, and for Windows applications that
do not take advantage of this ability, the COMxBaudX=
mechanism (described above) to allow the user a "back-door"
to set baud rates above 19.2 Kbaud.

   Starting with Version 1.2, TurboCom has added the Windows 3.1
software API for directly setting baud rates.  The older
applications can still use the COMxBaudX= mechanism for
setting baud rates above 19.2 Kbaud.

c) The Microsoft comm driver for Windows 3.1 expanded the number
of available IRQs for Windows applications permitting, a user 
to use IRQs such as IRQ5 or IRQ7 for comm ports.

   This capability is being considered for a future release of
TurboCom.

d) The Microsoft comm driver for Windows 3.1 added three
functions to the comm API.

   These functions are being considered for future releases of
TurboCom.

e) The Microsoft comm driver for 3.1 fixed the problems that prevented
sharing IRQs between comm ports on a rotating basis in the ISA bus 
environment, matching TurboCom's feature.

 ****************************** END ********************************   

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 enforceable 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
180 Beacon Hill Lane
Ashland, OR  97520
(503) 482-2744
