home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / dcom / modems / 20154 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  3.9 KB
  1. Path: sparky!uunet!ferkel.ucsb.edu!taco!gatech!usenet.ins.cwru.edu!agate!netsys!decwrl!netcomsv!netcomsv!boo!uttsbbs!john.navas
  2. From: john.navas@uttsbbs.uucp (John Navas) 
  3. Newsgroups: comp.dcom.modems
  4. Subject: GATEWAY TELEPATH MODE
  5. Message-ID: <8848.48.uupcb@uttsbbs.uucp>
  6. Date: 27 Jan 93 23:56:00 GMT
  7. Distribution: world
  8. Organization: The Transfer Station BBS, Danville, CA - 510-837-4610/837-5591
  9. Reply-To: john.navas@uttsbbs.uucp (John Navas) 
  10. Lines: 67
  11.  
  12. bert.tyler@satalink.com (Bert Tyler) writes:
  13.  
  14.  JN> And where is it written that a modem be able to accept any
  15.  JN> command sequence at the maximum speed of the UART?  "Methinks the
  16.  JN> lady doth protest too much!"  <grin>
  17.  
  18.  > If your communications program or its script files generate and
  19.  > send any modem commands automatically, those commands are going to
  20.  > head down the line at the current connection speed.  I kind of
  21.  > prefer my communications program to do my dialing for me, and I
  22.  > rather expect my modem to be able to handle that case.  The same
  23.  > goes for any other modem commands I may find it necessary to send
  24.  > down the line.
  25.  
  26. Any comm software worthy of the name should provide for transmit
  27. character pacing.
  28.  
  29.  JN> <sigh>  The fact remains that most comm programs do NOT have
  30.  JN> problems with the "current crop" of modems.
  31.  
  32.  > The problem is that the better/more thorough job a comm program
  33.  > does, the more likely it is to trip over problem hardware/BIOS
  34.  > implementations.
  35.  
  36. With all due respect (and from the perspective of having written a
  37. good deal of comm software), I disagree.  BIOS is a non-issue.  And
  38. the only significant problem in recent years has been the unfortunate
  39. number of "brain-damaged" UARTs released by semiconductor manfs (not
  40. the modem folks, who are the victims).  That problem notwithstanding,
  41. some comm programs make assumptions about hardware operation that gets
  42. them into trouble.
  43.  
  44.  > ...which turned out to be a bug in the StarStation BIOS.  We were
  45.  > apparently getting sporadic stray interrupt signals from the
  46.  > hardware at high speeds.  When that happens, it looks to the
  47.  > communications program just like a "real" interrupt, except that
  48.  > the UART it's looking at says "it didn't come from me".  When that
  49.  > happens to Procomm, Procomm simply throws the interrupt away.
  50.  > MS-Kermit, being more thorough, passes the interrupt signal back to
  51.  > the preexisting interrupt routine, under the assumption that it
  52.  > might be dealing with an interrupt generated by some other device.
  53.  > So far, so good - except that the StarStation BIOS apparently
  54.  > handles stray interrupts by *disabling* all interrupts on that IRQ,
  55.  > effectively disabling the UART's ability to inform MS-Kermit that
  56.  > it has any further data.  (AT&T apparently doesn't think of this as
  57.  > a bug - it's apparently an improvement over the IBM BIOS in their
  58.  > minds.  At least, they've declined to fix it.) We had to add
  59.  > special code to our copies of MS-Kermit that explicitly re-enabled
  60.  > interrupts after passing any interrupts back to the preexisting
  61.  > interrupt routine.  Boy, was *that* ugly.
  62.  
  63. With all due respect, I'm afraid that AT&T was right and it wasn't a
  64. BIOS bug.  The BIOS should indeed disable any spurious interrupts
  65. (defined as an interrupt for which there is no handler) that might
  66. occur in order to prevent unnecessary system problems.  On an ISA bus
  67. there is no way to share interrupts, so if you were on an ISA bus
  68. system you should NEVER pass an interrupt that you own along.  And
  69. even on an EISA or MCA system it doesn't make any real sense.
  70.  
  71. Best regards,
  72. John
  73.                                                                           
  74. ----
  75. +------------------------------------------------------------------------+
  76. | The Transfer Station BBS (510) 837-4610 & 837-5591 (V.32bis both lines)|
  77. | Danville, California, USA. 400+ MB Files & FREE public Internet Access |
  78. +------------------------------------------------------------------------+
  79.