             ONEFOSsil FOSSIL 5 Communications Driver Revision 9
          (C) Copyright 1995-96 by Carl Morris and Morris Softronics,
                             all rights reserved
         Published and released by Morris Softronics on June 15, 1996

                              Table of Contents
    Topic---------------------------------------------------------Location
    What is ONEFOSsil?...................................................1
    Warranty.............................................................2
    Licensing Information................................................3
         Distribution..................................................3-1
         Registration..................................................3-2
         Benefits of Registering.......................................3-3
    System Requirements..................................................4
    Installation.........................................................5
         Port Argument.................................................5-1
         Command Line Options..........................................5-2
              Locking Port Settings..................................5-2-1
              Setting Buffer Sizes...................................5-2-2
              Setting Multitasker Options............................5-2-3
              Controlling FIFO's.....................................5-2-4
              Holding the Interrupt..................................5-2-5
              Controlling Time-outs..................................5-2-6
              Controlling Carrier-Detection..........................5-2-7
    After Installation...................................................6
         Un-installing.................................................6-1
         Getting Status................................................6-2
         Changing Port Settings........................................6-3
         Forcing Port Opened...........................................6-4
         Forcing Port Closed...........................................6-5
    Examples of Installation and Use.....................................7
    Compatibility Notes..................................................8
         Shared IRQ's..................................................8-1
         Pretested Software............................................8-2
         Windows Tips..................................................8-3
    Troubleshooting (obtaining support)..................................9
    Credits.............................................................10

                        Section 1: What is ONEFOSsil?

    ONEFOSsil is a high speed serial communications driver for 8250 series
    UARTs.  The 8250 series includes all compatible UARTs, such as the
    8250A, 8250B, 16450, 16550, 16550A, and the 82510 in 16450
    compatibility mode.  Other UARTs are sure to exist that may be
    compatible.

    ONEFOSsil provides services for FOSSIL compliant software.  ONEFOSsil
    supports most of the FOSSIL 5 specification and the Extended X00
    FOSSIL specification.  ONEFOSsil will probably work with any program
    that is designed to use a FOSSIL driver.  Some differences do exist
    between ONEFOSsil and a full FOSSIL 5 driver, and the technical
    document, ONEREF.TXT, describes these differences.  Very few of these
    differences should cause problems.

    ONEFOSsil is special (it can't be called unique) in that it only
    supports one FOSSIL port at a time.  This provides the best solution
    for multitasking environments such as DESQview or Windows where only
    one port is needed in each task.  Just because ONEFOSsil is a single
    port driver, that does not stop it from being useful for multiport or
    multiline systems.  ONEFOSsil can even handle multiple ports that
    share the same IRQ (read Compatibility Notes - Shared IRQ's.)

    Some people ask why there is a need for another FOSSIL driver.  Other
    people are finally relieved to see new FOSSIL drivers.  Its been
    nearly two years since the last update of any FOSSIL driver.  Most
    drivers are much older than that yet.  Many of the current drivers are
    loaded with bugs, and the versions that are bug free are lacking
    needed features.  Most drivers are not even supported by their authors
    anymore.

    ONEFOSsil was wrote to fill this gap completely.  ONEFOSsil not only
    provides an alternative, but a better solution.  The author stands
    behind ONEFOSsil, promotes it and FOSSIL compliant software, and is
    willing to take the heat.  In a time where more and more software is
    becoming less and less DOS based, it is hard for anyone to provide and
    support such a product as ONEFOSsil.  It is only for this reason that
    ONEFOSsil has been produced as a shareware product.  By supporting the
    author, you show the author your support of his work in supporting the
    product.

                             Section 2: Warranty

    The shareware version of ONEFOSsil comes with absolutely no warranty.
    Due to the instability of modern media and the unreliability of
    communications devices, it can not be guaranteed that this copy of
    ONEFOSsil is in the same state as when it was released.  Use of this
    software and/or documentation is at your own risk.

    Carl Morris, Morris Softronics, or any of their distributors can not
    be held responsible for any accidental or consequential damages this
    product may cause, including destruction of data, or damage to
    equipment.  No warranties exist on the use of this product, either
    expressed or implied, and is hereby disclaimed of any and all implied
    warranties of merchantability and fitness for a particular purpose.

    The only expressed warranty of the registered version of ONEFOSsil is
    if ONEFOSsil ever performs incorrectly, ONEFOSsil will be corrected
    and a new registered version will be made available.  This is based on
    Morris Softronics judgment of "performing incorrectly."

                       Section 3: Licensing Information

    Since ONEFOSsil is primarily a shareware product, several licenses
    apply to its distribution and use.  ONEFOSsil is protected by U.S.
    copyright laws and international copyright treaties and is licensed,
    not sold.

                          Section 3-1: Distribution

    Distribution rights of this copy of ONEFOSsil is described in the file
    DISTRIB.TXT supplied with this copy.

                          Section 3-2: Registration

    The shareware version of ONEFOSsil is for evaluation only.  After the
    evaluation period, the full version of ONEFOSsil must be licensed for
    use, or the shareware version must be removed from use.  The file
    REGISTER.TXT supplied with ONEFOSsil will detail the registration
    process.

                     Section 3-3: Benefits of Registering

    Registration of a shareware product is usually done to extend the
    usefulness or enjoyment of a product.  Shareware products usually come
    crippled, or with some form of a reminder, or both.  ONEFOSsil is not
    crippled in any way.  ONEFOSsil will display a registration reminder
    every time it is ran.  ONEFOSsil will delay 5 seconds when it is
    installed.  This is a small price to pay to evaluate cripple free high
    performance software such as ONEFOSsil.

    Registration of ONEFOSsil will include, but not be limited to:  an
    indefinite license agreement, an executable without the delay and
    reminder, free (from registration costs) upgrades to newer versions,
    enhanced support from the author, and discounts and specials on other
    products from Morris Softronics.

                        Section 4: System Requirements

    To be effective and useful, ONEFOSsil requires the following: MS DOS
    3.0 or compatible operating system, a minimum of 64k of memory(uses 4k
    minimum for installation), an 80286 or compatible processor, an 8250
    or compatible UART, and software that is FOSSIL 5 compliant.

    Almost any application that is FOSSIL 5 (or less) compliant should
    function with ONEFOSsil.  Lots of new applications that use FOSSIL
    drivers are appearing all the time, so it is hard to say that any
    specific kind of software will or will not use ONEFOSsil.

                           Section 5:  Installation

    NOTICE: As of revision 9, some functions have not yet been completed.
    Notes will appear if a function is still being written.  Please read
    Troubleshooting if any problems arise.

    ONEFOSsil knows little, and assumes less about the computer it is
    being used on.  ONEFOSsil gets all its information about the computer
    off the command line.  ONEFOSsil's command line is simple to use when
    installing.  Only one argument is required; all other arguments are
    optional, and may be placed in any order after the first argument.
    The following is the syntactical use of ONEFOSsil for installation:

         ONEFOS port=address,irq [L=[baud][[,format][,flow]]]
              [B=[write][[,read][[,stop][[,continue]]]]]
              [S=os[,sensitivity]] [F=[buffer][,trigger]] [H] [T=time]
              [D[=delay]]

    Details on each option are in the following sections.  Refer to
    Examples of Installation and Use if additional help is required.
    Notice that ONEFOSsil's command line is case insensitive.  The letters
    A and a are treated the same.

    An error level of 0 is returned if ONEFOSsil was successfully
    installed.

                          Section 5-1: Port Argument

    The port=address,irq argument is the only argument required to install
    ONEFOSsil.  However, seldom will ONEFOSsil work at it its best
    potential knowing that little and assuming the rest.

    The port value is the decimal number of the communications port
    ONEFOSsil is to provide services for.  It may be any value from 1 to
    64.  Not all software support ports greater than 8 or 16.  In most
    cases, port 1 is the same as COM1 and so on, but may be changed at
    will for special circumstances (ie, you may make port 3 be COM7).

    The address and irq values provide ONEFOSsil with the hardware address
    for the UART it is to provide services for.

    The address value is a hexadecimal number that details the base
    input/output address for the UART.  Valid values for address range 100
    though FFFF.

    The irq value is a decimal number that details the hardware interrupt
    request line the UART will use to signal ONEFOSsil to communicate with
    the UART.  Valid values for irq are 3 though 5, 7, 9 through 12, and
    15.  If a value of 2 is needed, the value 9 will work.

    The following table displays some common values used for port,
    address, and irq.

    COM Port  port address   irq
    -------------------------------------
      COM1      1    03F8     4
      COM2      2    02F8     3
      COM3      3    03E8     4
      COM4      4    02E8     3

    Notice that ONEFOSsil refers to ports the same way most application
    software do; other FOSSIL drivers do not.  This was done to make
    ONEFOSsil simpler to use specially in batch files that need to use
    ONEFOSsil commands after ONEFOSsil has been installed, but more on
    that later.

                      Section 5-2: Command Line Options

    Following the port=address,irq argument may follow any number of
    options in any order, provided no option is repeated.  Most of these
    options change ONEFOSsil's usefulness or performance.  For some
    computers and software, some of these options seem mandatory.  The
    following sections describe each option in detail.  It is encouraged
    that people should read each section carefully to see which options
    may apply to their computer or software.

                     Section 5-2-1: Locking Port Settings

    The most often used option in FOSSIL installations is the settings
    locking options.  With ONEFOSsil, almost anything that can be
    configured by applications can be locked on the command line, to
    prevent an application from changing it.  This is primarily what the
    settings locking options are for.  With high speed modems, the
    "computer to modem" speed seldom changes, and so is locked to prevent
    applications from changing it.  Most configurations also only use an
    "8N1" data format, and so often lock it, to prevent possibly buggy
    software from changing it.  ONEFOSsil has an added option; ONEFOSsil
    can lock which types of flow control are to be used, preventing
    applications from changing them.  The syntax for ONEFOSsil's settings
    locking option follows:

         L=[baud][,[format][,[flow]]

    What this shows is that all values are optional.  If a value is not
    specified, a comma should still be placed between the missing values.
    Trailing commas are not permitted, and of course, if no values are
    specified, one should not place L= on the command line.

    The baud value defines the baud rate that will always be used to
    communicate on this port.  Applications are not permitted to change
    it.  Only ONEFOSsil may later change or clear this value.  Often, high
    speed modems have an option to remain at one speed all the time.  If
    the modem on the port works this way, the baud value should be used to
    specify this speed.  For slow speed modems, this value should usually
    not be used.  The baud value may be 110, 150, 300, 600, 1200, 2400,
    4800, 9600, 19200, 28800, 38400, 57600, or 115200.

    The format value defines the data format that should always be used to
    transmit and receive characters.  Applications are not permitted to
    change it.  Only ONEFOSsil may later change or clear this value.  Most
    configurations only call for 8 data bits, no parity, 1 stop bit.
    Unless need warrants, this value should always be locked to "8N1".
    The format value is specified by combining one value from each of the
    following groups: data bits - 5, 6, 7, or 8; parity - N for none, O
    for odd, E for even, M for mark, and S for space; stop bits - 1 or 2.

    The flow value defines which methods of flow control should be locked.
    Applications will not be permitted to set or remove flow control
    options locked here.  Only ONEFOSsil may later change any flow control
    options which have been locked.  Flow control can both be locked
    enabled or locked disabled.  If a baud value was specified, hardware
    flow control should be locked enabled.  In many cases, software flow
    control provides problems, and should locked disabled.  The flow value
    can be any one or more(providing they are not repeated) of the
    following: [-]H to lock enabled [or disabled] hardware flow control,
    [-]S to lock enabled [or disabled] sending of software slow control
    codes, or [-]R to lock enabled [or disabled] acting on received
    software flow control codes.  With most high speed modems, flow should
    almost always be set to "H-S-R".  However, locking software flow
    control disabled may provide problems with some FAX software.

                     Section 5-2-2: Setting Buffer Sizes

    Increasing buffer sizes often makes applications more efficient and
    increases the application's performance.  While the default buffer
    values work fine on most DOS only based systems, users of multitasking
    environments may find they need larger buffers.  ONEFOSsil provides a
    single option that permits setting buffer sizes, along with flow
    control threshold values.  ONEFOSsil is one of the few communications
    drivers known to allow the user to tweak the flow control thresholds.
    The syntax for the buffer configuration command follows:

         B=[write][,[read][,[stop][,[continue]]]]

    What this shows is that all values are optional.  If a value is not
    specified, a comma should still be placed for the missing value.
    Trailing commas are not permitted, and of course, if no values are
    specified, one should not place B= on the command line.

    The write value specifies the size in bytes of the transmit buffer.
    Valid values for write range 32 through 32767 and defaults to 1024.  A
    common rule for setting the buffer is to set the buffer large enough
    to hold one second worth of data.  An ideal value for write is 1024 to
    5760.

    The read value specifies the size, in bytes, of the receive buffer.
    Valid values for read range 32 through 32767 and defaults to 1024.  A
    common rule for setting the buffer is to set the buffer large enough
    to hold one second worth of data.  An ideal value for read is 1024 to
    5760.

    The stop value specifies the point at which there is too little room
    in the receive buffer and flow control should be engaged to prevent an
    overrun of the receive buffer.  Valid values for stop range 0 through
    1 less than the read value and defaults to  of the read value.

    The continue values specifies the point at which there is enough room
    in the receive buffer to safely disengaged flow control after it has
    been engaged, allowing more data to be received.  Valid values for
    continue range 1 through the value of read and defaults to  of the
    read value.  The continue value must be larger than the stop value.

    Notes

      The total size of the buffers can not exceed the memory limit of
      the driver.  ONEFOSsil occupies about 4k of memory, so the
      remaining 60k of the memory available to it may be split between
      the two buffers.
      A receiver buffer size of 32 should only be used on very slow
      modems or serial connections.  Otherwise, the receive buffer size
      should never be less than 64 bytes.
      The stop and continue values are automatically calculated based on
      the read value, and it is strongly suggested not to attempt to
      change the default settings.

                  Section 5-2-3: Setting Multitasker Options

    ONEFOSsil provides a means to detect when some applications are idle,
    and return their time slice to the multitasker.  For this to work, the
    application must be using ONEFOSsil and you must be running in a
    supported multitasking environment.  Currently both DESQview and
    Windows are supported.  ONEFOSsil does not detect which multitasker it
    is functioning on, so defaults to not returning time slices.  The
    syntax for setting the multitasker options follows:

         S=os[,sensitivity]

    The os value specifies which multitasker ONEFOSsil is to return time
    slices to.  Valid values are D for DESQview and W for Windows.

    The sensitivity value is optional, and specifies the sensitivity
    ONEFOSsil is to measure before returning time slices.  Valid values
    for sensitivity range 0 through 255 and defaults to 128 if not
    specified.  This value works somewhat like Windows 95's MS-DOS Program
    Properties Idle Sensitivity slider, but in the opposite direction.
    Smaller values yield more time slices; larger values yield fewer time
    slices.  There is no known ideal value.  Some applications have been
    found to be so efficient at making FOSSIL calls that ONEFOSsil can not
    detect their idleness.

                      Section 5-2-4: Controlling FIFO's

    ONEFOSsil is considered the be one of the few communications drivers
    to permit the user to configure the usage of the 16550 receive and
    transmit FIFO's independently.  This was done because when using the
    new multitasking environment's virtualized communications ports, there
    is performance to be gained.  Please read Compatibility Notes -
    Windows Tips for more information when running under Windows or
    Windows 95.  The FIFO settings option is only valid if the UART was
    detected with working FIFO's.  The syntax for controlling the FIFO's
    follows:

         F=buffer[,trigger]

    The buffer value specifies the number of characters ONEFOSsil will
    buffer into the UART's transmit FIFO.  Valid values for buffer are 0
    through 255, and defaults to 16 on the 16550.  The buffer value should
    not exceed the number of transmit FIFO's the UART has.  A 16650 may be
    capable of buffering 32 characters, but has not been tested.  A value
    of 0 forces FIFO's to be entirely disabled.

    The trigger value is optional, and may only be specified if the buffer
    value was specified.  The trigger value is a code that specifies how
    many characters must be received before the UART will request
    ONEFOSsil to read them.  Current values for trigger range 1 through 4
    and defaults to 3.  On a 16550 UART, the trigger value causes the
    following results:

    trigger   characters received
    ------------------------------
       1           1
       2           4
       3           8
       4           14

    Generally, trigger should be set at 3 unless problems occur.  If
    problems like CRC errors occur frequently when pressing a key or
    switching tasks, the trigger value should be reduced.  However,
    special settings apply for Windows, documented in Compatibility Notes
    - Windows Tips.

                     Section 5-2-5: Holding the Interrupt

    Under some circumstances, it might be dangerous for ONEFOSsil to hook
    the UART's interrupt request vector only when needed.  The hooking
    option forces ONEFOSsil to hook the interrupt at installation time
    rather than when needed by an application.  The syntax for the hooking
    option follows:

         H

    The hooking option will not prevent applications from hooking on top
    of ONEFOSsil, and does not prevent applications from stealing the
    UART's hardware interrupt request or FOSSIL services vectors from
    ONEFOSsil.  It is primarily provided for users that load ONEFOSsil
    before the multitasking environment, but may not be required.  There
    were also circumstances documented in Compatibility Notes - Pretested
    Software that required the use of this option.

                     Section 5-2-6: Controlling Time-outs

    Some functions in the FOSSIL specification will not return until they
    have been satisfied.  Hardware problems wreak havoc with this, and may
    cause unexplainable lock-up's.  ONEFOSsil provides a configurable
    time-out option to force these functions to return after the preset
    time period.  This helps reduce the chances of sudden hardware
    problems from completely locking up a system.  The syntax for the
    time-out option follows:

         T=time

    The time value specified the length of time that ONEFOSsil will wait
    for a function to complete when failing.  The unit of time is seconds,
    and valid values range 0 through 3599 (60 minutes), and defaults to
    30.  If other FOSSILs provide a time-out condition it is generally 30
    seconds, Some FOSSILs will never time-out.  The BIOS communications
    routines usually time-out after 2 seconds; however, most FOSSIL
    compatible software are wrote to skip time-outs, and so too small a
    value will cause lost characters during flow control.  Time-out values
    are accurate to 1,080/19,663rds of a second (just incase you were
    wondering).

                 Section 5-2-7: Controlling Carrier Detection

    ONEFOSsil provides a means of delaying carrier drops or providing
    applications with a continuous carrier detection.  This is known as
    providing a fake carrier detect, and ONEFOSsil is known to be the only
    FOSSIL driver that provides the user such an option.  Providing a
    delay for carrier drops may improve connections on 2400bps or slower
    modems.  Providing a fake carrier detect is a software means of
    solving a faulty or incorrectly wired null-modem cable, or enabling
    software to work with a 3-line cable.  The syntax for the delayed
    carrier option follows:

         D[=delay]

    Specifying the D without a value forces the carrier detect to be
    always active on this port.  When an application requests the port
    status, ONEFOSsil will always report that there is carrier present.
    If the optional delay value is specified, ONEFOSsil will delay the
    carrier from dropping for delay units of time.  The unit of delay is
    1,080/19,663rds of a second, or approximately 1/18th of a second.
    Valid values for delay range 1 through 32767 (30 minutes).  A common
    value, if needed, is 18, which provides about 1 second for the carrier
    to recover.  This is used primarily on old 1200 or 2400bps modems
    which permit the carrier detect line to drop during line noise.  Newer
    models of slower modems no longer need this as they perform like high
    speed modems, which only drop the carrier detect line when the
    connection has been terminated.

    This option is provided to make ONEFOSsil possibly the most complete
    communications driver.  This option may be often useful for people
    trying to figure out how to connect two computers together and can't
    get their software to work without a carrier detect.  For those who
    can wire a cable, the following will help:  On each end of the cable,
    short the lines named DSR and DCD together.  This provides a carrier
    detect based on the DTR.  Then to lower the DCD to fake having "hung
    up" one would lower the DTR line.  Most communications programs lower
    DTR to hang up modems, so this works well on computer to computer
    connections.

                        Section 6: After Installation

    After ONEFOSsil has been installed, ONEFOSsil can manipulate some of
    its functions or change its parameters.  The syntax for using
    ONEFOSsil to execute its commands follows.

         ONEFOS port [command]

    The port argument works the same as if ONEFOSsil was installing
    itself.  Generally port 1 refers to COM1.  The following commands
    apply to the command value.

    A more complete utility is coming soon from the author that will
    enable its users to do almost anything to the FOSSIL driver from a
    batch file.  More on this when the time comes.

                          Section 6-1: Un-installing

    After having been installed, ONEFOSsil can be removed from memory when
    its services are no longer needed.  The following is the syntax for
    the un-install command.

         U

    ONEFOSsil will attempt to remove itself from memory.  If it is unsafe
    to do so, an error will be displayed, and ONEFOSsil will remain in
    memory.  Different versions of ONEFOSsil will not un-install each
    other.  An error level of 0 is returned if ONEFOSsil successfully
    removed itself.

                         Section 6-2: Getting Status

    Getting the status of a ONEFOSsil port is not currently available.  It
    simply hasn't been completed.  When it is completed, it will provide
    some information about the current conditions of the specified
    ONEFOSsil port.  It will also be able to display some information
    about other FOSSIL driver's ports.

                     Section 6-3: Changing Port Settings

    Changing the port settings of a ONEFOSsil port is not currently
    available.  It simply hasn't been completed.  When completed it will
    permit both changing the locked parameters or just the current
    settings for port speed, data format, and flow control.

                       Section 6-4: Forcing Port Opened

    ONEFOSsil can be used to force a port activated.  This is not specific
    to ONEFOSsil ports, and may be used with any FOSSIL driver.  The
    syntax for opening a port follows.

         O

    ONEFOSsil will attempt to open the specified port, and will report its
    success or failure.  ONEFOSsil will exit with an error level of 0 if
    it was successful.

                       Section 6-5: Forcing Port Closed

    ONEFOSsil can be used to force a port deactivated.  This is not
    specific to ONEFOSsil ports, and may be used with any FOSSIL driver.
    The syntax for closing a port follows:

         C

    ONEFOSsil will attempt to close the specified port, and will report
    its success or failure.  ONEFOSsil can not insure that it was
    successful though, but will exit with an error level of 0 if it
    appears to have worked.

                 Section 7: Examples of Installation and Use

    This section will show some examples on how ONEFOSsil is installed and
    used.  These examples usually will not be sufficient by themselves,
    but they provide hints on how options are used in case the
    descriptions above were not clear enough.

    Installing ONEFOSsil on standard COM1 which is running a 28800bps
    modem.  This will set the buffers to allow for one second of data.
    This is a standard command line used for most 28,800bps modems on
    COM1.

         ONEFOS 1=03F8,4 L=115200,8N1,H-S-R B=4096,4096

    Installing ONEFOSsil on a completely non-standard port, locking the
    baud rate at 38400, data format at 8N1, and hooking the hardware
    interrupt at load time.

         ONEFOS 5=3480,12 L=38400,8N1,H H

    Installing ONEFOSsil on COM4 using IRQ 7 locking the data format at 7
    data bits, even parity, 2 stop bits, and locking software flow
    control, with very small buffers.

         ONEFOS 3=02E8,7 L=,7E2,SR B=64,64

    Un-installing ONEFOSsil from COM3.

         ONEFOS 3 U

    Opening COM1 after ONEFOSsil has already been installed.

         ONEFOS 1 O

                        Section 8: Compatibility Notes

    These sections include some tips and other issues on using ONEFOSsil
    in specific environments or with specific software.  Some of these
    tips may have been reported by users, but have usually been tested.
    Some suggestions may not always work under some circumstances.  You
    use these suggestions at your own risk.

                          Section 8-1: Shared IRQ's

    ONEFOSsil supports ports that share the same IRQ.  Under DOS or
    DESQview, this will only work if ONEFOSsil is the last driver to use
    the interrupt and is loaded before the multitasker.  Any number of
    copies of ONEFOSsil should be able to share the same IRQ.  Under
    Windows or Windows 95, it is believed that ONEFOSsil will work even if
    loaded in each window.  This is due to how Windows virtualizes the
    communications.  Please read Windows Tips for more information.

                       Section 8-2: Pretested Software

    The following software notes have been taken during testing and normal
    use of ONEFOSsil.

    DOORWAY: It was earlier noted that DoorWay required the H option or
    the O command (before loading DOORWAY SYSF).  This no longer seems
    necessary.

    CEXYZ: If you use CEXYZ as a protocol driver, under a multitasker,
    performance may drag, specially on receiving.  Everything is ok if run
    in DOS.  It appears to be CEXYZ's multitasking support.  ZSXW works
    fine and gets much better performance under Windows and DESQview.

    DDPLUS: Any door written with DDPlus version 7.1 or earlier, possibly
    later versions too, and possibly DoorDriver, will not work with
    ONEFOSsil if set to use XFOSSIL (otherwise known as the X00 Extended
    FOSSIL mode).  DDPlus driven doors will not even work with X00 in that
    mode.  Instead all calls to the FOSSIL end up in the BIOS COMM
    routines.  This is probably in how DDPlus is detecting an X00 FOSSIL,
    which just plain won't work with ONEFOSsil.  Doors affected by this
    include LORE 2.00, LORD 3.55, USURPER 1.15 and many others.

    Software tested: Renegade BBS, FHSLink, L.O.R.D., Planets: TEOS,
    Usurper, Galactic Overlords, Global War, DoorWay, CEXYZ, RIPVersi,
    LORE, FOSSILC (unreleased version), FOSSILCP (unreleased version),
    B.R.E., Portal of Power, FrontDoor, Intermail, ZSXW, RIPSweeper,
    WildCat!, F.E., Yankees and Rednecks, New York 2008, and many others.

                          Section 8-3: Windows Tips

    During development and testing, some tips for using ONEFOSsil under
    Windows 3.11 and Windows 95 have been collected.  Many thanks to those
    in FidoNet's WIN95 echo for suggesting these tips.  These tips have
    not been tested under Windows 3.11, as it does not have all these
    options.  These suggestions will reduce, if not entirely eliminate,
    CRC errors and increase performance.  Also, these tips are not just
    for ONEFOSsil, but apply to almost all communications under Windows
    95.

    It was found during testing of ONEFOSsil that Windows 95's
    communications drivers have some bugs in how a 16450 UART is
    initialized.  As such, if the first port accessed by a DOS application
    after Windows has been loaded is a 16450 UART port, it is likely that
    the application that uses the port will drop lots of characters,
    specially at higher speeds.  This is not specific to ONEFOSsil as all
    DOS communications software were found to have the same problem.
    Generally, there are no problems if a 16550 UART port is accessed
    before a 16450 UART port is accessed.  The problem also seems to
    disappear once the DOS window has been closed and re-opened.

    One may find communications in Windows 95 to be very temperamental if
    an IRQ above 8 is used for a COM port IRQ (specifically IRQ 9/2).  The
    conditions would come and go from reboot to reboot.  Generally the
    UART's transmit interrupt would be disabled whenever a character was
    received, and could cause system locks.  This was generally made even
    worse when combined with the above problem.  The only solution is to
    try to keep COM ports using IRQ's lower than 8, specifically when the
    UART is a 16450.  It has been heard that some people have also had
    trouble just with IRQ 9/2, no matter what kind of UART, so this
    problem may only be significant with IRQ 9/2.

    The following tip was partially suggested by Bill Gaston on FidoNet's
    WIN95 echo.  Most of the suggestion he posted as been complemented
    with the authors complete testing of the suggestion.  As such, there
    have come to be some differences even between Bill's and the author's
    original publication of this tip.

    Perform the following steps to improve DOS programs performance and
    reliability while running in Windows 95.  This will generally
    eliminate all CRC errors and may solve some performance problems.

         Open the Control Panel.  Open the System icon.  Select the Device
         Manager tab and expand the Ports branch.

         Carry out the following steps on each COM port.

              Select the port in question and press the Properties button.
              The properties on this page are only used as defaults for
              Windows programs; however, make sure everything is correct,
              such as the Flow Control setting should usually be set to
              Hardware.  Press the Advanced... button.  Press the Defaults
              button to set the FIFO values at 3 notches and 4 notches
              respectively.  This works the best for most all systems, and
              appears to apply even to DOS applications.  Press the OK
              button to return to the Properties tab and press the OK
              button there to return to the Device Manager.

                   Note:  Some suggest (often) that the lower slider
                   should be set at the middle notch.  Read the message at
                   the top of the properties tab.  It reads that the right
                   most notches provides better performance, and the left
                   most notches are for solving communications problems.
                   With 16550 UARTs, the right most notch of the lower
                   slider is the best to use for highest performance.

         Close the System Properties window to save the changes.  Open the
         file \Windows\System.ini with an editor.  Make the following
         changes to the [386Enh] section.

              Remove or remark any "COMBoostTime=" statements.  It was
              earlier suggested to add this statement, but the author has
              found that applications perform better without it.

              Add or change the statement "MinTimeSlice=" to read
              "MinTimeSlice=30".  This greatly improves the performance of
              BRE and other door games while they are in the background.
              Adversely, another alternative exists, and this has worked
              quite well on the author's system.  Remove or remark the
              "MinTimeSlice=" statement and add or change the statement
              "WinTimeSlice=" to read "WinTimeSlice=100,100".  This causes
              Windows to give the task in the foreground only as much time
              as the tasks in the background get.

              Add or change the statements "COMxBuffer=y" for each COM
              port used by DOS applications.  The value y is the amount of
              buffer space to be reserved for COMx.  Ideally, a value
              larger than ONEFOSsil's read value should be used.  This
              will greatly improve performance and reliability of DOS
              applications.  Common settings are between 1024 and 10240.
              1024 may work for most people, and will surely improve
              performance, but some systems may need 10240.  The author
              has seen very few systems that didn't need any change in the
              buffers.

         Save the file, close, and restart Windows.  If there continues to
         be problems with CRC errors or dropped characters, increase the
         buffers, or reduce the top slider in the advanced port settings
         page by one notch.  If you have problems with slow transmit
         speeds, try adjusting the "MinTimeSlice=" statement or adding and
         adjusting a "COMBoostTime=".

    On the ONEFOSsil command line, the FIFO settings can be set to F=16,4
    to provide better results on 16550 UARTS.  This sets the FIFO's to
    maximum for both transmit and receive FIFO's.  Since Windows 95 always
    uses its FIFO settings, ONEFOSsil's FIFO settings will only be used
    for transferring data from the Windows VCOMM buffer to ONEFOSsil's
    buffer, and by transferring more characters at a time the performance
    generally increases.

    It is also suggested to run the UART at as high of a speed as can be
    supported by the modem.  This increases performance specially with
    error correcting and data compression modem protocols.  Most 28,800bps
    modems support 115,200bps while most 14,400bps modems support
    57,600bps.

    Just to note, these settings have completely eliminated CRC errors on
    the author's 4 megabyte system on all 16550 UART ports.  Ports using
    16450 UARTs seldom produce CRC errors even running at 38400bps (direct
    link between computers).

                          Section 9: Troubleshooting

    If you can not find an answer here, you are very welcome to read the
    SUPPORT.TXT file and use any valid means for contacting the author to
    discuss the problem.

    This section will be maintained in FAQ (Frequently Answered Questions)
    format.

    Q: I get CRC errors in Windows or Windows 95, can this be solved?

    A: Usually.  Please read Compatibility Notes - Windows Tips, above,
    for more information.  If problems persist, please contact the author
    through the appropriate support channel.  He may want to see your
    system.ini file.

    Q: I have just a couple programs that refuse to work with ONEFOSsil,
    everything else appears to work fine, what can I do?

    A: Contact all authors involved.  The author of ONEFOSsil may be able
    to solve the problem, or provide a work-around, but the best long term
    solution is to correct the bugs other programs may have.  It reduces
    the chances that other problems will be created in the future.

    Q: ONEFOSsil refuses to install, stating that the UART doesn't exist,
    why is this?

    A: ONEFOSsil does a test that almost always insures the UART and the
    interrupt hardware are functioning before loading.  Under
    multitaskers, if another window or task already has the port to
    itself, ONEFOSsil may not be able to recognize the UART (as in the
    case with Windows) or may find the interrupt hardware to be failing
    (as in the case with DESQview).  Try closing all windows or loading
    ONEFOS in DOS.  If it still refuses to work check all settings.  After
    running out of possibilities, attempt to contact the author to see if
    you don't have unsupported UART hardware.  ONEFOS has been tested to
    work on internal modems, 16550's, 16450's, and on 12mhz 80286
    processors.  Even faster machines may provide problems with how
    ONEFOSsil detects UART's, however no problems have been reported yet.

    Q:  I tried to get ONEFOSsil to report its status, or change its
    settings after it has been installed, but I keep getting a command
    line error message, why?

    A:  RTFM!  Those commands are documented above as being unfinished.
    It is the hope of the author to have all ONEFOSsil commands completed
    at revision 10.  At that time the whole project will be given a better
    command line processor, and better help when an error occurs.

    Q:  Does ONEFOSsil work with shared IRQ's under Windows 95?

    A:  As stated in an above section, ONEFOSsil, or any other DOS program
    should work with shared IRQ's provided you have set Windows 95 up
    correctly.  Make sure that Windows 95's device manager reports the
    hardware for your COM ports correctly.

    Q:  Any other questions, anyone?

                             Section 10: Credits

    All trademarks and copyrights mentioned in this documentation are the
    property of their owners.  References to companies or their products
    are in no way an advertisement or a guarantee that this product will
    work with the mentioned products or environments.

    Thanks the most to Ralph Brown and others for the Interrupt List
    (version 48).  Without the Interrupt List and its many other
    components, this project would have flopped from all the misleading
    sources I used. Yes, the Interrupt List is not perfect, but not nearly
    as bad as some of the other sources I used in this project.

    Thanks also to Allen L. Wyatt, Sr. for "Advanced Assembly Language"
    (ISBN 1-56529-037-2) which provided me with just enough (misleading)
    information to start on the project.  Many sample programs contradict
    information shown in the charts, but they all seem to run, and I do
    plan to use more of the book than the "Serial Communications" chapter.

    Thanks also to Ray Gwinn for providing the specifications to his
    slightly advanced FOSSIL specification.  Yes, small errors here and
    there too, but nothing the Interrupt List didn't clear up.  It is also
    his buggy DOS based FOSSIL driver, X00, and his supposed denounce of
    Windows, that prompted for the creation of this driver.  Bob Juge also
    had some help in getting me to write this driver, with his persistent,
    "the X00 specs are publicly available."

    Thanks a little to Barb Maly, for constantly reminding me why she
    didn't use X00, and why I didn't use BNU.  She is also a primary beta
    tester and is the primary distributor.

    Dan Liston gets a little thanks too, for allowing me to test my driver
    on repeated calls to his system.  I know it had to be annoying.

    Thanks to Ralph Wilcox, the registration letters should be easier to
    follow by those who do not use PKUnZip on a normal basis.

    Many thanks to everyone in the FidoNet WIN95 support echo.  Their
    support has helped to make ONEFOSsil more complete.

    <EoF>
