home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / dcom / modems / 11274 < prev    next >
Encoding:
Text File  |  1992-07-27  |  5.2 KB  |  108 lines
  1. Newsgroups: comp.dcom.modems
  2. Path: sparky!uunet!rde!ksmith!keith
  3. From: keith@ksmith.uucp (Keith Smith)
  4. Subject: Re:  Serial and Parallel interface ??????
  5. Organization: Keith's Computer, Hope Mills, NC
  6. Date: Mon, 27 Jul 92 23:24:32 GMT
  7. Message-ID: <1992Jul27.232432.5603@ksmith.uucp>
  8. References: <1992Jul21.205557.29123@cc.ic.ac.uk> <1992Jul23.011759.14499@ksmith.uucp> <1992Jul24.184318.18883@cc.ic.ac.uk>
  9. Lines: 97
  10.  
  11. In article <1992Jul24.184318.18883@cc.ic.ac.uk> cmaae47@cc.ic.ac.uk writes:
  12. >Intuitively I always knew that the 80xxx series of processors was a bad 
  13. >product, now you give me another nail for the coffin. I can still remeber
  14.  
  15. Hehe,  The Z-80 Had a "flip-set" of registers for interrupt handling. 
  16. The instruction to flip-flop them took like 3 cycles.  My favorite CPU.
  17.  
  18. >On the mint condition 1981 PC with an 8088 this may mean doing either a
  19. >(floppy-) disk or a serial port transfer, and in particular telling the modem
  20.                                                              ^^^^^^^^^^^^^^^^^
  21. >to shut up for some time. This does not help nominal throughput, it cannot do,
  22.  ^^^^^^^^^^^^^^^^^^^^^^^^
  23.  
  24. Uh ...  Okay, firing down CTS, or sending XOFF a buffer full (which is
  25. even MORE instructions BTW) may stop your modem from sending chars to
  26. the CPU, but what is gonna prevent the REMOTE site from continuing. 
  27. Assume a dumb modem at both ends?
  28.  
  29. >as the CPU on the receiving end is the bottleneck.
  30. >
  31. >However, not obeying flow control will be more expensive, because files or 
  32. >packets have to be retransmitted. We did exactly that here to get early 
  33. >Kermits in binary form: read from the serial port, write to disk, if bytes 
  34. >are lost ask for retransmission. Wasteful, but its get you going.
  35.  
  36. Exactly,  So Now your File Transfer Protocall is handling flow control
  37. by not ACK'ing packets until the writes have completed.
  38.  
  39. >
  40. >But the point is that NO manufacturer I know of has sold machines that 
  41. >dropped bytes in transfers to and from floppy disks, I someone did they 
  42. >certainly did not sell many of those. Serial (or parallel) ports should
  43.  
  44. Again, The dropping of characters cannot be guaranteed by the receiving
  45. hardware, even with flow control.  In fact, YOU JUST SAID THAT U USED
  46. ONE that required packet re-transmission.  That means the hardware
  47. dropped the ball during the floppy write.  Period.  It was either
  48. dropped by the SIO chip because the CPU didn't read it fast enough, or
  49. it was dropped by a buffer overrun in the modem.  Otherwise there would
  50. have been no neccesity to re-transmit the packets...
  51.  
  52. >have the same reliablility, and manufacturers should give people *exact*
  53. >ideas what their machines can and cannot do. There is only one way to 
  54. >achieve this: keep pestering them about it.
  55.  
  56. Again dropping chars has nothing to do with the hardware manufacturers
  57. per se.  A properly designed File Transfer Protocall will not drop
  58. characters provided no real hardware limits are exceeded.  This requires
  59. cooperation between BOTH machines.
  60.  
  61. i.e.  A bit of well written assembler to do Zmodem will allow the 8250 on
  62. the XT to run at 115K baud.  Your thruput however will not be quite that
  63. good.
  64.  
  65. >
  66. >Finally, a parallel port has got some big advantages. At low speeds, you can
  67. >control a LED bar or a robot, at high speeds there is the fact that each byte
  68. >is handed off and acknowledged. This is also done in (asynchronous) SCSI.
  69. >
  70.  
  71. The problem with Parallel OR Serial is the lack of brains on both ends
  72. of the interface, meaning the main CPU has got to handle ALL the
  73. overhead.  Drop a CPU on the other side (as the case with async SCSI or
  74. a parallel interface doing an ACK on each byte) and the WAY it is
  75. transmitted becomes sort of irrelevant as long as both are on the same
  76. sheet of music.
  77.  
  78. >The problem with SCSI is that there is a fairly rigid protocol, and that
  79. >people who have SCSI buses on their computers usually have disks drives
  80. >hanging off them. They are therefore reluctant to put anything onto a SCSI
  81.  
  82. The problem with SCSI is that it is a Peer to Peer protocall, and
  83. requires a computer at both (all) addresses to handle the protocall.  In
  84. other words mo' money.  A "standard" parallel printer (Centronics Style)
  85. protocall is a hell of a lot more rigid than SCSI.  In fact, it doesn't
  86. support bi-directional data transfer as spec'd.
  87.  
  88. >bus before it is known to behave correctly. Once it is understood what a
  89. >peripheral does, the software has been debugged and the throughput 
  90. >requirements are known it can well go on to the SCSI bus if that is 
  91. >appropriate. But it could go onto a parallel port much earlier than that.
  92.  
  93. Well, If I'm debugging my new homebrew SCSI modem interface I wouldn't
  94. really care either way because a software problem in my parallel port
  95. modem driver could hang my machine just as quick, if not quicker than
  96. one in my SCSI modem driver.  On the other hand I'd much prefer to
  97. purchase one that already works either way in which case I'll simply
  98. plug and play it.
  99.  
  100. The ONLY "STANDARD" parallel interface on IBM stuff is the one defined
  101. in the timing diagrams in the back of most printer manuals which is ONE
  102. WAY, OUT!
  103.  
  104. -- 
  105. Keith Smith          uunet!ksmith!keith            5719 Archer Rd.
  106. Digital Designs      BBS 1-919-423-4216            Hope Mills, NC 28348-2201
  107. Somewhere in the Styx of North Carolina ...
  108.