NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/dcom/modems/11112

Internet Message Format | 1992-07-25 | 3.6 KB

Path: sparky!uunet!mcsun!uknet!icdoc!cc.ic.ac.uk!carrion.cc.ic.ac.uk!vulture
From: [e-mail] (Thomas Sippel - Dau)
Newsgroups: comp.dcom.modems
Subject: Re:  Serial and Parallel interface ??????
Message-ID: <[e-mail]>
Date: 24 Jul 92 17:43:18 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail]
Organization: Imperial College of Science, Technology and Medicine
Lines: 55
Nntp-Posting-Host: cscgc

In article <[e-mail]>, [e-mail] (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: [phone] x4937 or 4934 (day), or [phone] (fax)
*   snail: Imperial College Center for Computing Services, Kensington SW7 2BX