OS/2 Professional/OS2PRO194.ISO/os2/info/faq/os2_20/os2help/comsys.fax

Text File | 1992-09-17 | 8.2 KB | 175 lines

  INTERRUPT PROBLEMS ON AN ISA SYSTEM

  On an ISA system, having a shared interrupt-request line can cause problems.
  ISA systems have what are called "edge triggered" interrupts whereas Micro
  Channel and EISA systems use "level sensitive" interrupts.  "Edge triggered"
  interrupts can only be sensed for a very short period of time.  If a second
  interrupt arrives from another adapter while the first interrupt is still
  being processed, the second interrupt will be lost.  In your computer system,
  this situation can lead to various difficulties such as printers that do not
  seem to print smoothly or reliably, or communications sessions where some
  characters are getting lost.

  However, with single-tasking systems such as DOS, the two adapters that are
  sharing the interrupt might never cause any real problems because they might
  never be in use at the same time.  OS/2 2.0, however, presents a different
  set of problems.  If you have multiple serial communications adapters, there
  is a greater probability that you might try to use two or more of them at the
  same time.  If some of them have previously been set up using shared
  interrupts, problems can occur that probably didn't happen in DOS.

  OS/2 2.0 can detect that an interrupt line is shared and will not allow
  simultaneous use.  Assume that COM1 and COM3 are sharing Interrupt Request
  line 4 (IRQ4).  If you try to use both COM ports at the same time, the OS/2
  operating system will not allow the second one to start.  A well-written OS/2
  communications program will recognize that the port cannot be opened and an
  error message will be displayed.  A DOS application, however, is unprepared
  to respond to this unfamiliar situation.  It will probably suspend, waiting
  for the port that will not open.

  Another potential source of trouble is having multiple hardware adapters that
  are sharing the same I/O address.  The various hardware adapters in your
  computer must have their own addresses.  Consider what might happen, for
  example, if the commands that were meant for your printer were instead routed
  to your disk drive.

  The solution for all of these problems is to ensure that all your hardware
  adapters have their own unique I/O addresses and IRQ assignments.


  COM3 OR COM4 SUPPORT ON AN ISA SYSTEM

  The original ISA machine (the IBM PC-AT) 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 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.  ProComm 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 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 that you are attempting to access
   a = communications port I/O address (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 address 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 might 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.


  SETTING THE INTERRUPT REQUEST (IRQ) LEVEL ON AN ISA SYSTEM

  The following information will help you determine what IRQ settings you can
  use for COM3 or COM4 port adapters to avoid shared interrupts.

  On an ISA machine there are a total of 15 IRQ levels available.  Many of
  these are already being used.  Most are already in use because they are the
  the standard settings for the more common devices.  These standard settings
  are as follows:

  IRQ LEVEL      DEVICE ASSOCIATED

  0              System Timer

  1              Keyboard

  2              Secondary Interrupt Controller  (see note)

  3              COM2 (Serial Communications Port 2)

  4              COM1 (Serial Communications Port 1)

  5              LPT2 (Parallel Port 2)

  6              Diskette

  7              LPT1 (Parallel Port 1)

  8              Realtime Clock

  9              open

  10             open

  11             open

  12             open

  13             Math Coprocessor

  14             Hard Disk

  15             open

  NOTE:  On the IBM-AT (ISA bus), the IRQ9 pin is identical with the IRQ2 pin
         on the original IBM-PC.  If you have an older, 8-bit adapter whose
         documentation states that it uses IRQ2, be aware that this will
         actually be interpreted as IRQ9 when plugged into the 16-bit ISA bus.

  The IRQ levels shown as "open" have no established, standardized use.  When
  setting the IRQ values on your COM3 or COM4 ports, you are likely to find
  these levels available to use without conflict with some other adapter.
  Furthermore, if you don't have two parallel ports installed, IRQ5 might be
  usable for some other purpose, such as COM3 or COM4.  Be cautious about doing
  this because it might cause a problem later if you decide to install a second
  parallel port.  In addition, some other non-standard device might already be
  using IRQ5.

  When trying to manage the IRQ levels of your various hardware adapters to
  avoid conflicts, you may find that your 8-bit adapters cause problems.
  Except for IRQ9, only 16-bit adapters are configurable to use IRQ levels
  higher than 7.  A glance at the IRQ table will also show that the
  low-numbered IRQ lines already have some standard function assigned.  It

  might be that your only alternative for avoiding some IRQ conflicts is to
  purchase a more versatile 16-bit adapter.

  If you have non-standard 8-bit adapters, be especially careful of interrupt
  conflicts.  For example, the SoundBlaster adapter is configured at the
  factory to use IRQ7.  IRQ7, however, is the standard assignment for LPT1, the
  first printer port.  This conflict might not be apparent with DOS because DOS
  printing typically does not use the interrupt line.  OS/2 2.0, however,
  requires it, and the hidden conflict can become the source of printing
  problems.  It is also fairly common to discover that the interrupt feature on
  your parallel port adapter does not work.  In DOS, this might not have any
  effect.  In OS/2 2.0, however, your printer might be very erratic or not work
  at all.