From: vulture@carrion.cc.ic.ac.uk (Thomas Sippel - Dau)
Newsgroups: comp.dcom.modems
Subject: Re:  Serial and Parallel interface ??????
Date: 24 Jul 92 17:43:18 GMT
Reply-To: cmaae47@cc.ic.ac.uk
Organization: Imperial College of Science, Technology and Medicine

In article <1992Jul23.011759.14499@ksmith.uucp>, keith@ksmith.uucp (Keith Smith) writes:
..... lots of good stuff about cycles available for a reading data from a
       serial port. Recommended reading. But I won't repeat it here.

Keith,

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
reading in L.A. Leventhal on the 6502 how to write a serial driver that uses
the V register to shift the bit in from the serial line, no need to pay
for those expensiv uarts ...

Yes, I know, you can only do so much with a processor at a given speed, and 
when there are 11500 interrupts per second to serve, most will grind to a halt.
"Modern" "Risc" chips are rather more affected by this if they use a stupid
"save all registers just in case" interrupt handler, since they have so many
registers.

But even when the throughput is limited, there is no excuse for dropping 
bytes as long as the processor has ways to control the total throughput.
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,
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.

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 
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.

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 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
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.

Nice talking to you                            Thomas
-- 
*** This is the operative statement, all previous statements are inoperative.
*   email: cmaae47 @ cc.ic.ac.uk (Thomas Sippel - Dau) (uk.ac.ic.cc on Janet)
*   voice: +44 715 895 111 x4937 or 4934 (day), or +44 718 239 497 (fax)
*   snail: Imperial College Center for Computing Services, Kensington SW7 2BX