home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / dcom / modems / 20121 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  3.2 KB
  1. Path: sparky!uunet!ferkel.ucsb.edu!taco!gatech!darwin.sura.net!ukma!cs.widener.edu!dsinc!satalink!bert.tyler
  2. From: bert.tyler@satalink.com (Bert Tyler) 
  3. Newsgroups: comp.dcom.modems
  4. Subject: GATEWAY TELEPATH MODE
  5. Message-ID: <15127.1011.uupcb@satalink.com>
  6. Date: 27 Jan 93 11:12:00 GMT
  7. Distribution: world
  8. Organization: Datamax/Satalink Connection * Ivyland, PA (215) 443-9434
  9. Reply-To: bert.tyler@satalink.com (Bert Tyler) 
  10. Lines: 54
  11.  
  12.    john.navas@uttsbbs.uucp (John Navas) writes about MS-Kermit and modems...
  13.  
  14. John, let me dive in here and defend Joe D. and MS-Kermit some.
  15.  
  16. JN>                                    And where is it written that a
  17. JN>modem be able to accept any command sequence at the maximum speed of
  18. JN>the UART?  "Methinks the lady doth protest too much!"  <grin>
  19.  
  20. If your communications program or its script files generate and send
  21. any modem commands automatically, those commands are going to head
  22. down the line at the current connection speed.  I kind of prefer my
  23. communications program to do my dialing for me, and I rather expect
  24. my modem to be able to handle that case.  The same goes for any other
  25. modem commands I may find it necessary to send down the line.
  26.  
  27. JN><sigh>  The fact remains that most comm programs do NOT have problems
  28. JN>with the "current crop" of modems.
  29.  
  30. The problem is that the better/more thorough job a comm program does, the
  31. more likely it is to trip over problem hardware/BIOS implementations.
  32. MS-Kermit does an exceptionally good job - and sometimes pays the price.
  33. A case in point is a problem we ran into at the NIH with MS-Kermit and
  34. AT&T StarStations.
  35.  
  36. The symptom was that while receiving data at high speeds, MS-Kermit would
  37. suddenly lose all contact with the StarStation's UART.  Only taking an
  38. action that involved resetting the UART ("set speed nnnn") would
  39. reestablish communications.  Procomm didn't have this problem, so we
  40. were "obviously" dealing with a bug in MS-Kermit.
  41.  
  42. ...which turned out to be a bug in the StarStation BIOS.  We were
  43. apparently getting sporadic stray interrupt signals from the hardware
  44. at high speeds.  When that happens, it looks to the communications
  45. program just like a "real" interrupt, except that the UART it's looking
  46. at says "it didn't come from me".  When that happens to Procomm, Procomm
  47. simply throws the interrupt away.  MS-Kermit, being more thorough,
  48. passes the interrupt signal back to the preexisting interrupt routine,
  49. under the assumption that it might be dealing with an interrupt generated
  50. by some other device.
  51.  
  52. So far, so good - except that the StarStation BIOS apparently handles
  53. stray interrupts by *disabling* all interrupts on that IRQ, effectively
  54. disabling the UART's ability to inform MS-Kermit that it has any further
  55. data.  (AT&T apparently doesn't think of this as a bug - it's apparently
  56. an improvement over the IBM BIOS in their minds.  At least, they've
  57. declined to fix it.) We had to add special code to our copies of
  58. MS-Kermit that explicitly re-enabled interrupts after passing any
  59. interrupts back to the preexisting interrupt routine.  Boy, was
  60. *that* ugly.
  61.  
  62.                    Bert Tyler   (bert.tyler@satalink.com)
  63. ---
  64.  . DeLuxe./386 1.25 #343sa . Death is just God's way of dropping Carrier Detect
  65.                     
  66.