Release Notes PN 93000127M1P
                              for
                Digi Asynchronous Driver Package for QNX 4.X
                         Version 2.1.0q.

          Quantum Software Systems QNX version 4.22 - 4.25

          Software Package        P/N 75000127M1P
          Diskette (3.5")         P/N 40000754M1P  
          Software Manual         P/N 92000127D

                        May 31, 2002



                   Digi Xi, Xe, Xr, Xem, C/X, COM/Xi


INTRODUCTION
    This Digi software package includes device drivers for the Acceleport
    Xe, Acceleport Xr, Acceleport Xem Acceleport C/X, Xi and COM/Xi
    families of adapters.  It is currently supported on QNX 4.23-4.25.

    Note : This package includes two separate device drivers named 
           Dq.ser16 (for 16 bit environments) and Dq.ser32 (for 32
           bit environments).  Please consult the manual for proper
           installation instructions.


SUPPORTED PRODUCTS

    ISA Bus
    -------
    Acceleport Xe               2e, 4e, 8e         (EIA232 & EIA422)
    Acceleport Xr               4r & 8r            (EIA232 & EIA422)
    Acceleport Xem              4-64ports          (EIA232 & EIA422)
    Acceleport C/X              8-128ports         (EIA232)
    PCI/Xi, COM/Xi

    PCI Bus
    -------
    Acceleport Xem              4-64ports          (EIA232 & EIA422)
    Acceleport Xr               4r & 8r            (EIA232)
    Acceleport C/X              8-128ports         (EIA232)
    Acceleport Xr/422           4r/422, 8r/422     (EIA422)
    Acceleport 2r/920           2r/920             (EIA232)
    Acceleport 4r/920           4r/920             (EIA232)
    Acceleport 8r/920           8r/920             (EIA232)

    Microchannel Bus
    ----------------
    MC/Xi



ENHANCEMENTS

  * Added support for the 2 port PCI XR 920

  * Added support for the PCI XR-422

  * Added -P command line option for setting FEP polling interval
   (FEPPOLL) for improved latency response.

  * Update to latest on-board operating system (BIOS and FEP) files.

  * Added "-x" option for setting default runtime priority of the driver.

  * Added ability to specify outgoing BREAK duration by implementing
    IOCTL_STARTBREAK and IOCTL_STOPBREAK ioctls.

  * Added ability to determine and report length of incoming BREAKs.
    This consists of two parts:

    1.  Getting bitmap values to qnx_ioctl().  Dev.ser implements a status
        bitmap that is user-accessible via qnx_ioctl() and is described
        in /usr/local/system/qioctl.h.  Previously, the BREAK bit was
        neither set nor reset.  Now, the BREAK bit is set on receipt of an
        incoming BREAK and reset on receipt of the next non-BREAK event. 
        Ideally, this bit would be reset on the termination of the BREAK
        sequence, but in practice, there is no way to determine a BREAK
        other than by the receipt of another event.

    2.  Faking the incoming BREAK end time.  The FEP/OS can detect and
        generate an event at the start of a BREAK sequence however,
        the UARTs give no indication of the end of these sequences so no
        events are generated.  The best solution to fake the incoming BREAK end
        time was to set the BREAK bit in the qnx_ioctl() bitmap when an 
        incoming BREAK sequence starts, and cleared on receipt of the next 
        non-BREAK event, for example on the receipt of a character or detection
        of a modem line status change.

        However, users who require precise indication of BREAK end time
        may use the following trick suggested by Gene Olson: connnect
        pin 3 on the Digi adapter side of the cable to some unused modem
        control line, say RI.  Then, when an incoming BREAK starts
        or ends, a modem event (in this case an RI event) will be
        perceived and the qnx_ioctl() bitmap will be refreshed.

  * Added support for setting the software flow control characters at
    the Digi adapter level and developed a workaround for communicating
    these to the driver (because QNX normally expects to handle this
    at the higher DEV level and only calls the driver to communicate
    changes it cannot handle).  As in previous versions, the
    start/stop characters are set with "stty" (e.g: "stty start=02 stop=03..."),
    but stty command changes (alone) to the start and stop characters are not
    communicated to the driver.  However, since certain "stty" changes
    (including changes to: baudrate, clocal, hupcl, cread) always result
    in calls to the driver, the information is transferred by
    contriving to always include at least one change to one of these
    other settings when modifying the start or stop characters.

    For example: to set board-level software flow control to use Ctl/B and
    Ctl/C, use a temporary change to: the "clocal" setting.
    Assuming that the device is currently set for -clocal, 
    set the start and stop characters with:

         stty clocal start=02 stop=03 +osflow +isflow </dev/dty1

    and then restore the original clocal settings with:

         stty -clocal </dev/dty1
    
    The example of clocal is not the only command to work but also changes
    to baudrate, hupcl, and cread (change setting to transfer the information, 
    then restore the original setting) will also work.


BUG FIXES

  * Workaround to accommodate computers with bad PCI controller chips which
    fail to do 32 bit copies on certain address boundaries.  Depending on
    the application protocol, machines with these bad chips would sometimes
    drop data.


KNOWN LIMITATIONS
  * The number of devices that can be mounted is severely restricted by
    the resources of the Dev process that have a maximum setting of
    128, but only permits 96 or possibly 112 devices to be mounted.

HISTORY

Version 2.1.0, January 12, 1998
-------------------------------

  Enhancements
  ------------
  - Added support for PC (ISA) and PCI Xr+ cards.  Previously, the
    PC/Xr was supported by treating it like a PC/Xem.  Now, the entire
    Xr/Xr+ series is supported with new, on-board OS files (xrbios.bin
    and xrfep.bin) that must be distinguished from PC/Xem's on the
    driver command line.  One example (that uses the parameters, DIP switches
    with an I/O address of 0X320 hex and memory address 0Xd0000 hex) to 
    specify a PC Xr or Xr+ board, use "r" as
    the "cfg" command line parameter:

         Dq.ser32 320,d0000,r

    The example indicates either a PC/Xr or Xr-plus.  PCI cards (including the
    PCI versions of the Xr and Xr+) are identified automatically
    and do not require "port", "mem" or "cfg" flags.  The following command 

         Dq.ser32 -v

    will find and identify all supported PCI cards, including
    PCI Xr and PCI Xr+ cards. 

  - Added driver support for high baud rates (460800 and 921600) for
    the Xr+ cards.  Using these baud rates with other cards will
    have an unpredictable effect.

  - Updated the on-board OS files, including adding two new files:
    xrbios.bin and xrfep.bin which are now used for the entire PC
    and PCI Xr/Xr+ card family.

  Bug fixes
  ---------
  Version 2.0.3a  December 1997
  -----------------------------
  - Fixed a problem with memory segmenting that caused driver crashes
    during channel buffer pointer rollovers.
  
- Fixed a problem with channel buffer memory allocations that were fixed 
- at 4K, but some cards have much bigger buffers.  Now the driver makes memory requests based on the rx_size and tx_size sizes reported by the card.
  
  - Fixed a problem with supporting multiple cards
    simultaneously.  In the v2.0.2 release, some cards would 
    be disabled.
  
- Fixed a problem with card memory left disabled after an interrupt.  
- This occurred when interrupting a qcp session on one card, and 
- starting a qcp on a second card, the second never starts up properly.
- The same problem shows at least as far back as version 2.0.1b.  
  
  - Fixed a problem with re-enabling card memory contexts
    following high priority interrupts from cards using an ioport memory
    setting different from that used by the interrupted card.
  
  - Fixed a problem: The internal routine getFP()
    allocates system memory segment pointers -- a limited QNX system
    resource.  These were not released in dev_exit(), so repeated
    stopping (e.g. via kill) and restarting of the driver eventually
    used up all the available segment pointers and caused the next
    invocation of the driver (or anything else that needs segment
    pointers) to crash.  Previously, the only way to reset this
    was to reboot.  Now, dev_exit() frees up these memory pointers.


  Version 2.0.2  October 20, 1997
  -------------------------------
  - Removed debug code from beta test versions
  - Changed version number to V2.0.2

  Version 2.0.1k  September 15, 1997
  ----------------------------------
  - Add support for special baud rate of 0 which is a POSIX-sanctioned 
    code for disabling the communications port, including dropping
    DTR on a modem-enabled line.  Programs like ckermit() momentarily
    set the baud rate to 0 to reset lines.

  Version 2.0.1j  September 5, 1997
  ---------------------------------

  - Fixed scheduling problem that caused SIGSEGV errors under
    certain circumstances (associated with high priority
    ioctl calls preempting card write operations at sensitive
    times).


  Version 2.0.1c-i July 28 - September 2, 1997
  --------------------------------------------

  - Interim testing versions to track down the cause of occasional
    SIGSEGV errors


  Version 2.0.1c, July 28, 1997
  -----------------------------

  - Changed stty code to never return an error.  Previously,
    a bad baud rate would cause the stty handler to
    return an error which caused the driver to terminate.  The POSIX 
    standard instructs implementors to try to implement the baudrate
    as well as possible and ignore the rest.
    the rest.  QNX Tech Support reports that
    there is no way to notify the application of the failure.

    So, let the user beware:

    Requesting a bad baud rate no longer causes the driver to crash
    (it now leaves the previous baud rate unchanged), but there
    is no way for the user to know that the request has failed.
    Subsequent information requests (e.g. calling stty at the
    shell, or cfgetispeed() from a C program) are not reliable
    sources of information:  because user programs talk only to Dev,
    and Dev never asks the driver (Dq.ser) for its opinion, the
    returned values will simply be copies of what the user most
    recently asked for, not necessarily the baud rate actually set.


  Version 2.0.1b, April 3, 1997
  -----------------------------

  - Modified SIGNAL handling code to catch and IGNORE user level,
    EOF and HUP signals to prevent premature driver exits.

  - Corrected problem that caused the driver to fail to recognize
    MCA (MicroChannel) architectures with newer versions of QNX.

  - Corrected a COM/Xi-specific problem that caused data corruption
    on channel #8.

  Version 2.0.1a, March 25, 1997
  ------------------------------

  - Fixed a problem with recognizing the microchannel bus on
    some machines

  - Fixed several problems associated with messy termination (possibly
    trapping the kernel) following HUP, KILL or TERM signals
    under some circumstances.