Shareware 1 2 the Maxx/sw_1.zip/sw_1/COMM/IOMON2.ZIP/IOMON.DOC

Text File | 1992-02-20 | 8KB | 176 lines

IOMON - Protected mode I/O port monitor
---------------------------------------
IOMON is a protected mode I/O monitor written by Rick Knoblaugh and
published in an article in Programmer's Journal (volume 9, number 5).
The program files for IOMON are copyright 1991 ASMicro and distributed
here with their permission.

IORPT is a reporting program that reads the memory resident data buffer
maintained by IOMON and produces several reports. IORPT was written by
Terry Hughes of TurboPower Software and is released to the public
domain.

Version 1.0
1/92


Overview
--------
IOMON and IORPT can be used to monitor and report on the serial port I/O
performed by any communications program. As you might guess by their
names, IOMON does the monitoring and IORPT does the reporting.

This combination of programs can add some powerful and convenient
debugging capabilites to your toolbox. Previously, if you wanted to
monitor the exchange of data in a serial link you needed a data scope or
an extra PC (and cables) equipped with data scope-like software. While
there will still probably be times when only a data scope will do, IOMON
and IORPT make it possible to monitor many such communication exchanges
directly on one of the participating machines.

IOMON is a memory resident monitor that tracks all accesses to a
specified range of I/O ports. As presented here, its intended purpose is
to monitor the range of I/O ports that belong to a UART. The tremendous
utility of such a program is that it can monitor communications programs
as they run, without interfering with them, and note all serial data
input and output as well as modem and line control performed by that
program.

IOMON was originally published in Programmer's Journal as a general
purpose I/O port monitor. We've made one small modification to it to
allow the its information buffer to be truly circular (as published, the
buffer was cleared everytime it wrapped).

We've supplied the file IOMON.EXE executable file as well as the source
code files distributed with the Programmer's Journal article (with our
small modification). For more information about how IOMON works we
suggest you read Rick Knoblaugh's article on the program in Programmer's
Journal 9.5.

IORPT is a reporting program that reads IOMON's memory resident data
buffer and produces two reports -- a "trace" and "audit" report. The
trace report is identical to the Tracing facility provided by Async
Professional. The audit report is similar to Async Professional's event
logging report except that it lacks a time stamp.

Note that while IOMON is a general purpose I/O monitor, IORPT assumes
that IOMON is currently being used to monitor the UART ports of COM
port. Running IORPT while IOMON is monitoring some non-UART port
addresses will give unpredictable results.


Using IOMON and IORPT
----------------------
In a nutshell, a typical testing scenario will consist of

  1) loading IOMON with desired UART addresses
  2) running the communications program you wish to monitor
  3) running IORPT to build a report of what the communications program did

Here's a bit more detail about each step.

IOMON.EXE is a TSR that takes two command line arguments -- the starting
and ending port addresses you wish to monitor. For example:

  IOMON 3F8 3FE

will monitor all inputs and outputs to I/O ports $3F8 through $3FF. It
maintains an internal 8K buffer of information about all accesses to
those port addresses. For each access it saves the exact port address,
the data input or output and whether the access was a word or byte
access.

These addresses are assumed to be in hexadecimal notation and the first
address must be less than the second address. When using IORPT in
conjuction with IOMON, these addresses will be the UART port addresses
of the COM port you wish to monitor. Below are the standard addresses
for COM ports:

  COM1  3F8 3FF
  COM2  2F8 2FF
  COM3  3E8 3EF
  COM4  2E8 2EF

IOMON isn't restricted to just these addresses. It will attempt to
monitor whatever range you give it. However, IORPT assumes that you are
using it to monitor a UART. To report on other addresses, you'll need to
use the more simple-minded IODISP.EXE program that is part of the
original IOMON package.

To perform its monitoring, IOMON must run in virtual-86 protected mode.
This provides two obvious restrictions on its use: 1) it requires a 386,
486 or later, and 2) the machine cannot already be running in protected
mode. Since most memory managers (QEMM and 386Max) also place the
processor in protected mode, they must be removed before running IOMON.

An additional restriction of the way IOMON operates is that it cannot be
uninstalled by itself or by using external mark/release programs. Once
you are finished with your monitoring tests you will need to reboot your
machine to remove IOMON.

Assuming you've installed IOMON correctly, the next thing to do is run
the communications program you wish to monitor. Each time that program
accesses one of the ports in IOMON's range, an I/O exception will be
generated and IOMON will temporarily gain control. It will allow the I/O
to continue but will peek at the data that was input or output and add
an entry to its circular log. The circular log will contain the last
8192 I/O events.

When the communications program is finished you will use IORPT to read
that circular buffer and produce its reports. IORPT has the following
command line arguments:

  Usage: IORPT [options]
    /T      build standard APRO trace to IORPT.TRC
    /D      build detailed audit report to IORPT.AUD
    /F      filename to use (no extension)

The /T option builds a report identical to Async Professional's Tracing
report. Here's a short sample:

  Transmit:
  ATZ[13][10]

  Receive:
  ATZ[13][10][13][10]OK[13][10]

The program begin monitored sent an 'ATZ' to the serial port and
received back on echo of that command plus an 'OK' response.

The /D option builds a report similar to Async Professional's Event
Logging report. However, this report doesn't provide and timestamp and
is otherwise different enough that we gave it a different name -- an
audit report. Here's a short sample:

 Addr  Direction  Value   Message
 ----  ---------  -----   -------
 02F9     In        00    Reading interrupt enable mask
 02FA     In        01    Reading interrupt type
 02FC     In        00    Reading modem control register
 02F9     In        00    Reading interrupt enable mask
 02F9     Out       00    Setting interrupt enable mask
 02F9     In        00    Reading interrupt enable mask
 02F9     Out       00    Setting interrupt enable mask
 02F9     In        00    Reading interrupt enable mask
 02FC     In        00    Reading modem control register
 02FB     In        03    Reading line control register
 02FB     Out       83    Enabling DLAB
 02F8     In        30    Reading baud rate
 02F9     In        00    Reading interrupt enable mask
 02FB     Out       03    Setting line control register (DLAB off)
 02FF     In        F0    Reading scratch register
 02FF     Out       F0    Writing scratch register

The information should be fairly self-explanatory. Each line represents
one access to a UART port. Addr has the exact address, Direction tells
whethe this was due to and IN or OUT instruction and Value contains the
value input or output. Message is a short text explanation that IORPT
attaches to each address, direction and value, assuming that the address
range being monitored is part of a UART address range.

Note that you can produce both reports by specifying both /T and /D on
the command line. When debugging information exchanges, like protocols,
you probably find the /T report helpful. When debugging low-level
problems (like modem control issues) you'll probably find the /D report
more helpful.