From: keith@ksmith.uucp (Keith Smith)
Subject: Re:  Serial and Parallel interface ??????
Organization: Keith's Computer, Hope Mills, NC
Date: Mon, 27 Jul 92 23:24:32 GMT

In article <1992Jul24.184318.18883@cc.ic.ac.uk> cmaae47@cc.ic.ac.uk writes:
>Intuitively I always knew that the 80xxx series of processors was a bad 
>product, now you give me another nail for the coffin. I can still remeber

Hehe,  The Z-80 Had a "flip-set" of registers for interrupt handling. 
The instruction to flip-flop them took like 3 cycles.  My favorite CPU.

>On the mint condition 1981 PC with an 8088 this may mean doing either a
>(floppy-) disk or a serial port transfer, and in particular telling the modem
                                                             ^^^^^^^^^^^^^^^^^
>to shut up for some time. This does not help nominal throughput, it cannot do,
 ^^^^^^^^^^^^^^^^^^^^^^^^

Uh ...  Okay, firing down CTS, or sending XOFF a buffer full (which is
even MORE instructions BTW) may stop your modem from sending chars to
the CPU, but what is gonna prevent the REMOTE site from continuing. 
Assume a dumb modem at both ends?

>as the CPU on the receiving end is the bottleneck.
>
>However, not obeying flow control will be more expensive, because files or 
>packets have to be retransmitted. We did exactly that here to get early 
>Kermits in binary form: read from the serial port, write to disk, if bytes 
>are lost ask for retransmission. Wasteful, but its get you going.

Exactly,  So Now your File Transfer Protocall is handling flow control
by not ACK'ing packets until the writes have completed.

>
>But the point is that NO manufacturer I know of has sold machines that 
>dropped bytes in transfers to and from floppy disks, I someone did they 
>certainly did not sell many of those. Serial (or parallel) ports should

Again, The dropping of characters cannot be guaranteed by the receiving
hardware, even with flow control.  In fact, YOU JUST SAID THAT U USED
ONE that required packet re-transmission.  That means the hardware
dropped the ball during the floppy write.  Period.  It was either
dropped by the SIO chip because the CPU didn't read it fast enough, or
it was dropped by a buffer overrun in the modem.  Otherwise there would
have been no neccesity to re-transmit the packets...

>have the same reliablility, and manufacturers should give people *exact*
>ideas what their machines can and cannot do. There is only one way to 
>achieve this: keep pestering them about it.

Again dropping chars has nothing to do with the hardware manufacturers
per se.  A properly designed File Transfer Protocall will not drop
characters provided no real hardware limits are exceeded.  This requires
cooperation between BOTH machines.

i.e.  A bit of well written assembler to do Zmodem will allow the 8250 on
the XT to run at 115K baud.  Your thruput however will not be quite that
good.

>
>Finally, a parallel port has got some big advantages. At low speeds, you can
>control a LED bar or a robot, at high speeds there is the fact that each byte
>is handed off and acknowledged. This is also done in (asynchronous) SCSI.
>

The problem with Parallel OR Serial is the lack of brains on both ends
of the interface, meaning the main CPU has got to handle ALL the
overhead.  Drop a CPU on the other side (as the case with async SCSI or
a parallel interface doing an ACK on each byte) and the WAY it is
transmitted becomes sort of irrelevant as long as both are on the same
sheet of music.

>The problem with SCSI is that there is a fairly rigid protocol, and that
>people who have SCSI buses on their computers usually have disks drives
>hanging off them. They are therefore reluctant to put anything onto a SCSI

The problem with SCSI is that it is a Peer to Peer protocall, and
requires a computer at both (all) addresses to handle the protocall.  In
other words mo' money.  A "standard" parallel printer (Centronics Style)
protocall is a hell of a lot more rigid than SCSI.  In fact, it doesn't
support bi-directional data transfer as spec'd.

>bus before it is known to behave correctly. Once it is understood what a
>peripheral does, the software has been debugged and the throughput 
>requirements are known it can well go on to the SCSI bus if that is 
>appropriate. But it could go onto a parallel port much earlier than that.

Well, If I'm debugging my new homebrew SCSI modem interface I wouldn't
really care either way because a software problem in my parallel port
modem driver could hang my machine just as quick, if not quicker than
one in my SCSI modem driver.  On the other hand I'd much prefer to
purchase one that already works either way in which case I'll simply
plug and play it.

The ONLY "STANDARD" parallel interface on IBM stuff is the one defined
in the timing diagrams in the back of most printer manuals which is ONE
WAY, OUT!

-- 
Keith Smith          uunet!ksmith!keith            5719 Archer Rd.
Digital Designs      BBS 1-919-423-4216            Hope Mills, NC 28348-2201
Somewhere in the Styx of North Carolina ...
Newsgroups: comp.dcom.modems