(c) Copyright 1991 Bio-Engineering Research Laboratories, Berkeley, CA This document may not, in whole or in part, be copied, photocopied, translated, or reduced to any electronic medium or machine readable form without prior written consent from Bio-Engineering Research Laboratories. About your SINGLE USER LICENSE of TurboCom(TM) TurboCom is a commercial product developed by John Loram at Bio-Engineering Research Laboratories, Berkeley, CA. TurboCom was developed on a speculative basis in response to the perceived need for improved Asynchronous communications capabilities under Microsoft Windows 3.0. The Single User License, printed on the envelope in which TurboCom is packaged, grants specific rights. Please take a few minutes to read and understand the extend of these grants. We have tried to make the elements of the Single User License as unencumbering as possible while protecting the substantial effort that has been made to provide a useful product. TurboCom is not a shareware product. Please do not share it with your friends and associates, even on a trial basis. You may of course test TurboCom on any system and as many systems as you wish, so long as the Single User License agreement is not violated. A copy of the Single User License appears at the end of this document for your reference. TurboCom is available under single user licenses, site licenses, and licenses for bundling with other software and hardware products. Quantity discounts are available for single user and site licenses. For further information contact John Loram at: Bio-Engineering Research Laboratories 2831 Seventh St. Berkeley, California 94710 (415) 540-8080 Basic Installation Installing TurboCom is a five step process. It may be accom- plished while in Windows or DOS. 1) Copy the three files named TURBOCOM.DRV, TURBOVCD.386, and TURBOBUF.386 from the TurboCom distribution disk into the \WINDOWS\SYSTEM sub-directory. If your system is based on the 80286 processor you need only copy TURBOCOM.DRV. 2) Copy the file named TURBOCOM.SYS from the TurboCom distribu- tion disk to the directory in which you keep your DOS .SYS files. On many systems this would be the root directory of the boot volume (e.g. C:\). TURBOCOM.SYS is not required for IBM PS/2 Microchannel models 50 and above. 3) Append the contents of TURBOCOM.INI from the TurboCom distri- bution disk to your Windows SYSTEM.INI file, which you will find in your main \WINDOWS sub-directory. Make sure that TURBOCOM.INI is appended to the SYSTEM.INI file, not to one of the other .INI files located in this sub-directory. 4) Find and modify the following profile strings in your SYSTEM.INI file: In the [boot] section of SYSTEM.INI: change profile string comm.drv=comm.drv to read comm.drv=TurboCom.drv In the [386enh] section of SYSTEM.INI make two changes (unnecessary for 286 machines): change profile string device=*vcd to read device=TurboVcd.386 change device=*combuff to read device=TurboBuf.386 5) Add the following line to your CONFIG.SYS file: DEVICE=TURBOCOM.SYS This line must appear in the CONFIG.SYS file before any line which loads a driver involving Com ports such as a serial port mouse driver, or a serial port network driver. It can be safely placed as the first device driver in the CONFIG.SYS file. TURBOCOM.SYS is not required for IBM PS/2 Microchannel models 50 and above. How Does TurboCom Work TurboCom works on three levels to greatly improved Windows and DOS asynchronous communications performance. Level 1 Improvements - Comm Port hang-ups and COM3/4 availability: TurboCom.sys is a DOS device driver that extends the boot-time system initialization functions of the ROM BIOS of your ISA based system. Few ISA ROM BIOSes make provisions to initialize COM3 and COM4 hardware and the associated ROM BIOS data area where comm port base addresses are stored. No ROM BIOS for ISA based system properly initialize the 16550 UART. The result of these limitations is that many systems cold boot with their serial port hardware incompletely initialized, and warm boot with their UARTs in unpredictable, often inaccessible states. TurboCom.sys performs proper hardware initialization of 8250, 16450, and 16550 UARTs, and builds a complete UART data table in the ROMBIOS data area of system RAM. It then reports the results of its efforts and discoveries and exits without taking up system RAM. Level 2 Improvements - Windows Comm Port bugs and 16550 UART support: TurboCom.drv and TurboVCD.386 comprise the two basic Windows Comm Drivers. TurboCom.drv is the Windows 3 Comm Driver. It provides the application program interface (API) for Windows applications which use the serial and parallel ports, and the interrupt level routines for Real and Standard mode operation. Two bugs, one dealing with comm port hangups during high-speed full duplex operations and another causing IRQ conflicts were corrected. The interrupt level code was restructured to make it more efficient standard UARTs, and take better advantage of the high performance hardware features of the 16550 UART. TurboCom brings new levels of performance to Windows Asynchronous port usage by providing support for the hardware buffers in the 16550 high performance UART. The sixteen byte transmit and receive buffers of the 16550 UART make it highly resistant to the often poor interrupt response time of multi-tasking environments like Windows. In addition, with the 16550 UART's ability to collect multiple characters before issuing an interrupt, the receive and transmit interrupt overhead can be reduced by as much as an order of magnitude. Level 3 Improvements - DOS Comm support and 16550 access: TurboBuff.386 provides a RAM based UART buffer for DOS applications running under enhanced mode Windows. TurboBuf collects characters from the UART into a system RAM buffer while a DOS application is switched out. When the application is switch in during its time-slice, TurboBuf provides the collected characters to the DOS application by simulating the UART, interrupts and all. Performance Tuning TurboCom Windows and DOS Applications TurboCom provides a number of performance modifying parameters which can be placed in the TurboCom section of the SYSTEM.INI file. Some of them are quite esoteric and will not need to be change in most systems. Others, will likely be changed by every user. First, a little about the purpose and structure of your SYSTEM.INI file. The SYSTEM.INI file is similar in function to the DOS CONFIG.SYS file; it tells Windows which Windows device drivers to load, and it allows those device drivers access to user supplied configura- tion information. The SYSTEM.INI file's contents are composed of sections in the format of [SectionName] (note the square brackets) and profile strings in the format of Profile=String (note the equal sign). Profile=Strings are always associated with the specific [SectionName] which proceed them. Should another [SectionName] inadvertently be placed between a Profile=String and its associated [SectionName], the association is broken and strange unpredict- able events will almost certainly occur, often at boot time but sometimes much later. Make a copy of your SYSTEM.INI file before you change it and keep the copy in a separated directory. Identifying the Communications Device Windows and DOS Applications COMxDeviceType=n, default n = 16, legal values = 0, 1, 2, or 16 If your system does not exclusively use 16550 style UARTs, you will want to change one or more of the COMxDeviceType profile strings to reflect your actual hardware configuration. TurboCom does a good job of identifying which kind of communica- tion devices (e.g., UARTs) are available in your system. How- ever, should you wish to turn off the use of the advanced features of whichever device has been detected, you can. TurboCom will override inappropriate choices and tell you about it. To force device identification, change the following lines(s) of text in your SYSTEM.INI file, in the [TurboCom] section. COMxDeviceType=n Where x = the Com port number 1, 2, 3 or 4, and n is the identi- fier for the communications device: 0 = unknown, 1 = 8250 / 8250-B style UARTs, 2 = 8250A / 16450 style UARTs, 16 = 16550 style UARTs For example; COM1DeviceType=16 tells TurboCom that Com port 1 is a 16550 style UART. COM3DeviceType=0 tells TurboCom to treat the Com3 device as the simplest of communication devices, which is currently the same as choice #1, the 8250 / 8250-B. Setting High Baud Rates Windows Applications If you wish to use baud rates above the 19,200 limit imposed by the standard Windows Comm driver, the COMxBaudX profile string allows you to do so. COMxBaudX=n, default n = 1, legal values = 1, 2, or 3: Most commercial Windows applications only provide for baud rate settings of 19,200 baud and below. This is because the standard Windows Comm driver rejects any attempt to set a higher rate. Since TurboCom performs well at 57,600 baud in fast machines, you can multiply the nominal baud rate by a factor of two (2) or three (3) on a per channel basis. To multiply the baud rate set by your Windows application, change the following line(s) of text in your SYSTEM.INI file, in the [TurboCom] section. COMxBaudX=n Where x = the Com port number 1, 2, 3, or 4, and n = the baud rate multiplier 1, 2, or 3. For example; COM2BaudX=3 will multiply an application set baud rate of 19,200 baud to an actual 57,600 baud for Com2. COM4BaudX=2 will multiply an application set baud rate of 19,200 baud to an actual 38,400 baud for Com4. TurboCom will reject attempts to set rates above 19,200 baud on ports that do not have high performance hardware (e.g., 16550 style UARTs). The TurboCom API allows a Windows application to directly set baud rates up to 57,600 baud if the appropriate UART is avail- able. Setting the Receiver FIFO Interrupt Trigger Level Window and DOS applications Note: This is really high tech stuff, and is here mostly for the un-reconstructed hacker. Unless you really enjoy tinkering, there is probably no reason to change the Receive FIFO Interrupt Trigger Level. COMxRcvTrigLvl=n, default n = 8, legal values 1, 4, 8, or 14 The 16550 UART has two 16 byte fifos (First In First Out buffers). One is for incoming (received) characters, and the other for outgoing (Transmitted) characters. These two fifos are the 16550's distinguishing features, and are key to the perform- ance enhancements that TurboCom provides. Associated with the Receive Fifo, is the Receive Fifo Interrupt Trigger Level. This programmable value determines to what level the receive fifo must be filled by incoming data, before the UART will issue a service requesting Data Available interrupt. You may set this variable to one of its four legal values 1, 4, 8, or 14. If your Windows applications lose incoming characters when your system is very active, you might try reducing this variable from the default of 8 to 4 or even 1. If you are serious about dinking with this variable you should probably become thoroughly familiar with the technical issues concerning the 16550 UART (get a data sheet) and the interrupt response time of you system. To set this variable, change the following line(s) of text in your SYSTEM.INI file in the [TurboCom] section. COMxRcvTrigLvl=n Where x= the Com port number 1, 2, 3, or 4, and n= the trigger level 1, 4, 8, or 14 For example; COM3RcvTrigLvl=14 means that the UART will not issue a Data Available interrupt until it has collect 14 bytes of data. It can receive 2 more bytes before it absolutely must be serviced, or a data overrun will occur. If you're wondering what happens if just 13 characters come in, the answer is that the UART has a timer. That timer will cause an interrupt if data sits in the UART for four character times without another character being received or the fifo being ser- viced. Setting the Transmit Fifo Filling Level Windows and DOS Applications Note: This is another item for the hacker. Unless you really enjoy tinkering, there is probably no reason to change the Trans- mit Fifo Filling Level. COMxTxDepth=n, Default n = 8, legal values 1, 2, 3......, 16 Each time the Transmit Fifo becomes empty, the UART issues a service requesting Transmit Fifo Empty interrupt. While an empty Transmit Fifo could be filled with as many as 16 characters, there may be times when this is not desirable. Certain flow control issues might make it desirable to stop transmitting characters before the 16 byte fifo is empty, and there is no mechanism in the 16550 UART to accomplish this. The only option is not to fill the Transmit Fifo so full. To set the number of characters placed in the Transmit Fifo on each Transmit Fifo Empty interrupt, place the following line(s) of text in your SYSTEM.INI file, in the [TurboCom] section. COMxTxDepth=n Where x = the Com port number 1,2,3 or 4, and n = the fill level 1,2,3....., 16 For example: COM3TxDepth=12 means that each time the Com3 Transmit Fifo Empty interrupt is serviced, the Transmit Fifo will be filled with 12 characters from the Transmit Queue, if that many are available. Setting the COMM Buffer Size DOS Applications If your DOS applications running under enhanced mode Windows are experiencing character overruns (lost received characters) this section is for you. COMxBuffer=n, Default n = 128, legal values 0, 1, 2......, 10000 In traditional (UNIX, VMS, etc.) multi-tasking environments, inter- rupt level services are provided by the operating system. All applications are required to use these services to access the hard- ware. Enhanced mode Windows is unique in that each Virtual Machine (VM) provides its own hardware drivers. The Serial Port Drivers, (Comm Drivers) for the Windows VM (Comm.drv, or TurboCom.drv in our case) are provided with the Windows package. The Serial Port Drivers for DOS applications running under Windows are provided either by DOS or by the DOS application itself. The question then arises, what shall we do with a character received by a UART which is "owned" by a VM (DOS application) that has been switched out. TurboBuf provides an answer, by providing a buffer in system RAM for each comm port. TurboBuf collects characters from the UARTs, places them in buffers, and then when the VM (DOS application) which owns a comm port is active, TurboBuf delivers the characters by simulating the UART, interrupts and all. In this way even 16550 unaware DOS applications benefit from its high performance features. To set the number of bytes buffered for DOS applications, place the following line(s) of text in your SYSTEM.INI file, in the [TurboCom] section. COMxBuffer=n Where x = the Com port number 1,2,3, or 4, and n = the size of the buffer in bytes, 0, 1, 2..... 10000 For example: COM2Buffer=512 means that TurboBuf will provide a 512 byte buffer for the COM2 serial port. This buffer would be large enough to hold about one half second's worth of characters at 9600 baud. If you assume that there are three VMs active, Windows and two DOS appli- cations, and that the minimum time slice is set to the default value of 20 milliseconds, then 512 bytes would be more than sufficient. Setting the COMM Boost Time Windows and DOS applications If your Windows or DOS applications are experiencing sluggish comm performance, character overruns (lost received characters), or loss of keyboard characters under enhanced mode Windows, this section is for you. COMBoostTime=n, Default n = 2, legal value 0, 1, 2......, ? This setting gives a VM addition time each time it receives an inter- rupt from an comm port. Since TurboCom and a 16550 UART result in substantial reductions in interrupt overhead it may not be necessary to ever increase this value. If you give a VM too much additional time using this method, it can quickly hog the whole system. There is only one COMBoostTime profile string for all comm ports. To set the number of milliseconds additional time upon each owned comm interrupt, place the following line of text in your SYSTEM.INI file, in the [TurboCom] section. COMBoostTime=n Where n equals the number of additional milliseconds operating time granted to a VM upon receipt of each comm interrupt. For example: COMBoostTime=5 will give the VM an additional 5 milliseconds of oper- ating time each time it receives an interrupt from a comm port which it owns. Hardware: I/O Addresses, port availability, Interrupts, and Com Port Lockups If you have experienced difficulties with Windows' Message Boxes that proclaim "The COMx port is currently assigned to a DOS application. Do you want to reassign the port to Windows?", and then when you answer in the affirmative nothing happens. Or, Com ports that work one minute but not the next, this section is for you. It will give you some understanding of the roots of your travail, and an explanation of how TurboCom will help. I/O addresses and Port Availability: A Windows Comm driver looks in a dedicated area of RAM to find the addresses of your system's (up to) four Com ports. This RAM area is initialized by the system ROM BIOS at boot time. Only a few very recent ROM BIOSes are fully aware of Com3 and Com4 and correctly initialize this data area. If the data area is not properly initialized, and the address the Windows Comm driver finds is ZERO, Windows will make assumptions that depend: upon whether Windows is operating in Real/Standard vs. Enhanced mode, upon whether it is looking for Com1/Com2 or Com3/Com4, upon whether the bus structure is the ISA vs. EISA/MCA, upon the Model and Submodel data in the ROM BIOS and finally, upon quantity and the base addresses of the Com ports in you system. The permutations and combinations have created a great deal of misunderstanding and confusion. All of this is made more complex by a Com port addressing incon- sistency between the Windows Comm driver COMM.DRV and the en- hanced mode Virtual Machine Comm driver *VCD. However, all the addressing and availability problems are re- solved if the dedicated area of RAM has the correct information about Com port addresses, and the addressing inconsistency be- tween the Windows Comm driver and the Virtual Machine Comm driver is corrected. TURBOCOM.SYS is provided to properly initialize the data area and TURBOVCD.386 corrects the addressing inconsistency. TURBOCOM.SYS is not required for IBM PS/2 Microchannel models 50 and above. TURBOCOM.SYS, in part, acts as an extension of the ROM BIOS. When loaded by the CONFIG.SYS file at DOS boot time, TURBOCOM.SYS searches for four Com ports, places their addresses in the dedi- cated RAM area, and reports its findings. TURBOCOM.SYS also permits the user to optionally enter load line arguments (switches) which extend the search for Com ports to non-standard I/O addresses, and force a specific physical-to-logical mapping of Com ports that are found. Up to four switches may be entered, one for each logical Com port. For example, if your ISA system has four Com ports at the quasi- standard addresses of 3f8h, 2f8h, 3e8h, and 2e8h, the TURBOCOM.SYS load line in your CONFIG.SYS file might be: DEVICE=TURBOCOM.SYS /3f8 /2f8 /3e8 /2e8 This would make the following assignments: Logical port Physical port Com1: = 3f8h Com2: = 2f8h Com3: = 3e8h Com4: = 2e8h You could reverse the Logical to Physical connection with the following load line: DEVICE=TURBOCOM.SYS /2e8 /3e8 /2f8 /3f8 Which would make the following assignments: Logical port Physical port Com1: = 2e8h Com2: = 3e8h Com3: = 2f8h Com4: = 3f8h If you choose to use a non-standard arrangement of Com port addresses, be aware that many DOS based communications programs make their own Logical to Physical associations, and pay no attentions to those provided by the ROM BIOS. Conflicts of Com port associations between Windows and DOS based applications lead to great confusion and grief! TURBOCOM.SYS is 16550 UART aware, and will properly initialize these high performance devices. Interrupt sharing and Com Port Lockups: While simultaneous hardware interrupt sharing is not possible in the ISA bus environment without special serial port hardware, it should be possible to share hardware interrupts on a sequential basis. However, because of a conceptual error in the Windows Enhanced mode Virtual Comm driver, interrupt sharing of any kind with Windows in an ISA bus environment will lead to Com port lockup. Once a Com port has been acquired by a process (i.e., a Windows or DOS application) the hardware interrupt associated with that Com port will become permanently unavailable to the other serial port sharing the interrupt. If the other serial port, which shares the interrupt, is subsequently activated it will also claim the hardware interrupt. At this point neither port will operate, yet neither port will completely relinquish the interrupt. The only solution is a power off re-boot of your system. Even a warm boot is not enough because of limitations in most ROM BIOS. TURBOVCD.386 corrects this problem and allows serial ports to be passed about with abandon, provide the one-at-a-time on an IRQ restriction is observed. The follow is a reproduction of the Single User License AGREEMENT print on the sealed disk package in which TurboCom is shipped is provide here for your convenience. Should there be any difference between this reproduction and the original on the sealed disk package, the original shall prevail. TURBOCOM LICENSE AGREEMENT BY OPENING THIS SEALED DISK PACKAGE, YOU AGREE TO THE TERMS OF THIS AGREEMENT WITH BIO-ENGINEERING RESEARCH LABORATORIES. IF YOU DO NOT AGREE TO THE TERMS OF THIS AGREEMENT, PROMPTLY RETURN THE UNOPENED DISK PACKAGE AND THE ACCOMPANYING MATERIALS TO THE PLACE YOU OBTAINED THEM FOR A REAL REFUND. This agreement supersedes all prior agreements and understandings between you and Bio-Engineering Research Laboratories regarding the TurboCom driver. SOFTWARE LICENSE 1. The enclosed software is protected by both United States copyright law and international treaty provisions. Therefore, you must treat this software like a book, with the following single exception. You are authorized to make archival copies of the software for purposes of backup to protect your investment from loss. 2. By saying "like a book" we mean, for example, that this software may be used by any number of people and may be freely moved from one computer location to another so long as there is no possibility of it being used at one location while it is being used at another. Just like a book that cannot be read by two different people in two different places at the same time, the software may not be used by two different people in two different places at the same time. 3. The software is licensed to you and title to the software is retained by Bio-Engineering Research Laboratories. You may not rent or lease the software but you may transfer the software and accompanying written materials on a permanent basis provided you retain no copies and the recipient agrees to the terms of this agreement. If the software is an update, any transfer must include the update and all prior versions. 4. You agree that you will not reverse, engineer, decompile or disassemble the software. LIMITED WARRANTY 5. Bio-Engineering Research Laboratories warrants the physical disk and the accompanying physical documentation to be free of defects for a period of thirty days from the date of purchase. In the event of notification within the warranty period of defects, Bio-Engineering Research Laboratories will replace the defective disk or documentation. The remedy for breach of this warranty is limited to replacement and shall not encompass any other damages, including but not limited to loss of profit, and special, incidental, consequential or other similar claims. 6. Bio-Engineering Research Laboratories specifically disclaims all other warranties, expressed or implied, including but not limited to implied warranties of merchantability and fitness for a particular purpose, with respect to the disk, accompanying documentation, and the program license granted herein. In no event shall Bio-Engineering Research Laboratories be liable for any loss of profit or other commercial damage, including but not limited to special, incidental, consequential or other damages. GENERAL 7. For purposes of licensing to any agency of the United States government, the software and documentation are provided with RESTRICTED RIGHTS. 8. This agreement is governed by the laws of the State of California and is enforce- able by Bio-Engineering Research Laboratories and/or its resellers and distributors. The prevailing party in any action brought in connection with an alleged infringement of proprietary rights in the enclosed software will be entitled to recover its costs and expenses, including attorneys fees. Bio-Engineering Research Laboratories - 2831 Seventh St., Berkeley, Califorina (415) 540-8080