From: utzoo!decvax!harpo!npois!ucbvax!info-terms
Newsgroups: fa.info-terms
Title: Ambassador
Article-I.D.: ucbvax.7580
Posted: Wed Jun  9 00:47:03 1982
Received: Wed Jun  9 05:21:41 1982

>From teklabs!tekmdp!azure!stevenm@Berkeley Wed Jun  9 00:47:17 1982


------- Forwarded Message

From: tekmdp!teklabs!aat!sleat
Date: Sun  6 Jun 1982 at 0415
To: stevenm 




To: teklabs!stevenm
Re: aaa & mclure@SRI-UNIX

Not quite sure how to get from here to there, so maybe you could relay
this to him...



There's a good chance the problem is in the 2651 serial i/o chip (USART).
There are two of these on the logic daughter board, one for the host port
and one for the printer port.  A very simple way to test this hypothesis
is to swap the two.  If the problem goes away, or changes to weird behavior
on the printer port, that's probably it.  Of course you --might-- have two
bad ones, but it's not very likely.  To pin down which one runs which port
takes a little bit of tracing or a schematic or parts layout drawing.

Turning off error detection only affects parity checking.  Framing errors
are still flagged.  Note that you can see what the terminal thought the
character was by looking on the data monitor line.  In theory one should
be able to correlate the transformation on the data with known failure
modes of the 2651, but swapping the two is easier.

				  regards,
				  Michael Sleator @ Ann Arbor Terminals
				  ...!teklabs!aat!sleat



------- End of Forwarded Message