From: bender@oobleck (Duke of Canterbury)
Newsgroups: comp.dcom.modems
Subject: Re: Serial and Parallel interface ??????
Date: 29 Jul 1992 02:19:15 GMT
Organization: SPARK's R US
Reply-To: bender@oobleck.eng.sun.com
NNTP-Posting-Host: oobleck
X-Newsreader: Tin 1.1 PL3

vulture@carrion.cc.ic.ac.uk (Thomas Sippel - Dau) 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
: 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 ...

What are you talking about?  I'm glad that you have a book written in 1978
that shows you how to make a 300-baud software UART, but the issue at hand
seems to be your claim (that I don't dispute) that your 1981 8088 system can
transfer 256K+bps from your floppy disk drive, while your serial port craps
out at 9600 baud.

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

I suppose that you've worked with many "Modern" "Risc" chips and have written
interrupt handlers for them and determined what interrupt load they can
sustain before they grind to a halt?

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

But if the CPU is so swamped with interrupts, who is going to do the
hardware and/or software flow control?  Transmit (i.e. outgoing) flow control
is easy - the remote device sends an XOFF or drops CTS, and your hardware
can stop sending, with no intervention from the CPU, but implementing receive
flow control in hardware gets a little tricky; when does your hardware tell
the remote device (a modem in this case) to stop transmitting?  When your
UART's FIFO is 1/2 full? Completely full?  Don't forget that many devices
such as modems that support RTS/CTS flow control will still transmit several
bytes AFTER your receiver's RTS line has dropped, so your receiver better be
able to receive several bytes AFTER you drop RTS.

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

You don't seem to understand that there are two different mechanisims at work
here - your 1981 vintage PC uses DMA to transfer data from the floppy
controller, which, BTW, has already done the clock recovery and
de-serialized the data stream off of the disk and presents it as 8-bit
parallel quantities.  DMA requires no CPU intervention once the transfer
parameters are set up and the DMA controller is triggered by an external
event, in this case, the floppy controller telling the DMA controller that
the former has a byte that it wants the latter to transfer into memory.  The
DMA controller grabs the system bus, transfers the byte from the floppy
controller to memory, and waits for the next byte to become available.  In
the meantime, the CPU can get back on the bus if it needs to.

Serial port transfers on the IBM-developed PC architecture on the other hand
are programmed I/O operations - the UART generates an interupt when some
conditions are met (i.e. one or more bytes in receive FIFO, transmit FIFO
empty, modem control signal change, etc...), and the CPU has to go service
that interrupt, which usually means doing some stack manipulation, diddling
with the UART to find the source of the interrupt, getting the data (if it's
an Rx interrupt), stashing the data away, and telling the chip that you're
done handling the interrupt.  This requires a lot of CPU cycles. As was
mentioned in another post, some PC applications continuously poll the UART
to get around the overhead of the interrupt handler and increase the
throughput, but the CPU must be involved much more intimately with the UART
than with the floppy controller duren the course of a normal data-transfer
operation.

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

Well, that's true IF you're using some sort of packetizing protocol, but
standard serial data transfer doesn't use anything other than a
user-selectable bit protocol (i.e. 5,6,7 or 8 bits/char :-), with NO
provisions for retransmission of corrupted data.  On a serial port, if you
loose incoming data, and there's no retransmission protocol, it's gone down
the shitter for good.  On a floppy drive, the data is still there and can be
read the next time the sector passes under the head.

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

How do you know this?  Maybe the OS retired the disk read, or maybe the
floppy controller had enough buffering for a sector's worth of data so that
if the DMA controller didn't get around in time to service the floppy
controller, no data would be lost?  There are a lot of disk retries going on
underneath the works that never get reported to the user.  Data loss on a
serial port, however, is must more noticable.

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

That's because disk drives have traditionally required "high" data transfer
rates, and serial ports were content to plod along at 300-baud FSK dial-up
acoustic-coupled modem speeds until relatively recently.

mike

--
The IQ requirement for being a phone operator may be pretty low, but the
required IQ for placing a call is just about vegetable level.  That's why
they kill sardines before canning them; if you let them swim around in the
can, it would heat up and explode.
Newsgroups: comp.dcom.modems