home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / ibm / pc / hardware / 21668 < prev    next >
Encoding:
Text File  |  1992-08-12  |  2.9 KB  |  65 lines
  1. Newsgroups: comp.sys.ibm.pc.hardware
  2. Path: sparky!uunet!psinntp!tandon!tdbear
  3. From: tdbear@tandon.com (Tom Barrett)
  4. Subject: Re: How standard is hardware flow control?
  5. Message-ID: <1992Aug11.164547.27904@tandon.com>
  6. Organization: Tandon Corporation, Moorpark, CA
  7. References: <1992Aug10.181222.5443@tvnews.tv.tek.com>
  8. Distribution: usa
  9. Date: Tue, 11 Aug 1992 16:45:47 GMT
  10. Lines: 53
  11.  
  12. In article <1992Aug10.181222.5443@tvnews.tv.tek.com> dougs@tvnews.tv.tek.com (Doug Stevens) writes:
  13.  
  14. EEEK! Someone from Oregon... home of those hateful
  15. Springfielders :)
  16.  
  17. >We need to be able to operate to 115 Kbaud and transfer binary data. Does
  18. >anyone know whether packages that operate at this speed and do binary transfer
  19. >(LapLink and Commute come to mind as examples) use hardware flow control?
  20. >Do any packages use xon/xoff to do this?
  21.  
  22. There are non-AT UARTs which handle the handshaking at the
  23. hardware level (the old 6850 comes to mind).  In the PC world,
  24. the handshaking has to be done via software.  Since the system
  25. may be busy with some other task when the interrupt comes in
  26. to service the input FIFO, it may take a while before the
  27. hardware handshaking can be toggled... not a well though-out
  28. design, but then again 9600baud was hot back in the 80s.
  29.  
  30. Laplink is very creative in their communications SW... I
  31. suspect that they use a combination of simple interrupt
  32. routines (maybe even a polling routine), large RAM buffers,
  33. and hardware handshaking if a 6 conductor cable is used
  34. instead of the 3.  They probably guarantee that they can
  35. service the UART faster than the data arrives and place the
  36. data in a large RAM buffer.  When the driver senses that the
  37. buffer is almost full, it probably operates the hardware
  38. handshake and allows the buffer task to swing in a fresh
  39. buffer.  There are a few laplink-like public domain programs
  40. that I've seen on BBSes... you might be able to check around
  41. for the source code to see what they really do.
  42.  
  43. >The statement has been made that many communication packages commonly used on 
  44. >the PC have no provision for dealing with hardware flow control. How true is 
  45. >this? 
  46.  
  47. All of my BBS software has the capability of flow control.  I
  48. run a FOSSIL and FrontDoor as my primary communications
  49. package, with my USR Dual it requires at least 38400baud with
  50. hardware handshake and a 16550 (especially with multitasking).
  51. If I was transferring uncompressed data, the channel should be
  52. 57,600 to be more efficient (especially with ZMODEM which just
  53. sends and asks questions later).  
  54.  
  55. What with the new v.fast and/or 28.8kbs standards coming
  56. along, it is a good thing IBM is championing the new 600Kbaud
  57. serial standard.
  58.  
  59.  
  60. -- 
  61. Tom Barrett (TDBear)    tdbear@tandon.com                 voice 805-378-6207
  62. Tandon Corporation      tdbear@p6.f1006.n102.z1.fidonet.org fax 805-529-8895
  63. Sr. HW Design Engineer  "War is Peace, No is Yes, And We're All Free!" 
  64. [The views expressed herein may not be shared by the organization of origin]
  65.