home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.wwiv.com
/
ftp.wwiv.com.zip
/
ftp.wwiv.com
/
pub
/
GENUTIL
/
ONEFOS09.ZIP
/
ONEFOS.TXT
< prev
next >
Wrap
Text File
|
1996-06-15
|
45KB
|
852 lines
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>