Bila Vrana

home *** CD-ROM | disk | FTP | other *** search

/ Bila Vrana / BILA_VRANA.iso / 019A / ONEFOS09.ZIP / ONEFOS.TXT < prev next >

Wrap

Text File | 1996-06-15 | 43.9 KB | 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>