OS2_COM.TXT Serial Utility Diskette 1997 ********************************************************************* Technical Note April, 1994 Subject: OS/2 Serial Communications COM3: OR COM4: SUPPORT ON AN ISA SYSTEM ------------------------------------- The original XT and AT computer allowed for the definition of up to four serial communication ports. However, there has never been any hardware architectural standard that defined the I/O port addresses or Interrupt Request (IRQ) lines associated with communication ports 3 or 4. Over the years, a convention has developed that places the port addresses for COM3: AND COM4: at 03E8 and 02E8 respectively. This is a generally accepted convention, but not yet a standard. Check the documentation and the settings of the adapters in your system to verify your hardware environment. After you have checked and set the I/O and IRQ values on your COM: ports or internal modems, you must add this information to the communications device-driver (COM.SYS) statement in the CONFIG.SYS file. You might also need to tell your communications application software where the COM: ports are. PROCOM software, for example, has a configuration screen that enables you to specify these settings. If the application, operating system, and hardware are not in agreement, then the application will not run. OS/2 COM: ports do not need to be defined in sequence. It is acceptable to have a COM4: without having a COM3:. DOS, however, might have difficulty if there is a gap in the port definition. To avoid confusion for DOS, you can define the COM: ports that do not have any physical adapters attached in the COM.SYS statement. These substitute definitions will serve as placeholders. COM1: and COM2: are assumed to have standard values and do not need to be explicitly set up unless you want to set some non-standard values to accommodate your particular configuration. To enable COM3: or COM4: on an ISA system, place the following in the CONFIG.SYS file: DEVICE=X:\OS2\COM.SYS (n, a, i) (n, a, i) where X = the drive where OS/2 is installed n = the COM: port to access a = communications port I/O addresses (03E8, 02E8, for example) i = IRQ level, which is usually a jumper setting on the I/O adapter For example, to specify that COM3: is at address 03E8 on IRQ5 and that COM4: is at addresses 02E8 on IRQ10, use the following statement (assuming that OS/2 is installed on drive C): DEVICE=C:\OS2\COM.SYS (3,03E8,5) (4,02E8,10) The I/O address and IRQ level should be noted in the documentation that came with your adapter. Either or both may be fixed values or can be set to a range of values via jumpers or switches. In some cases you might find that the values are fixed or that the range of settings available to you is insufficient to avoid the sharing conflict. In that case, you must purchase a different, more versatile adapter or accept that you cannot use both adapters at the same time. TROUBLE SHOOTING: ================ SYMPTOM: The COM: port is not recognized or does not work at all ---------------------------------------------------------------- A. If computer is an AT, ISA, or EISA machine and is trying to use COM3: or COM4:. A.1 Parameters in DEVICE=C: OS2 COM.SYS in CONFIG.SYS are required A.2 IRQ for COM: port in OS/2 must be different for each COM: port. DOS does not handle multiple interrupts at the same time but OS/2 does. A.3 IRQ5 is recommended for COM3:. If IRQ5 is taken, IRQ9 or IRQ10 is recommended. A.4 Reboot the system A.5 If error message during boot : COM3: not installed because Interrupt is already in use. => Check if there is an IRQ conflict with other device driver or hardware. B: If system (AT bus or MCA) boots without error but any of the COM: ports are still not working at all Issue a Mode command to the problem COM: port => If it indicates COM: port not installed check IRQ conflicts (see A.5) => Check Mode command parameters to be correct (see MODE_CMD). SYMPTOM: Application appears to hang -------------------------------------- C: When the application is started: C.1 If an OS/2 application => Ensure your COM: port works in stand alone DOS. => Using MODE command, turn off IDSR, ODSR, and OCTS (see MODE_CMD) => (see SUGGESTIONS) C.2 Using a DOS application => (Start from letter A.1 Above and work down) => If a problem still exist, remove VCOM.SYS. D. After COM: port has been running for some time: D.1 Using an OS/2 application and experiencing a lot of data loss => Lower the baud rate => (see SUGGESTIONS) D.2 Using a DOS application: D.2.1 A BBS communication package. => Set COM_HOLD DOS Setting to ON => If using a FOSSIL Driver, then If X00.SYS Rem VCOM.SYS in CONFIG.SYS, else If another FOSSIL Driver. Rem VCOM.SYS WON'T WORK => If using less than 12MB of memory => (see SUGGESTIONS) D.2.2 A FAX application which uses a COM: port. => Known limitation needed to operate at < 9600 bps => Use OS/2 application for high speed fax. (Currently FAXPM and BitFax) D.2.3 An application which uses QBASIC or BASIC CTTY => Install COMDD.SYS in C: OS2 MODS directory D.2.4 Some other ASYNC applications. - CrossTalk for Windows needs that BUFFER=OFF. - Mirror III is similar to CrossTalk. BUFFER can be controlled with MODE command. - LapLink PRO, IDSR, ODSR, and OCTS of all COM: ports must be OFF. (see MODE_CMD) - LapLink III, remark out VCOM.SYS. D.2.5 In Auto Answer mode and a call comes in: => Known problem APAR PJ04200 => Remark out VCOM.SYS in CONFIG.SYS SYMPTOM : OS/2 does not detect FIFO --------------------------------------- E.1 COM.SYS detects FIFO and utilizes it, however VCOM.SYS will only emulate a 16450 or 8250 chip and hides FIFO from DOS app. No performance problem is caused by this. SYMPTOM: The line is dropped randomly or fails to download file --------------------------------------------------------------- F.1 While switching sessions => change PRIORITY_DISK_IO in CONFIG.SYS from YES to NO, reboot. Go to F.2 below if problem continues F.2 Without switching sessions. => Increase idle sensitivity to 100. => If problem is happening during noticeable disk activity add additional memory to reduce swapping. => Try increasing DISKCACHE in CONFIG.SYS (e.g. from 1024 to 2048) SYMPTOM: Slow through-put, poor performance -------------------------------------------- G.1 Using an OS/2 application => (see SUGGESTIONS) => Using MODE command, turn off IDSR, ODSR, and OCTS. (SEE MODE_CMD) G.2 Using a DOS application => Increase IDLE_SENSITIVITY to 100 => (See SUGGESTIONS) Note: Since interrupt must be simulated in VDM session, the throughput decreases. MODE_CMD: Use MODE from an OS/2 Command line or DOS command line and set IDSR, ODSR, and OCTS EQUAL TO OFF. e.g.: MODE COM3: 9600, N, 8, 1, OCTS=OFF, IDSR=OFF sets COM3: TO 9600, no parity, 8 Data Bits, 1 Stop bit, OCTS, ODSR AND IDSR to OFF. If OCTS and/or ODSR are set to ON, the COM: port will not transmit data unless CTS and/or DSR signal lines are enabled. If set to OFF, the COM: port will transmit regardless of the state of signal lines CTS and/or DSR. If IDSR is set to ON, the COM: port will discard the incoming data unless DSR signal line is enabled. If set to OFF, the port will receive data regardless of the state of DSR. If any problems transmitting or receiving, set OCTS=OFF, ODSR=OFF, IDSR=OFF to ensure that the hardware connected to the COM: port is not preventing the port from transmitting or receiving. SUGGESTIONS: => Increase IDLE_SENSITIVITY in DOS settings => Adjust the disk cache in CONFIG.SYS => Change PRIORITY_DISK_IO from YES to NO in CONFIG.SYS => To reduce swapping add more memory ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Additional Information: The 16550 provides for a 16-character receive hardware buffer that can be set to generate an interrupt every 1, 4, 8 or 14 characters. It can also hold up to 16 characters in a transmit buffer, generating an interrupt only when that buffer is empty. In other words, in its most efficient mode, the 16550 can handle transmission and receipt of data in roughly 16-byte chunks, only interrupting the CPU at the end of each chunk. Note that even if you don't make use of the extended buffering from the point of view of interrupt handling, but still receive an interrupt for every character received or transmitted, the 16550 buffer can be helpful, as it can buffer received characters if the COM: handler misses an interrupt, thereby preventing receive overruns. The OS/2 COM: driver can fully exploit these capabilities of the 16550 depending on how it is configured. Here's the problem - if you take the default COM: settings, and even if you use MODE to set the BUFFER parameter to AUTO, the COM: driver is only partially using the capabilities of the UART. COM: Driver Settings (MODE): -------------------------- The extended hardware buffering mode of the async driver can be controlled via the BUFFER parameter of the MODE command. It can take on three values: ON Set transmit/receive triggers to fully exploit buffering. (16-character transmit/receive queues for 16550). OFF Set transmit/receive triggers to a single character. AUTO "Automatic Protocol Override". Adjust the transmit/receive triggers according to handshaking protocols in effect. The "handshaking protocols" for AUTO mode use the following signals: RTS = Request To Send ( Signals FROM OS/2 COM: Driver ) DTR = Data Terminal Ready CTS = Clear To Send ( Signals TO OS/2 COM: Driver ) DCD = Data Carrier Detect DSR = Data Set Ready and refer to the following: * Input Sensitivity using DSR - MODE option IDSR, default ON - If this setting is ON, then the driver will only accept data from the device while the DSR line is active. * Output Handshaking using CTS, DSR, DCD - MODE options OCTS, ODSR, default is both ON - No MODE option for DCD - MODE always sets it OFF - This setting controls whether CTS, DSR or DCD are used to control the flow of data to the modem. If any of these settings are ON, the driver stops giving data to the transmit hardware as soon as the corresponding control signal drops. * RTS Control Mode - MODE option RTS, default is ON. Can be one of the following: + Enabled [MODE=ON] + Disabled [MODE=OFF] + Input Handshaking (RTS drops on input queue full) [MODE=HS] + Toggling on Transmit (RTS drops unless transmitting) [MODE=TOG] - This setting controls how the RTS signal is controlled by the driver. If ON, DTR is used to signal when the COM: port is active, while if HS, DTR is used to control the flow of data from the modem. * DTR Control Mode - MODE option DTR, default is ON. Can be one of the following: + Enabled [MODE=ON] + Disabled [MODE=OFF] + Input Handshaking (DTR drops on input queue full) [MODE=HS] - This setting controls how the DTR signal is used to control the flow of data. - This setting controls how the RTS signal is controlled by the driver. If ON, DTR is used to signal when the COM: port is active, while if HS, DTR is used to control the flow of data from the modem. A typical default configuration for the COM: port is (ignoring some of the MODE parameters not relevant to this post): IDSR = ON ODSR = ON OCTS = ON DTR = ON RTS = ON BUFFER = AUTO Setting Interaction: ------------------- For the purposes of this article (getting the most performance out of the 16550), the only settings that are really important from the above discussion are the "Extended Hardware Buffering" (BUFFER), "Input Sensitivity using DSR" (IDSR), and "Output Handshaking using CTS, DSR, DCD" (OCTS,ODSR). Here's the basic problem. In order to accomplish the latter two settings in their default modes, the AUTO buffering mode basically stops using the FIFO buffers. In particular, the following adjustments are "automatically" made: * If IDSR is enabled, then the COM: driver is set up to respond to a lowering of the DSR signal within one character time. To ensure this, the driver adjusts the receive trigger to be a single character. In other words, it lets the 16550 generate an interrupt per character. The full 16-character receive buffer is still available to prevent receive overruns, and the transmit trigger is not adjusted. * If either OCTS, ODSR (or ODCD - only changeable from a program) are enabled, then the device driver will respond to a lowering of the appropriate signal within a single character time. To do this, the transmit trigger is lowered to a single character - the 16550 is set to generate a transmit interrupt for each character, although the receive trigger is not adjusted. The reason both of these automatic adjustments are made is to take the safe course, and assume that anything using these signals have been designed to assume that the signals take action within a single character time. For example, without fixing the transmit trigger, the modem could lower the CTS signal, but the 16550 might continue transmitting up to 15 characters that might still be in the FIFO transmit queue. Of course, the problem is that with the default settings, both of these rules come into effect, and the driver ends up getting an interrupt per character for both transmitting and receiving characters. In other words, you end up using the 16550 just like any lower UART, with the single advantage that the receive FIFO buffer on the chip helps avoid receive overruns. Improving Settings ------------------ In order to make more effective use of the 16550, you can do one of three things: * Explicitly set the extended buffering on (MODE BUFFER=ON). * Disable IDSR sensitivity (MODE IDSR=OFF) * Disable any output flow control (MODE OCTS=OFF,ODSR=OFF) Of the three, the former is preferred, but you may have reasons to do one of the latter two. By explicitly setting the buffering on, you will override the rules above that adjust the receive and transmit triggers. What this means is that you may receive extraneous data if DSR is actually being used to signal input and that if the modem asks the driver to stop sending data (CTS), it may still receive up to 15 more characters. This problem should not effect most modem users. Most modems hold DSR high while they are on (or at least are configurable to do this), and most modems that handle hardware flow control (RTS/CTS) drop CTS before they are absolutely out of room. Summary ------- An important aspect of the support for 16550 UARTs within the OS/2 2.0 COM: driver is the interaction between various modem control handshaking settings and the automatic control of extended buffering. In particular, several of the default COM: port settings (IDSR=ON,OCTS=ON,ODSR=ON) when automatic control (BUFFER=AUTO) is enabled force the driver not to use the enhanced buffering of the 16550, and instead generate interrupts for each character transmitted or received. This can decrease performance and definitely places a heavier load on the machine. The easiest way to solve this is to use a setting of BUFFER=ON rather than BUFFER=AUTO, as long as it won't cause problems overrunning your modem or receiving extraneous information (see "Improving Settings" above). For the DOS Box, one hint to users trying to get reasonable performance out of DOS COM: applications - BUFFER=ON may also help this situation, but if you can live with 9600 baud, and your application supports using the BIOS interface to the COM: port, try using that mode. You may be to run the application successfully at higher data rates through the emulated BIOS interface than if the application tries to use the emulated COM: hardware directly. --------------------------------------------------- For technical support, refer to your user manual or the label on your software utility disk for the appropriate correspondence.