From: john.navas@uttsbbs.uucp (John Navas) 
Newsgroups: comp.dcom.modems
Subject: GATEWAY TELEPATH MODE
Date: 27 Jan 93 23:56:00 GMT
Distribution: world
Organization: The Transfer Station BBS, Danville, CA - 510-837-4610/837-5591
Reply-To: john.navas@uttsbbs.uucp (John Navas) 

bert.tyler@satalink.com (Bert Tyler) writes:

 JN> And where is it written that a modem be able to accept any
 JN> command sequence at the maximum speed of the UART?  "Methinks the
 JN> lady doth protest too much!"  <grin>

 > If your communications program or its script files generate and
 > send any modem commands automatically, those commands are going to
 > head down the line at the current connection speed.  I kind of
 > prefer my communications program to do my dialing for me, and I
 > rather expect my modem to be able to handle that case.  The same
 > goes for any other modem commands I may find it necessary to send
 > down the line.

Any comm software worthy of the name should provide for transmit
character pacing.

 JN> <sigh>  The fact remains that most comm programs do NOT have
 JN> problems with the "current crop" of modems.

 > The problem is that the better/more thorough job a comm program
 > does, the more likely it is to trip over problem hardware/BIOS
 > implementations.

With all due respect (and from the perspective of having written a
good deal of comm software), I disagree.  BIOS is a non-issue.  And
the only significant problem in recent years has been the unfortunate
number of "brain-damaged" UARTs released by semiconductor manfs (not
the modem folks, who are the victims).  That problem notwithstanding,
some comm programs make assumptions about hardware operation that gets
them into trouble.

 > ...which turned out to be a bug in the StarStation BIOS.  We were
 > apparently getting sporadic stray interrupt signals from the
 > hardware at high speeds.  When that happens, it looks to the
 > communications program just like a "real" interrupt, except that
 > the UART it's looking at says "it didn't come from me".  When that
 > happens to Procomm, Procomm simply throws the interrupt away.
 > MS-Kermit, being more thorough, passes the interrupt signal back to
 > the preexisting interrupt routine, under the assumption that it
 > might be dealing with an interrupt generated by some other device.
 > So far, so good - except that the StarStation BIOS apparently
 > handles stray interrupts by *disabling* all interrupts on that IRQ,
 > effectively disabling the UART's ability to inform MS-Kermit that
 > it has any further data.  (AT&T apparently doesn't think of this as
 > a bug - it's apparently an improvement over the IBM BIOS in their
 > minds.  At least, they've declined to fix it.) We had to add
 > special code to our copies of MS-Kermit that explicitly re-enabled
 > interrupts after passing any interrupts back to the preexisting
 > interrupt routine.  Boy, was *that* ugly.

With all due respect, I'm afraid that AT&T was right and it wasn't a
BIOS bug.  The BIOS should indeed disable any spurious interrupts
(defined as an interrupt for which there is no handler) that might
occur in order to prevent unnecessary system problems.  On an ISA bus
there is no way to share interrupts, so if you were on an ISA bus
system you should NEVER pass an interrupt that you own along.  And
even on an EISA or MCA system it doesn't make any real sense.

Best regards,
John
                                                                          
----
+------------------------------------------------------------------------+
| The Transfer Station BBS (510) 837-4610 & 837-5591 (V.32bis both lines)|
| Danville, California, USA. 400+ MB Files & FREE public Internet Access |
+------------------------------------------------------------------------+
From: Leo.Flood@f7.n8406.z86.toadnet.org (Leo Flood)
Sender: fredgate@cheswicks.toadnet.org