From: utzoo!decvax!harpo!npois!ucbvax!info-terms Newsgroups: fa.info-terms Title: Ambassador Article-I.D.: ucbvax.7579 Posted: Wed Jun 9 00:16:26 1982 Received: Wed Jun 9 05:20:24 1982 >From teklabs!tekmdp!azure!stevenm@Berkeley Wed Jun 9 00:15:38 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