From: gerg@netcom.com (Greg Andrews)
Subject: Re: Are 16550'a pin compatible with 16450's?
Date: Mon, 13 Apr 92 06:55:38 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Summary: I thought I said that...

In article <jb86cio@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>In article <sxrjr_d.gerg@netcom.com>, gerg@netcom.com (Greg Andrews) writes:
>> In article <1992Apr8.195056.16953@sj.ate.slb.com> poffen@sj.ate.slb.com (Russ Poffenberger) writes:
>> >jim@ferkel.ucsb.edu (Jim Lick) writes:
>> >:
>> >: For the last point, the software which doesn't know about the 16550 will
>> >: still benefit, but not as much as one which does.
>> >
>> >No. If the software can't enable the FIFO on the chip, it will act EXACTLY
>> >like a 16450, with NO improvement at all
>> >
>> 
>> Not completely true, I'm afraid.  If the software used the more proper
>> method of checking the Data Ready bit in the Line Status Register and
>> reading bytes from the UART until that bit turned off, that software
>> would work better when the buffers are enabled.        ^^^^^^^^^^^^^
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 
>> Most programs that aren't 16550-aware don't do that.  They simply read a
>> single byte from the UART and exit.  They certainly won't benefit from
>> having the buffers enabled.
>> 
>> But there were a few out there that had receive routines that kept reading
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^                           ^^^^^^^^^^^^^^^^^
>> from the UART until the UART told them to stop.  Those ones did benefit
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^^
>> when an outside program enabled the buffers for them.  Even though they
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> didn't have any 16550-specific code.
>
>
>Again, are you absolutely certain of this?
>

Results were seen with my own eyes.

>
>My National Data sheet strongly implies that that the FIFOs are bypassed in
>16450 mode, which means that a 16550A is EXACTLY like a 16450.  If the
>FIFOs were on while in 16450 mode, common and obvious 16450 software would
>break.  Such software WOULD NOT WORK, albeit in subtle and uncommon ways.
>

Look at the things I said.  I was specifically talking about a 16450-mode
program using a UART that had been placed into 16550 FIFO mode by an
**external program**.

In that case, a properly coded program would be able to send and receive
quite well.

What it wouldn't be able to do is optimize the buffer threshold for different
types of communications work (interactive vs file transfer).

>
>Any reasonable UART driver will always read data bytes until data-ready is
>false, regardless of whether you have a 16450, 16550, 8530, 16681, 8251,
>8274, etc etc etc.  This is because while you are processing the first byte
>in the buffer, the shift register is accumulating the next, and by the time
>you store away the first byte, increment the pointers, etc, the second byte
>may be ready.  If you just exit, depending on the interrupt hardware, you
>may lose the interrupt.  You generally check data-ready before grabbing
>the first byte, because the interrupt may be suprious.
>

You've just described the first type of program I mentioned in my article
("Most programs....simply read a byte and exit."), which do indeed fail.

>
>I have never, in 24 years of playing with modems and serial I/O ever seen
>of an implmentation where the interrupt handler simply assumed one exactly
>byte/interrupt.  Never.  I believe you when you such garbage code exists,
>but I have never seen it and don't want that changed.
>

That's MS-DOS for you.  It's become much better with the top comm programs
being 16550A-aware, but a few years ago....whew!


-- 
 .------------------------------------------------------------------.
 |  Greg Andrews   |       UUCP: {amdahl,claris}!netcom!gerg        |
 |                 |   Internet: gerg@netcom.COM                    |
 `------------------------------------------------------------------'
Newsgroups: comp.dcom.modems