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.
Download Driver Pack
After your driver has been downloaded, follow these simple steps to install it.
Expand the archive file (if the download file is in zip or rar format).
If the expanded file has an .exe extension, double click it and follow the installation instructions.
Otherwise, open Device Manager by right-clicking the Start menu and selecting Device Manager.
Find the device and model you want to update in the device list.
Double-click on it to open the Properties dialog box.
From the Properties dialog box, select the Driver tab.
Click the Update Driver button, then follow the instructions.
Very important: You must reboot your system to ensure that any driver updates have taken effect.
For more help, visit our Driver Support section for step-by-step videos on how to install drivers for every file type.