COMi is a multi-port asynchronous serial device driver for the OS/2* operating system. This version of COMi will work in any system running OS/2 2.0 and above. There is a different version for OS/2 1.x that is still available and supported by OS/tools.
By multi-port we mean that with COMi there is no limit (logically) to the number of COM devices that can be made available to OS/2 sessions or applications. There is a practical limit, of course, because there is a limit to the number of COM devices that can be installed in any single system. COMi will allow you to install devices with names from COM1 to COM99.
COMi comes with an easy to use installation program (INSTALL.EXE). This program can transfer all required files to the directories of your choice, create a desktop folder and necessary program objects, and initiate the configuration process.
If you have multiple COMi licenses you can reuse a COMi initialization file for similar installations by copying that initiaization file to the distribution diskette. When INSTALL finds a COMi initialization file in the directory it is run from, it will transfer that file to the installation destination directory. The transferred COMi initialization file will be presented for modification during each subsequent installation process.
Multiple licenses for COMi can be installed from a network drive or directory. To do this you must first use INSTALL to transfer both COMi and INSTALL to a network drive, then complete the configuration process just as though you were installing it to a local drive.
Once installation and configuration are complete you can run INSTALL on a workstation from the network directory to install COMi to that workstation. Any initialization file you created in the INSTALL (network) directory will also be transferred to the workstation. You can then make any necessary changes to the initialization file by selecting the Configuration | COMi... menu item, after INSTALL has transferred the required files to the local drive.
To install and configure COMi Print Spooler support you must have elected to transfer the spooler support files while installing COMi by selecting the "Print Spooler Utilities" check box in the "Install Options" dialog, configured COMi for your serial hardware, and you must have re-booted your machine since that install session.
Once you have completed transferring the files, installing and configuring serial devices for COMi access, and re-booting your machine, you will need to do the following:
If you do not have a printer object see "Printing in OS/2" book in the Information folder for information on creating a printer object.
The Spooler software will read each spooler support library in that directory, including the COMi spooler support library, and show an icon in the container area of the dialog for each device these spooler support libraries support.
Only ports that have been installed with a COMi configuration program (COMscope or Install) will be available for installation as spooler ports by the system spooler software. COMi must have been loaded at system initialization before COMi print Spooler support can be installed, or accessed.
Once you have installed at least one COMi spooler port using this procedure, you will be able to install and delete spooler ports from the COMi Configuration program (either Install or COMscope).
You can set the port parameters to match the requirements of a printer by clicking mouse button two on an icon in the container area and selecting the "Settings" menu item. Help for setting printer port initialization parameters will be available once you have entered the setup dialog.
Note : Configuration of COMi print spooler ports for device and printer communications parameter initialization, will always have to be completed from the printer object's settings notebook, as described here. The system spooler software will not be aware of any initialization parameters selected from the COMi configuration program as they are intended as system startup defaults only.
The COMi device driver can only be configured using COMscope or Install. These two programs create, or modify, an initialization file for the device driver. Each time your system is started, COMi reads this initialization file to determine where to look for serial devices and how to configure those devices.
Additional Information:
The COMi device driver will not operate in ISA systems until a valid initialization file is created. There can be no access to COM devices in ISA systems until the configuration process has been completed and a valid initialization file has been created.
Related information:
The COMi device driver does not need an initialization file to initialize the eight pre-defined serial ports in a PS/2* or other MCA system that has ABIOS or equivalent. You will need to create an initialization file for MCA machines only if you:
Related information:
During installation, the configuration process is started by INSTALL (supplied with COMi). After Installation is completed you will need to re-boot your machine before you will be able to access serial devices with COMi.
After installation you can configure COMi either from a program object (icon) or from an OS/2* command prompt.
Starting from a program object:
If there is a program object for COMscope or Install you can double click on the object to begin the configuration process.
If there is no program object for COMscope or Install, you can either start the program from the command line (in an OS/2 windowed session) or create a program object using the following procedure:
Example: C:\COMM\COMscope.EXE
Example: C:\COMM
Example: COMi Configuration
Starting from an OS/2 command prompt:
If the COMi device driver is loaded you will only need to enter the program name and path on the command line.
Example: [C:\]C:\comm\COMscope <ENTER>
If the COMi device driver is not loaded you will be prompted for a path and file name after starting COMscope or Install. The COMi initialization file must be located in the same directory as the device driver, and must have the same base name as the drvice driver file with a ".INI" extension.
COMi has extensions that allow it to perform in some special situations. These extensions are:
Note : When initialization testing is disabled, COMi will not be able to automatically detect a 4x baud rate clock.
The COMi application interface (API) is exactly as described in the "Physical Device Driver" technical reference for Category One, Asynchronous Serial Device Drivers. COMi supports all features and functions as described in that reference, except the Enhanced Mode functions (functions 0x54 and 0x74).
Differences from COM.SYS:
There are some differences in how COMi is initialized compared to the COM.SYS device driver. Here is a list of the differences:
There should be one other difference noted here, though it pertains only to documentation. The "Physical Device Driver" technical reference stated that the COM.SYS device driver starts up with CTS and DTR output handshaking, DSR input sensitivity, and RTS input handshaking, enabled. The COM.SYS device driver starts up with no handshaking enabled and neither does COMi, unless the end-user makes it so.
COMi can work with any adapter that uses any of the required serial devices, in any combination and in any quantity your OS/2* system can accommodate. There are some restrictions and caveats, though, and these are what this part of the manual will explain.
COMi is designed to allow an OS/2 system to access multiple serial devices at baud rates up to 460.8K BPS and above, using "dumb", inexpensive, Universal Asynchronous Receiver Transmitters (UARTs). The device driver will support any UART of the 16550 family. This includes the 8250, 8250A, 16450, 16450A, 16550A, 16550B, 16650, and some others, including most built-in UARTs that are part of a motherboard chip set.
Systems Supported:
ISA shared interrupt capable adapters supported:
Devices Supported:
The ST16650 UART, by Startech, is an extension of the 16550 UART. It has 32 byte FIFOs and is capable of selecting the on board baud rate clock or dividing that clock by four. With this UART your system will be able to handle higher DTE baud rates; up to 460.8K BPS.
COMi will automatically detect if a 16650 UART is installed and will also automatically determine if the baud rate clock is a multiple of four of the normal 1.843MHz baud clock.
One version of the ST16C650 UART is completely pin compatable with the 16550 UART. You may purchase one or more of these UARTs and just replace the UARTs currently installed on your serial adapter; assuming the adapter has sockets for its UARTs.
The 16550 UART is the most common serial device in OS/2* systems. These UARTs have both receive and transmit First In First Out (FIFO) buffers. FIFOs allow a greater throughput with less interrupt overhead.
When the 16550 UART's FIFO modes are enabled the device will normally interrupt the CPU every 14 received characters or every 16 transmitted characters. This means that a device receiving data at 57600 baud will get an interrupt about every 2.5 milliseconds. For comparison, without FIFOs, a device running at 57600 baud would get an interrupt about every 170 microseconds.
The COMi device driver will automatically determine if any device it is configured to support has hardware buffers, and will take full advantage of those buffers when they are available
It is not recommended that you use any adapter that contains 16450 UARTs. These UARTs have no hardware buffering capabilities and will interrupt the CPU whenever a character is received or transmitted. This means that if you are running a communications program at 9600 baud there will be an interrupt about every one millisecond, possibly more if your application is receiving and streaming data (transmitting/ receiving large strings) in a full duplex mode.
As with the 16450 UART, the 8250 UART does not contain FIFOs, and it is not recommended that you use serial adapters that use 8250 UARTs in OS/2* systems. COMi will work with these UARTs but your system performance may be greatly diminished when using them at higher baud rates.
MCA machines are designed to allow adapters and/or devices to share hardware interrupts. This architecture makes it easy for COMi to support any number of serial devices in any combinations of device base addresses and hardware interrupts, with the following recommendations and restrictions:
ISA machines do not normally allow adapters, or devices, to share hardware interrupt levels. Because of this (deficiency) there are certain restrictions for configuring the device driver for access to serial adapters and multiple serial devices. These restrictions include:
Related Information:
If you are installing serial device support in an ISA machine and you intend to connect multiple devices to a single hardware interrupt level you need to be aware of the following:
Note : Sharing interrupts on an MCA machine requires no special configuation. Please note, though, that it is not recommended that you connect more than eight devices to any one hardware interrupt level.
Related Information:
In order for COMi to support shared interrupts on an ISA machine, an adapter of one of the types described below must be used.
Type One:
Type Two:
Type Three:
Type Four:
Type Five:
Related Information:
COMi has been tested with the following serial adapters.
旼컴컴컫컴컴컴컴컴컴컴컴컴쩡컴컴컴컴컴컴컴컴컴커 쿟ype 쿘anufacturer 쿘odel � 쳐컴컴컵컴컴컴컴컴컴컴컴컴탠컴컴컴컴컴컴컴컴컴캑 쿚ne 쿞ealevel Systems 쿎OMM+4 � 쳐컴컴컵컴컴컴컴컴컴컴컴컴탠컴컴컴컴컴컴컴컴컴캑 � � 쿟URBOCOMM+8 � 쳐컴컴컵컴컴컴컴컴컴컴컴컴탠컴컴컴컴컴컴컴컴컴캑 � 쿒lobetek 쿞-1005 � 쳐컴컴컵컴컴컴컴컴컴컴컴컴탠컴컴컴컴컴컴컴컴컴캑 � 쿜uatech 쿐S-xxx � 쳐컴컴컵컴컴컴컴컴컴컴컴컴탠컴컴컴컴컴컴컴컴컴캑 � � 쿜S-xxx � 쳐컴컴컵컴컴컴컴컴컴컴컴컴탠컴컴컴컴컴컴컴컴컴캑 쿟wo 쿎omtrol 쿓ostess RJ45 � 쳐컴컴컵컴컴컴컴컴컴컴컴컴탠컴컴컴컴컴컴컴컴컴캑 � � 쿓ostess RJ11 � 쳐컴컴컵컴컴컴컴컴컴컴컴컴탠컴컴컴컴컴컴컴컴컴캑 쿟hree 쿎onnect Tech 쿏FLEX � 쳐컴컴컵컴컴컴컴컴컴컴컴컴탠컴컴컴컴컴컴컴컴컴캑 쿑our 쿏igiBoard 쿛C/4 � 쳐컴컴컵컴컴컴컴컴컴컴컴컴탠컴컴컴컴컴컴컴컴컴캑 � � 쿛C/8 � 쳐컴컴컵컴컴컴컴컴컴컴컴컴탠컴컴컴컴컴컴컴컴컴캑 쿑ive 쿏igiBoard 쿛C/16 � 읕컴컴컨컴컴컴컴컴컴컴컴컴좔컴컴컴컴컴컴컴컴컴켸
COMi will support shared interrupts with all of the adapters listed above and any other adapter that uses one of the interrupt sharing schemes described under COMi Adapter Types.
Believe it or not, the COMi installation and configuration process is not always as simple and straight forward as we would like it to be.
The following is help and explanation for the most common problems encountered when attempting to install, configure, and access the COMi device driver:
The COMi configuration program will not normally allow you to configure more than one device per hardware interrupt level on ISA machines unless you have selected an adapter type from the Adpter Setup dialog, supplied an interrupt status register address, and selected an interrupt level.
Note : If you supply an interrupt status register address and there is no such register with that function your, system WILL lock-up.
You may configure more than one device to share an interrupt level by selecting the Extensions... button when configuring a device, and selecting the "Share Interrupt Connection" check box.
In order to share interrupts using this "extension", your hardware must have a "wired-OR" interrupt circuit that ties each device to the system board's Interrupt Request (IRQ) circuit. You can expect this to be the case any time you are using a multi-device adapter that allows you to connect more than one device to any one interrupt level. Adapters that contain only one serial device rarely use this type of circuit.
In general it is not a good idea to configure devices on more than one adapter to share interrupts. The exception is when your are using any adapter that specifically supports multi-adapter interrupt sharing.
MCA machines are designed to allow interrupt sharing. You can select any hardware interrupt level, though we do not recommend assigning more than eight devices to any one hardware interrupt level.
The configuration programs will not allow you to select a base I/O address for any device that is assigned to another COMi controlled device, nor will it allow you to select a base address that is not at an eight byte boundary.
During each load of the COMi device driver each defined device is normally tested to determine the following:
Any device failing the first four tests will not be installed and will not be available at run-time. If you KNOW that the device is valid as defined, you can select Disable Startup UART Tests in the Extensions dialog box for this device. Enabling this extension will cause all tests to be bypassed except the interrupt level availability test (number two).
This may be necessary if you have a UART that is built into the motherboard chip set, or a device that is not quite compatible with the 8250/16450/16550/16650 UART.
COMi will work when COM.SYS and VCOM.SYS are loaded. If you want to use both COMi and COM.SYS you will need to insure that COM.SYS is loaded before COMi. The configuration program will normally place COMi "DEVICE=" statements at the end of the CONFIG.SYS file, so this should not be a problem.
You will also have to refrain from naming COMi devices with the same names COM.SYS will use. Naming a COMi device COM1 through COM4 will cause COM.SYS to drop access to any device it owns with those device names. If you know that you do not have serial hardware at a traditional, or pre-defined, COMx location you can use that device name without problems.
If you want to use COM.SYS and VCOM.SYS for some COM ports and COMi for other's, you need only configure COMi to use the device name (COMx) you want COM.SYS to drop.
Additional Considerations:
ISA machines have traditionally defined serial devices for COM1 through COM4. Below is a listing of traditional ISA serial port specifications.
旼컴컴컴컴쩡컴컴컴컴쩡컴컴컴컴� 쿏evice 쿍ase 쿔nterrupt� 쿙ame 쿌ddress 쿗evel � 쳐컴컴컴컴탠컴컴컴컴탠컴컴컴컴� 쿎OM1 �0x3F8 �4 � 쳐컴컴컴컴탠컴컴컴컴탠컴컴컴컴� 쿎OM2 �0x2F8 �3 � 쳐컴컴컴컴탠컴컴컴컴탠컴컴컴컴� 쿎OM3 �0x3E8 �4 � 쳐컴컴컴컴탠컴컴컴컴탠컴컴컴컴� 쿎OM4 �0x2E8 �3 � 읕컴컴컴컴좔컴컴컴컴좔컴컴컴컴�
The COM.SYS device driver will normally connect only to COM1 and COM2. However, you can request access to COM3 and COM4 by defining the port number, base address, and interrupt level on the "DEVICE=d:\path\COM.SYS" command line in the CONFIG.SYS file. Using this method will not allow you to share interrupts, but you could get sequential access to devices defined with the same hardware interrupt level.
If you want to have COM.SYS and VCOM.SYS control any of the above listed devices you will not be able to use their respective COMx device names when configuring COMi.
For information on how to configure COM.SYS for COM3 and COM4 access enter "HELP COM.SYS" from any command prompt, or search in the "Command Reference" for "COM.SYS".
MCA machines have eight pre-defined serial port designations. COM1 through COM4 can be controlled by COM.SYS. Below is a listing of pre-defined MCA serial port specifications.
旼컴컴컴컴쩡컴컴컴컴쩡컴컴컴컴� 쿏evice 쿍ase 쿔nterrupt� 쿙ame 쿌ddress 쿗evel � 쳐컴컴컴컴탠컴컴컴컴탠컴컴컴컴� 쿎OM1 �0x3F8 �4 � 쳐컴컴컴컴탠컴컴컴컴탠컴컴컴컴� 쿎OM2 �0x2F8 �3 � 쳐컴컴컴컴탠컴컴컴컴탠컴컴컴컴� 쿎OM3 �0x3220 �3 � 쳐컴컴컴컴탠컴컴컴컴탠컴컴컴컴� 쿎OM4 �0x3228 �3 � 쳐컴컴컴컴탠컴컴컴컴탠컴컴컴컴� 쿎OM5 �0x4220 �3 � 쳐컴컴컴컴탠컴컴컴컴탠컴컴컴컴� 쿎OM6 �0x4228 �3 � 쳐컴컴컴컴탠컴컴컴컴탠컴컴컴컴� 쿎OM7 �0x5220 �3 � 쳐컴컴컴컴탠컴컴컴컴탠컴컴컴컴� 쿎OM8 �0x5228 �3 � 읕컴컴컴컴좔컴컴컴컴좔컴컴컴컴�
COM.SYS will allow you to access up to four devices from this list and will automatically use COM1 through COM4 for the first four serial devices it detects from the above list. The COMi device driver will also automatically configure itself, but it will allow you to access all eight devices defined in the list above.
COMi will try to automatically configure itself for any unowned device it detects in the list above. If COM.SYS or any other ABIOS aware serial device driver is loaded, COMi will not install any COMx port or device that is already owned by a previously loaded device driver. You will need to create an initialization file with a COMi configuration program (COMscope or Install) if you want COMi to control any device that a previously loaded device driver owns.
If you need access to more than eight serial devices and/or serial devices that are not configured as defined in the above table, you will also need to create an initialization file with a COMi configuration program.
Improperly configuring COMi and/or the serial adapter can cause various kinds of problems, none of which result in increased productivity.
The following items are the most common problems:
When an application writes to, or reads from, a COMx device, the device driver does not normally return to the calling thread until all requested characters have been either received or transmitted. If a time-out occurs before all characters have been transmitted, or received, the device driver will return to the calling thread with a count of the actual characters written, or read.
An application should test the returned count to determine if it should try to re-transmit, or read again, any remaining characters.
Write time-outs normally occur only when some output handshaking has been enabled and some event has caused the device driver to stop transmitting before it could transmit all of the requested characters. Read time-outs can occur anytime the "far-end" stops transmitting, before all requested characters have been received.
See the "Physical Device Driver". technical reference, Category One, Asynchronous Serial Device Drivers, for a complete description of the device I/O control commands and their various input and output parameters. COMi is designed to operate according to that application interface.
Your distribution diskette contains a "C" source file that has sample code for most of the DosDevIOCtl functions defined in the Technical Reference. The file name is "IOCTL.C".
An application has probably tried to read the COM device from the window procedure thread, the time-out is set for the default one minute read time-out, and no characters are arriving at the UART.
The device driver does not return to the calling thread until no characters have been received for the user configured read time-out count. It is recommended that an application access any COM device with a thread separate from the thread in which its window procedure is running.
Of course there are other reasons for system lock-up, but this one seems to be the most common when accessing COM devices.
This problem, when related to COM devices, is almost always caused by improper configuration of the device driver and/or serial adapter and/or device, and is the result of an endless loop within the interrupt service routine while interrupts have been disabled. Make sure that the COMi device driver is configured correctly for your adapter and that the serial adapter and/or device is configured as you intended.
This section is a "catch-all" for information we thought might be useful.
Concepts:
In any system it is important that all real-time activities, like serial communications, be truly asynchronous. Basically this means that no information should be lost because the operating system was busy doing something else.
In operating systems like DOS, or DOS and Windows**, there is never any guarantee the operating system will be able to get to a "real-time" process in a timely manner. Each process in these systems "owns" the machine until it relinquishes control. If a real-time process needs service it has to wait until any currently running process has completed.
In OS/2* this is not normally a problem. Its structure is such that hardware interrupts have the highest priority and are serviced almost immediately, and other processes are given a time-slice in which to execute.
Problems can occur in two ways. The first is when hardware interrupts come in faster than the operating system can respond. For asynchronous serial communications this problem is addressed mostly by serial devices with hardware buffers (FIFOs).
The second problem is that an application may not be able to read and process incoming information as fast as the hardware and device driver can receive and store information. This problem is addressed by the handshaking features of the serial device driver.
When handshaking is enabled the receiving system will signal the transmitting system to stop transmitting when its receive buffer nears full capacity. The transmitting system should stop transmitting when it receives a signal to stop.
In OS/2, a serial device driver must be capable of handshaking without intervention or control by the controlling higher level process. All a controlling process needs to do is command the device driver into a handshaking mode and the device driver must do all of the processing to be sure that the controlling process does not lose any information. This includes detecting when its own receive buffer is nearly full so it can send a "stop transmitting" signal and then detecting when its receive buffer has been emptied enough so that it can send a "start transmitting" signal. It also includes detecting when the device it is transmitting to has sent a "stop transmitting" or "start transmitting" signal and act accordingly.
This feature can only be enabled when a device has hardware buffers (FIFOs). Normally you would want to enable hardware buffers to reduce system overhead. When handshaking is required between this hardware (near-end) and some external hardware (far-end) it may be required that a far-end's request to stop transmitting be acted upon immediately.
If hardware buffers are enabled it would be possible for that hardware to transmit up to twenty bytes after the far-end sends a "stop transmitting" signal. This is because once the device driver has filled the hardware buffer, transmission will continue until the buffer is empty. This may cause a problem for some far-end equipment.
This problem can occur when any output handshaking is enabled. This includes CTS, DSR, and/or DCD output handshaking and transmit Xon/Xoff handshaking. The CTS, DSR, and DCD signals are "hardware" flow control signals and transmit Xon/Xoff handshaking is "software" flow control signaling.
There are two output handshaking scenarios to consider. The first is the "hardware" signaling case. When the far-end's receive buffer is full (or nearly full) it may signal to the near-end by making one or more of the "hardware" signals inactive. When the near-end detects an inactive signal it should stop transmitting. If the transmit buffer is enabled at the near-end it may transmit up to 16 bytes before it can act on that signal to stop.
The second case is "software" signaling. When the far-end's receive buffer is full (or nearly full) it may signal to the near-end by transmitting an Xoff character. When the near-end receives the Xoff character it should stop transmitting. If, at the near-end, the receive buffer is enabled, it will not detect the request to stop transmitting until it has read the Xoff character from the receive buffer, and if the transmit buffer is enabled it may transmit up to sixteen bytes before it stops transmitting.
The worst case could occur when "software" signaling is enabled. When hardware buffers are enabled it would be possible for an Xoff character to be received by the hardware and not read by the device driver for up to four character-times after the byte was received. The worst case would be for the Xoff character to arrive at the near-end hardware just as there are four characters left in the transmit buffer to be transmitted. The device would cause a transmit interrupt just as the last or the four bytes is transmitted and the device driver would refill the transmit buffer, then the device would cause a receive FIFO time-out interrupt and the device driver would read, and detect, the Xoff character, preventing further transmissions. This case could allow up to twenty bytes to be transmitted after the far-end transmitted the Xoff character.
All of these potential problems go away if the transmit buffer is disabled when any output handshaking is enabled and the receive buffer is disabled when transmit Xon/Xoff handshaking is enabled.
When Automatic Protocol Override (APO) is enabled the device driver adjusts hardware buffer functionality according to handshaking requirements. When APO is enabled and an application requests CTS, DSR, or DCD output handshaking the device driver will disable the transmit buffer. When APO is enabled and an application requests transmit Xon/Xoff handshaking the device driver will disable both the transmit and receive buffers.
There is one other adjustment Automatic Protocol Override can cause the device driver to make to the hardware buffers of a device. When DSR input sensitivity is enabled, and APO is enabled, the receive buffer will be disabled by the device driver.
DSR input sensitivity is designed to handle devices that may transmit garbage whenever DSR is in the inactive state. In this case it would be necessary to ignore any bytes received while DSR is inactive. It may be possible for the far-end to transmit a character at the same time it activates DSR. This could cause the near-end to miss a valid byte if its receive buffer is enabled.
What does all this mean to you? Probably nothing. There are not many "far-end" devices around these days that do not have some level of buffering capability. We recommend that you leave APO off, and FIFOs enabled, unless, and until, you determine that you are communicating with some archaic equipment that requires it.
Each device to be controlled by the COMi device driver owns a set of eight contiguous I/O space addresses. The I/O base address is the first address in that device's address space. See your adapter board documentation to determine what I/O base address to use.
Each device to be controlled by the COMi device driver must be connected to one, and only one, hardware interrupt level. See your adapter board documentation to determine what interrupt level to select.
Note : An exception to this rule is when you use a serial adapter that supports shared interrupts in an ISA machine. If you are using such an adapter you must take care not to use more than one interrupt level for each COMi load.
You may use any combination of interrupt levels MCA machines.
A first level DosOpen is the first time a device is opened by any application. Any other DosOpen calls, without first calling DosClose, are considered second level opens. When all applications have closed a device then the next DosOpen for that device will, again, be considered a first level DosOpen. The device driver returns some device operating parameters back to device driver defaults whenever a first level DosOpen occurs.
Device driver operating parameters that are set back to device driver defaults are:
Note : COMi start-up defaults are configurable by the user. The parameters in the above list are returned to defaults defined explicitly by the user or implicitly by OS/tools. If the user has not defined a given parameter default during configuration that parameter will be returned to the default defined by OS/tools.
Industry Standard Architecture
Machines that are compatible with the IBM AT personal computer are of this type.
IBM and AT are registerd trademarks of International Business Machines, Incorporated.
Micro Channel A rchitecture
Machines that are compatible with the IBM PS/2 are of this type.
IBM, Micro Channel, and PS/2 are registerd tradmarks of International Business Machines, Incorporated.
Note : The active device is the device selected from the "Device | Select Device..." menu dialog box. The name of the currently active device is displayed in the title bar of the COMscope main window, in the title bar of all COMscope monitor and control dialog boxes, and is shown as the title of any visible icon when a COMscope instance has been minimized.
Note : A COM device's main purpose in life is to send/receive data to/from some external device. All data written to a device, and/or read from a device, is considered to be that device's I/O Data Stream. Once a valid device has been selected COMscope can be made to capture, and save, any data that is part of that I/O Data Stream. The bytes of an I/O Data Stream are stored in the order in which they are transmitted and/or received.
Note : Ordinarily each byte received or transmitted is displayed in order of transfer to/from the hardware, with each new byte is placed for viewing into the next character position on the screen. When display compression is selected the character position is not incremented when a received byte follows a transmitted byte.
Note : Each DEVICE=comdd.SYS statement in your CONFIG.SYS file is considered a load of the COMi Asynchronous Device Driver.
You can check (select) a button either by clicking mouse button one while the pointer is on the item, or by using the TAB and/or cursor keys to move so the required item has the focus then pressing the space bar.
A symbol that shows that a menu choice is currently active.
In the lexical display format, only characters that are not excluded by the user with display filters are displayed.
When the lexical display format is in the "line" oriented mode the transmit and receive streams can be synchronized. This means that a stream direction being synchronized "to" is displayed starting at the first character of that "line" and the stream direction that is to be in synchronization is displayed starting at the first character of the first "line" the begins immediately after the first character of the sync to stream direction.
Stream direction is either into the device (receive), or out of the device (transmit).
Different adapter manufacturers use different schemes to allow shared interrupts in ISA machines. Currently the COMi device driver supports the following schemes:
Sealevel Systems COMM+8 and Turbo COMM+4, Connect Tech DFLEX, and GlobeTeks four port adapter use this interrupt sharing scheme.
Comtrol Hostess serial adapters use this interrupt sharing scheme.
Quatechs' ES-XXX and QS-XXX adapters use this scheme.
DigiBoard's PC/4 and PC/8 use this interrupt sharing scheme.
DigiBoard's PC/16 uses this interrupting scheme.
IBM, OS/2, PS/2, and Micro Channel are trademarks of International Business Machines, Incorporated.
Windows is a trademark of Microsoft, Incorporated.