NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/sys/ibm/pc/digest/210

Internet Message Format | 1993-01-27 | 34.3 KB

Path: sparky!uunet!europa.eng.gtefsd.com!paladin.american.edu!howland.reston.ans.net!spool.mu.edu!agate!ucbvax!WSMR-SIMTEL20.ARMY.MIL!Info-IBMPC
From: [e-mail] ("Info-IBMPC Digest")
Newsgroups: comp.sys.ibm.pc.digest
Subject: Info-IBMPC Digest V93 #12
Message-ID: <[e-mail]>
Date: 27 Jan 93 08:02:16 GMT
Sender: [e-mail]
Reply-To: [e-mail]
Organization: The Internet
Lines: 734
Approved: [e-mail]
X-Unparsable-Date: Sun, 24 Jan 93 00:39:29 GMT+1

Info-IBMPC Digest           Sun, 24 Jan 93       Volume 93 : Issue  12

Today's Editor:
         Gregory Hicks - Rota Spain <[e-mail]>

Today's Topics:
             Administrivia - Source of this issue (V93 #12)
                 Subscribing to the Info-Kermit Digest
             MS-DOS Kermit, COM3, COM4, and Internal Modems

Send Replies or notes for publication to: <[e-mail]>

Send requests of an administrative nature (addition to, deletion from
the distribution list, et al) to: <[e-mail]>

Addition and Deletion requests for UK readers should be sent to:
<[e-mail]>

Archives of past issues of the Info-IBMPC Digest are available by FTP
ONLY from WSMR-SIMTEL20.ARMY.MIL in directory PD2:<ARCHIVES.IBMPC>.

----------------------------------------------------------------------

Date: Sun, 24 Jan 1993 08:28:00 GMT+1
From: Gregory Hicks - Rota Spain <[e-mail]>
Subject: Administrivia - Source of this issue (V93 #12)

The articles in this Issue of Info-IBMPC Digest were originally
published as Info-Kermit Digest V17 #1; I created an article (next
one) and deleted one (patching MS-DOS Kermit for StarGROUP).  (See next
note if you want to subscribe...)

I thought Frank da Cruz's discussion about problems with COM1-COM4 of
particular interest since, in the recent past, there have been a number
of queries on how to make COM3 and COM4 work.  A lot of his article is
Kermit specific.  The rest - I think, and I think you will also -
contains good info on things to watch out for when adding a
third/fourth COMx port...

If not, I'm sure I'll hear about it.

Enjoy!
Gregory Hicks

------------------------------

Date: Thu, 14 Jan 1993 11:57:43 EST
From: Christine M Gianone <[e-mail]>
Subject: Subscribing to the Info-Kermit Digest

Digest submissions may be sent to [e-mail] or
[e-mail].  Requests for addition to or deletion from the
Info-Kermit subscriber list should be sent to [e-mail] or
[e-mail].  These messages must be of the form:

  SUBSCRIBE I$KERMIT <your-personal-name>    (To start a subscription)
  UNSUBSCRIBE I$KERMIT                       (To cancel a subscription)
  REGISTER I$KERMIT <your-personal-name>     (To correct your name)

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a
SUN-4/280 running UNIX (SUNOS 4.1), IP host number 128.59.39.2.  Login
as user anonymous (note, lower case), any password, and GET or MGET
(MULTIPLE GET) the desired files.  The file kermit/read.me is a general
guide to where things are.  The Kermit files are in directories
kermit/a, kermit/b, kermit/c, kermit/d, and kermit/e.  Test versions
are in kermit/test.  All files in these directories should be
transferred in text (ASCII) mode.  Binaries are in kermit/bin (use ftp
in binary mode).  All files on watsun have lowercase names, and case is
significant.

You can also get Kermit files over the BITNET/EARN network; to get
started send a message with text HELP to KERMSRV, the Kermit file
server, at host CUVMA.  For detailed instructions, read the file
kermit/a/aanetw.hlp (AANETW.HLP on KERMSRV).  To order by mail, request
a complete list of Kermit versions and an order form from Kermit
Distribution, Columbia University Center for Computing Activities, 612
West 115th Street, New York, NY 10025 USA.

------------------------------

Date: Tue, 12 Jan 93 11:40:00 EST
From: Frank da Cruz <[e-mail]>
Subject: MS-DOS Kermit, COM3, COM4, and Internal Modems

With the arrival of the new breed of low-cost high-speed internal
modems have come ever-increasing numbers of queries about how to use
them with MS-DOS Kermit, especially on COM3 or COM4.  With the help of
Joe Doupnik (author of MS-DOS Kermit) and John Klensin at MIT, we have
put together what I hope will be a useful guide to this complicated
topic.  This text has also been added to the MSKERM.BWR file.

TROUBLESHOOTING MS-DOS KERMIT SERIAL PORT AND MODEM PROBLEMS

  "Why can't MS-DOS Kermit find my COM3 or COM4 port?"
  "Why can Kermit send characters to my COM port, but not read them?"
  "Why doesn't Kermit work with my internal modem?"


First, rule out the obvious:  Is everything connected and turned on?
Did you give a SET PORT command for the right device, and did you give
it BEFORE any other device-related commands, such as SET SPEED and SET
PARITY?  Remember, port-related settings apply to the port that was
selected in the most recent SET PORT command, so a proper sequence
would be, for example:

  SET PORT COM2       ; First select the port you want to use.
  SET SPEED 19200     ; Then set the desired speed on the selected port,
  SET PARITY EVEN     ; and other parameters for this port, such as parity,
  SET FLOW RTS/CTS    ; flow control,
  SET LOCAL-ECHO OFF  ; and CONNECT-mode echoing.

Each of these parameters is remembered for each port, so switching
ports (e.g.  SET PORT COM1 after you have given the above sequence of
commands) switches all of these parameters to their previous (or
default) values for the port you have switched to.

To see the current port-related parameters, type the MS-DOS Kermit
command:

  SHOW COMMUNICATIONS

This displays all the relevant information about your currently
selected communication device, which is COM1 by default.  Check the
settings carefully to be sure they are what you intended.

  The following discussion, which applies to MS-DOS Kermit versions
3.11 and 3.12, is detailed and technical, but most of it boils down to
(a) installing a patch; (b) telling Kermit two numbers, the port
address and IRQ value; and (c) fiddling with your modem.  Keep that in
mind as you read more about PC hardware than you ever wanted to know.

HOW A PHYSICAL COMMUNICATION PORT IS ASSOCIATED WITH A DOS COMn DEVICE

DOS PCs come with full support for two communication ports, COM1 and
COM2, but with provisions for at least two more, COM3 and COM4.  The
basic problem with COM3 and COM4 is that they are not well (or
consistently) supported in most types of PCs, as are COM1 and COM2
which rarely (by themselves) cause any problems.  This discussion
considers only COM1-COM4, since higher-numbered COM ports are rare, and
in any case are not presently supported by MS-DOS Kermit.

The digit in the port name is an index into an area in memory that
contains the address of the serial port hardware.  The BIOS (the PC's
Basic Input/Ouput System) has four words reserved starting at segment
40 (hexadecimal), word 0, to hold the addresses of the first four COM
ports.  Word 0 defines COM1, word 2 (two bytes per word) defines COM2,
word 4 COM3, and word 6 COM4.  To view these addresses:

  C:\> debug             (start the debug program)
  -d 40:0                (display segment 40)
  -q                     (quit the debug program)

("C:\>" is the DOS prompt, "-" is the debug prompt.)  Here are the
results of this operation on a PS/2 with 3 COM ports:

  0040:0000  F8 03 F8 02 20 32 00 00-BC 03 00 00 00 00 60 03  .... 2........`.
  0040:0010  65 46 00 80 02 00 00 20-00 00 38 00 38 00 3E 34  eF..... ..8.8.>4
  0040:0020  20 39 78 2D 2E 34 78 2D-0D 1C 64 20 20 39 34 05   9x-.4x-..d  94.
  0040:0030  30 0B 3A 27 30 0B 0D 1C-75 16 67 22 20 39 00 00  0.:'0...u.g" 9..
  0040:0040  0A 00 C3 00 00 00 00 00-00 03 50 00 00 10 00 00  ..........P.....
  0040:0050  00 18 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
  0040:0060  0E 0D 00 D4 03 29 22 76-07 35 18 FF F9 C8 0F 00  .....)"v.5......
  0040:0070  00 00 34 12 00 01 00 00-14 14 14 20 01 01 01 01  ..4........ ....

The first line contains the COM port information (ignore the other
lines, as well as the funny characters on the right).  "F8 03" is the
2-byte COM1 address, expressed in hexadecimal (base 16) with the low
byte shown first.  Thus the actual COM1 address is 03F8 hex, which is
expressed in Kermit commands as \x03f8.  The COM2 address is 02F8, the
COM3 address is 3220, and (since there is no COM4) the COM4 address is
0000.  That is how both DOS and the BIOS (and hence many communication
programs, including Kermit) understand which ports are defined, and
where to find them.

When your PC is powered up, the BIOS startup code checks for serial
port hardware (that is, a Universal Asynchronous Receiver/Transmitter,
or UART) at the two port addresses 03F8 and 02F8.  If it finds a UART
at the first address then that address is placed in word 40:0 and
declared to be COM1.  Then the BIOS tries the second address and if
successful this address goes into the first available word at that
time, typically 40:2 as the address of COM2.  Thus if you remove a COM1
device then a previously COM2 device will appear in the COM1 Bios
storage area and become COM1 to DOS and Kermit.  What happens to the
other two words depends on the PC model and BIOS.  The IBM PS/2 BIOS
fills in all four words on startup, but most others (there are
exceptions) handle only the first two because that's how IBM did it
with the original PCs.

  So... just setting switches or jumpers on a serial port board or
internal modem does NOT define the board to be a particular COM port.

Why, then, do some communication programs work with COM3 and COM4
without any special fiddling?  The answer is that these programs ASSUME
that COM3 and COM4 are found at certain addresses, even when there are
no entries in segment 40, the BIOS communication-port area.  Some of
these programs show you their assumptions in a menu (and might allow
you to change them), others do not.  The assumed values are usually as
follows:

  Port   Assumed Address (hexadecimal)
  COM1        03F8
  COM2        02F8
  COM3        03E8
  COM4        02E8

  NOTE: PS/2s use different addresses for COM3 and COM4 -- 3220 and
3228, respectively, but these addresses are installed by the BIOS into
segment 40 when the PS/2 is started, so well-behaved communication
software (like Kermit) will use these addresses rather than the
defaults listed above.  Ill-behaved software will ignore the segment-40
addresses and erroneously attempt to use its own values, which, with
luck, might be correct but, more likely, will not work, or at worst,
can disrupt normal operation of your PC.

Unchecked use of an assumed port address is DANGEROUS if the device is
not really where the software expects, but the software goes ahead and
uses the address anyway, in particular if some other type of device,
say a network adapter, is at the given address.  It can also produce
unwanted conflicts under Windows, OS/2, and DesqView, whose drivers
often set the port's segment-40 word to zero when they want to use the
port exclusively and without interference, and then restore the real
address when they are done, and similar unwanted interference with Int
14H redirectors that allow serial-port communication software to be
used on network connections.

Unlike most other PC communication software, Kermit will NOT attempt to
use a communications port unless:

  (a) It finds its address in the BIOS comm-port area, segment 40, or:

  (b) You specify the address yourself

AND:

  The device at the given address passes certain tests, in which
registers (addresses related to the port's base address) contain
certain values that are legitimate for a UART.

In other words, KERMIT IS MORE CAREFUL than most other communication
software, because does not want to chance disrupting normal operation
of (or damaging) your PC.

SPECIFYING THE PORT ADDRESS

If you tell MS-DOS Kermit to SET PORT COMn (where n is 1, 2, 3, or 4),
and Kermit responds:

  Warning, no hardware for this serial port.
  This port will be operated through the BIOS as BIOSn

it means that Kermit did not find an address for the port in the BIOS
area or it did find one but the hardware at that address did not look
like an IBM-PC compatible UART.  If the cause of the message is a
missing address, you can tell MS-DOS Kermit the address of the port by
issuing the following command:

  SET COMn \xhhhh

where n is 1, 2, 3, or 4, and hhhh are four hexadecimal digits (0-9,
A-F) representing the 16-bit address.  This command not only informs
Kermit of the address, but also inserts the address into the
appropriate word in segment 40 so other programs can find the port
(assuming they follow the rules), and so you don't have to give this
command to Kermit again until after the next time you reboot.

After giving the SET COMn command, give a SET PORT COMn command for the
same port.  The SET COMn command must come first, then the SET PORT
COMn command, as in this example for COM3:

  set com3 \x3f8   ; Specify the address of COM3
  set port com3    ; Select COM3

How do you know what addresses to give?  Suppose you have purchased an
internal modem or an add-on serial port and you want to install it as a
particular COM port, say COM3.  The installation instructions for your
device will tell you how to do this.  The device must be configured --
generally by setting little switches or installing or removing jumpers.
The manual should tell you the address for each COM port.  You have to
make sure that the address that you have configured for the device
agrees with the address that Kermit will use.

Although it is not recommended that you guess at address values,
sometimes it is the only way (as often with inherited equipment), for
which occasions here is a list of the addresses commonly used for
serial ports and internal modems:

  Port   Likely Addresses (hexadecimal)
  COM1       03F8
  COM2       02F8
  COM3       03E8, 3220
  COM4       02E8, 3228, 02E0

It is relatively unlikely that you will find a serial port at any
address not listed above, but you might find a port at another port's
expected address.  The use of these addresses in SET COMn commands
should be relatively harmless (provided you don't also specify an
interrupt, explained later); if there is no error message, Kermit found
a possibly usable port.  If there is an error message, no harm should
have been done.

Now let's look at the other cause for the "This port will be operated
through the BIOS" message, namely that an address was found in segment
40, but the device at that address does not appear to be a genuine
serial port.  Why would this happen?  There are several possible
explanations, including:

 1. The device is at a different address.  Check your device's
configuration again, or else your SET COMn command.

 2. Your device is indeed at the given address, but its registers do
not contain values expected of a true PC serial port.  In that case,
BIOS operation is the only alternative.

 3. Your device is at the given address, but there is a conflict with
another device at that address or the machine's bus speed (not CPU
speed) is set so high that the hardware test gave confusing results.

When Kermit operates a port through the BIOS, rather than directly, it
will be MUCH slower and might not work at all because the BIOS requires
the CD, CTS, and DSR modem signals to be asserted by the device
connected to the port (and the CD signal is normally and by default NOT
asserted by a modem before it has made a connection to another modem).
In that case, you will have to configure the device (e.g. modem) to
assert DSR, CTS, and CD always, or wire your modem cable to fake these
signals (e.g. by cross-connecting them to DTR).

Assuming you have found the right address for your COM3 or COM4 port
(or nonstandard address for COM1 or COM2), and you want these addresses
to be set correctly for Kermit at all times, even if it doesn't read
its initialization file, you can put a command like the following in
your AUTOEXEC.BAT file:

  set kermit=com3 \x3e8; com4 \x2e8;

If you want the addresses to be set correctly in the BIOS
communications area, so all applications (not just Kermit), can find
the ports, put a line like this in your AUTOEXEC.BAT (substituting the
appropriate ports and addresses):

  kermit -f nul, set com3 \x3e8, set com4 \x2e8

INTERRUPTS

  "I can send characters to the modem, but I never see any on my
screen."

This common complaint (often arising from the user's observation of the
modem lights and speaker), also known as "can-talk-but-not-listen
syndrome", usually means that the communication device was found at the
expected address, but Kermit's idea of its interrupt is wrong.  What's
an interrupt?

To achieve high-speed communication without interfering with other
applications, Kermit reads characters from a serial device using
"interrupts".  Whenever a character arrives at the serial device, the
device sends a signal, called an interrupt, that may be "caught" by
application software such as Kermit, leaving the application free to do
other work in the meantime without having to constantly look at the
serial port to see if any characters have arrived (an operation called
"polling", which is used by some of the other communications programs).
Communications programs that use polling are not sensitive to
interrupts being set properly and may therefore work with
improperly-configured machines where Kermit will not (unless you give
it the required information), but they also tend to take over the
entire computer.

In contrast to polling programs, Kermit is normally waiting for input
from the keyboard, and is therefore idle if you are not typing and no
characters are arriving at the communication port.  In multi-tasking
environments such as Windows or OS/2, this allows other applications
the largest possible share of the CPU while Kermit is running.

When a character arrives at the port, an interrupt signals Kermit to
wake up from its keyboard-wait state and read the character from the
port.  But Kermit needs a way of knowing which device the interrupt
came from, so it will not erroneously read characters from the wrong
one.  The device is identified by an Interrupt Request (IRQ) number, a
small integer like 3 or 4.  The BIOS does not record the IRQ number
used by a serial port because the BIOS uses polling rather than
interrupts for serial port input and output.  Thus the communications
software has to know which IRQ to use.  By convention from the original
IBM PC, COM1 uses IRQ 4 and COM2 uses IRQ 3.  There is no standard for
COM3 and above, but certain conventions are normally followed:

  Port   PS/2  Others
  COM3   IRQ3   IRQ4
  COM4   IRQ3   IRQ3

  WARNING: Certain serial port cards and internal modems allow
themselves to be configured with different IRQ numbers (such as 9),
even on COM1 or COM2.  Check your device's installation instructions.

Some types of PCs (PS/2s, for example) allow sharing of IRQ numbers,
provided each application has its own interrupt service routine and
each such routine is built to chain interrupts properly (i.e. pass them
along to other applications if they have arrived at the wrong place).
This works, for example, with Kermit on a PS/2; you can run two copies
of Kermit under Microsoft Windows, one using COM2/IRQ3 and the other
using COM3/IRQ3 (i.e. two ports, same IRQ), both doing input and output
simultaneously with no confusion.  On most types of PCs, however, IRQs
can NOT be shared, and therefore each device must have a unique IRQ
number.  This caution applies especially when you have a serial mouse
on IRQ 3 or 4.

Once Kermit knows the address of a COM port, it tests to see which IRQ
number, 3 or 4, the device uses.  This is a safe test and does not
cause any modem signaling or communication to take place.  The PC
architecture has a limited range of IRQ numbers available, and so
(usually) there can not be a unique IRQ number for each serial port
when there are more than two.  This results in the common limitation
that no more than two serial ports can be active at once.

MS-DOS Kermit 3.12 and earlier test first for IRQ4, and then if there
is no response, IRQ3.  If both tests fail, a default value is used (on
PS/2s, the default is IRQ4 for COM1 and IRQ3 for COM2-4; on others is
it is IRQ4 for COM1 and COM3, IRQ3 for COM2 and COM4).  No error
message is given in this case, but "can-talk-but-not-listen syndrome"
is a likely result.

Some add-on communication boards or internal modems are set up to use
IRQ numbers other than 3 or 4 in order to avoid conflicts with COM1 or
COM2 and/or to allow more than two COM ports to be active at once.  But
this can be dangerous -- for example, IRQ 5 (which is sometimes used
for this purpose) is also used by the hard disk controller on the
PC/XT.  IRQ 7 is often used by network boards.  For this reason, Kermit
does not automatically test any IRQ numbers other than 3 or 4, and does
not use any other IRQ number by default.

But it is sometimes necessary, particularly on ISA (Industry Standard
Architecture) bus machines (PC/ATs and compatibles) and earlier (such
as PCs and XTs) to use an IRQ other than 3 or 4, for example when when
an internal modem is installed as COM3 on IRQ4, and then use of COM1
prevents COM3 from working, and vice versa.  This problem can often be
solved by reconfiguring the board to use an otherwise unused unique IRQ
number.  Ideally this would be a normally free IRQ such as 10 or 11,
but unfortunately most communication boards are not configurable for
IRQs higher than 7.  Here is a brief, and definitely not comprehensive,
guide to the low IRQ numbers (with IRQ numbers expressed in decimal):

  2  Normally available, but some video boards use it to obey an
obsolete standard for indicating vertical refresh.  Adjust video board
jumpers to not do this.  On 286's and above IRQ 2 is also known as IRQ
9: same IRQ, alternate number.  Windows 3.0 had difficulty with devices
using IRQ 2, but Windows 3.1 is better.

  3  Normally COM2 and COM4.  PS/2's use IRQ 3 for all serial ports
above COM1.  IRQ3 is also a favorite "factory default" of many local
area network (LAN) adapters.

  4  Normally COM1 and informally COM3 (except on PS/2s).

  5  Secondary parallel port.  Parallel ports are rarely
interrupt-driven (except for Novell RPRINTER users) so this wire
becomes free if you unjumper the IRQ on the parallel port board.  LAN
adapters are frequently placed on IRQ 5.  PC/XTs use IRQ 5 for the hard
disk.  Be careful with this one.

  6  Floppy disk drives. Leave it alone!

  7  Primary parallel port.  Remove as described for IRQ 5.  Be
careful, LAN adapters are frequently placed here.

  9  Alias for IRQ 2.

 10  Usually free.

 11  Usually free.

 12  Used by the IBM bus mouse, otherwise usually free.

 13  QEMM traps math coprocessor errors here, otherwise frequently
free.

 14  Used by hard disk on 286 and above.  Leave alone!

 15  Some SCSI controllers use this.  Usually free.

If your communication board uses an IRQ other than 3 or 4, you will
experience the "can talk but not listen" syndrome when using Kermit.
To force Kermit to both talk AND listen to the device, you must inform
Kermit of the device's IRQ number.  This is done in the SET COMn
command, after the address:

  SET COMn <address> <irq>

for example:

  SET COM3 \x03e8 5

When you include a number (like 3, 4, 5, 6, or 7) after the port
address (separated by a space), Kermit will skip its IRQ test and use
the IRQ number you have specified when you next give a SET PORT command
for that port.

  PLEASE NOTE that you MUST AVOID address and IRQ conflicts; these
items MUST NOT overlap existing equipment.  SERIOUS DAMAGE can result
if, for example, the IRQ number you give is the same as the one used by
your disk controller or network adapter.  Incorrect operation can
result if the interrupt is in use by a less critical device, such as a
mouse.

It is necessary to specify the IRQ number in either of these two
situations:

  1. The communication device uses an IRQ number other than 3 or 4.

  2. Kermit's IRQ test interferes with Windows or a similar
environment, and therefore must be skipped.

Check your PC's configuration carefully before specifying an IRQ
number.  Before starting Kermit, you can use certain public domain or
commercial utilities, such as MAPMEM, Northgate QAPLUS, Quarterdeck
MFT, or the MSD utility shipped with Windows 3.1 to get an idea of
which IRQ numbers are already in use (these utilities are, of course,
not foolproof -- for example, they can't tell what IRQs are used by
programs that are not presently loaded).

If, even after establishing the device's interrupt correctly, Kermit
still fails to operate correctly (or reliably), check to see whether:

  1. Some other device (such as a mouse or LAN adapter) is generating
the same interrupt.

  2. Some other software (such as a mouse driver) is catching the same
interrupt.

If you find a conflict, take whatever means are at your disposal to
remove it: remove the offending device driver or TSR from your
CONFIG.SYS or AUTOEXEC.BAT file, or turn it off temporarily (e.g. with
the MOUSE OFF command for certain mouse drivers); or reconfigure one of
the conflicting devices to use a different interrupt.

PROBLEMS WITH MODEMS

  "I just bought and installed an XYZ V-Dot-Everything internal modem, and
  it works with <name-deleted> and <name-deleted> communication packages,
  but it doesn't work with Kermit".

This has long been a common complaint about internal modems.  The same
complaint is also now being heard with alarming frequency about some of
the newer external modems.

With internal modems, particularly when they are installed on COM3 or
COM4, the most common problems are:

 1. Kermit does not know the modem's address, or the device is using an
IRQ number other than 3 or 4.  These problems can be fixed by giving
the appropriate SET COMn command to Kermit.

 2. The internal modem is installed incorrectly, with an address or IRQ
that conflicts with one already in use on your PC.

 3. The internal modem does not correctly emulate a real IBM PC serial
port, and therefore fails Kermit's hardware test, and therefore can
only be used through the BIOS.

 4. The device is in a laptop, notebook, or palmtop computer, and power
to the internal modem or serial port has been disabled in the CMOS
setup, or has been turned off automatically when the cover is closed or
the machine shut down.

In recent months (beginning about mid-1992) a new generation of
low-cost, high-speed modems, both internal and external, began to
appear on the market.  These modems typically offer a wide range of
features: V.32 and V.32bis modulation, V.42 and MNP error correction,
V.42bis and MNP data compression, etc.  Unfortunately, many of these
modems suffer from bugs not found in earlier (and usually more
expensive) modems.  The problems are generally related to
initialization of the modem and interaction with its command processor.
Some common complaints:

 1. An internal modem does not work at all; the modem becomes
nonoperational as soon as Kermit attempts to access it.  The cause has
been traced to the fact that Kermit's initialization of the modem's
UART is "too fast" for some of these new modems.  (This same
initialization sequence has been used for nearly a decade with no
problems, and still works on the well-known and reputable brands of
internal modems.)

 2. "Kermit won't dial or respond to modem commands".  The modem
ignores dialing or other commands from Kermit.  Or the modem ignores
commands when Kermit's PARITY is set to a particular value, like EVEN.
Or commands are not processed correctly above a certain interface
speed.

 3. "I can dial successfully, and in general send characters to and
through the modem, but I never get any characters back."  This looks
suspiciously like the "talk-but-not-listen" problem, but in some cases
it is a bug in, or a configuration problem with, the modem, having
nothing to do with Kermit: the modem is simply not sending any
characters to the PC.

 4. "After using the modem with <name-omitted> communication software,
it also works with Kermit, but it won't work with Kermit unless I run
<name-omitted> first."

And so on.  All of these are modem, not Kermit, problems.  Here are
some suggestions for overcoming them:

 1. Slow the UART-initialization sequence.  This is accomplished by
patch #11 to MS-DOS Kermit 3.11 and patch #10 to version 3.12.  These
patches have been tested successfully on several of the misbehaving
modems.  Get the patch file for your version of Kermit (3.11 or 3.12).
The patch files are in kermit/a/msr311.pch and kermit/a/msr312.pch on
watsun.cc.columbia.edu on the Internet, available via anonymous FTP.
Rename the file to MSKERMIT.PCH and put in the same directory as your
MSKERMIT.INI file, and start Kermit again.  At the MS-Kermit> prompt,
give a VERSION command to make sure the patches were installed.  If
not, give a PATCH command (or, better still, make sure that PATCH is
the first command in your MSKERMIT.INI file, and that your MSKERMIT.INI
file is in your DOS PATH so Kermit will always execute it).

 2. External modems only: Check that your modem cable has wires for (at
least) the TD, RD, SG, CTS, RTS, DSR, CD, and DTR RS-232 signals.  If
it does not, replace the cable with a real modem cable, or
(temporarily) configure your modem to compensate for the missing
signals.

 3. Read your modem manual and check your modem's configuration.
Perhaps its interface speed is locked to a different speed than the one
Kermit is using.  Perhaps it is set to use hardware flow control, but
Kermit is not.  Also, check its factory and/or saved settings, and
under what conditions they are restored (for example, are they restored
when the PC drops DTR?).  How are you selecting saved settings -- read
your modem manual about (for example) the difference between AT&F and
AT&F2.  Be aware that the AT&Fn commands might not restore all
S-registers, so double check them.  Be particularly sensitive to the
registers that control interface speed, modulation technique, error
correction, data compression, negotiation, and fallback, and note that
each modem maker probably uses different registers and commands to
control each of these features.

 4. Try the following sequence to initialize the port (using COM3 in
this example):

      SET COM3 <address> <irq>  ; (if necessary)
     SET PORT 3                 ; Select port 3
     HANGUP                     ; Drop DTR on port 3 SET PORT3
                                ; Re-initialize port 3

 5. SET PARITY NONE when talking to the modem, and then set parity to
whatever the remote host or service requires after making the
connection.  (WARNING: MS-DOS Kermit might set its parity to some other
value automatically as a result of automatic parity detection during
file transfer.)

 6. Ensure that your PC bus speed is 8MHz.  Some PCs (not PS/2s) come
with a BIOS SETUP facility that lets you change the PC's bus speed,
memory wait states, etc.  In general, it is dangerous to deviate from
the defaults, particularly from the 8MHz bus speed, which is a standard
for add-on devices, and might be required by your communication board
or internal modem.

 7. Modify HAYES.SCR, or whatever dialing script you are using, to take
extraordinary measures to ensure the modem is in command mode, and to
send its initialization commands very slowly and to try them
repeatedly.  For example, change "output ATQ0V1X1\13" to something like
this (note: the modem-related commands shown here are all relatively
portable -- you might also need additional modem-specific commands,
such as AT&F2 to load a particular configuration, or specific
S-register settings affecting speed, flow control, modulation,
fallback, etc.):

      WAIT 1 DSR         ; See if modem is asserting Data Set Ready
      IF FAIL FATAL -
       {No DSR signal: Is your modem connected and turned on\63}
      SET PARITY NONE    ; Use no parity
      SET COUNT 5        ; Try 5 times to initialize
      :INIT
      HANGUP             ; Modem is connected - hang up on it.
      CLEAR              ; Clear Kermit's input buffer.
      OUTPUT \B          ; Send a BREAK.
      PAUSE              ; Wait a second.
      OUTPUT \17         ; Send a Ctrl-Q in case modem is Xoff'd.
      PAUSE 2            ; Wait two seconds.
      OUTPUT +           ; Send the most likely escape sequence,
      OUTPUT +           ; which is "+++" with at least a second of
      OUTPUT +           ; "silence" before and after.
      PAUSE 2            ;  ...
      OUTPUT \13         ; Send a carriage return.
      PAUSE              ; Wait a second.
      OUTPUT A           ; Send an A.
      PAUSE              ; Wait another second.
      OUTPUT T           ; Send a T.
      PAUSE              ; Wait another second.
      OUTPUT \13         ; Send a carriage return.
      PAUSE              ; Wait a second.
      CLEAR              ; Clear away echo and response.
      OUTPUT A           ; Send initialization command.
      OUTPUT T           ; One character at a time...
      PAUSE
      OUTPUT Q           ; Q0 = Result codes enabled
      OUTPUT 0
      OUTPUT V           ; V1 = Word result codes
      OUTPUT 1
      OUTPUT X           ; X1 = Dial response level
      OUTPUT 1
      OUTPUT \13         ; Carriage return terminates the command
      PAUSE
      INPUT 3 OK         ; Wait for OK response.
      IF SUCCESS GOTO INITOK  ; Got one.
      IF COUNT GOTO INIT      ; Didn't, try again.
      ECHO Failure to initialize modem.  ; No more tries.
      STOP 1                             ; Fail.
      :INITOK

    If this doesn't work, insert a PAUSE command after each OUTPUT
command or run the script at a lower speed.

 8. Dial at a lower speed.  Make your interface speed match the
modulation speed -- e.g. use 9600 for V.32, 2400 for V.22bis, etc.
Turn off fancy modem options like error correction and compression.
etc etc.  NOTE: connection problems between the two modems have nothing
to do with Kermit and are beyond the scope of this document.  If a
modem appears to dial correctly, gets connection tones, and then hangs
up, it is undoubtedly a problem between the two modems (involving one
modem, both modems, and/or the phone company), and indicates a modem
configuration problem, a bug, or a basic incompatibility between the
calling and answering modems.

 9. Call your modem maker's technical support number.  Ask if they have
replacement chips to fix bugs in your modem.

------------------------------

End of Info-Kermit Digest
*************************

------------------------------

End of Info-IBMPC Digest V93 #12
********************************
-------