Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site bbnccv.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!bbnccv!jr
From: jr@bbnccv.UUCP (John Robinson)
Newsgroups: net.dcom,net.micro.pc
Subject: Re: ibm pc and interrupt driven asynch output
Message-ID: <93@bbnccv.UUCP>
Date: Thu, 4-Apr-85 12:09:36 EST
Article-I.D.: bbnccv.93
Posted: Thu Apr  4 12:09:36 1985
Date-Received: Sat, 6-Apr-85 02:02:41 EST
References: <23097@arizona.UUCP> <324@bu-cs.UUCP> <21@utastro.UUCP> <329@bu-cs.UUCP> <23122@arizona.UUCP>
Reply-To: jr@bbnccv.UUCP (John Robinson)
Distribution: net
Organization: Bolt Beranek and Newman, Cambridge, MA
Lines: 22
Xref: watmath net.dcom:929 net.micro.pc:3651
Summary: problem might be in asynch timing

Adding the extra stop bit introduces some delay, but as it is only
1/10 of a character time, it hardly seems that this is what is
helping.

What I would guess is going on is that the crystal generating the 1200
baud timing in your pc is in disagreement with that of the VAX (I'm
not saying who's wrong, necessarily).  The extra stop bit allows the
receiver in the VAX to reaquire bit-timing when the next start bit
comes in, whereas with just one stop bit, what is probably happening
is that the receiver can never resynchronize, and eventually the bit
sampler finds the bit after the stop bit (the start bit of the next
character, or the last data bit of the previous).  Recall that start
bits are 0 and stop bits (and idle lines) are 1.

So I would check the crystal generating timing on your PC, or that on
the VAX (do this by trying a port on a different interface, if
possible).  Meanwhile, the 2-stop-bit approach sounds like a good one,
and the penalty is only 10%.

Besides, it means you can talk to tty33's  :-)

/jr