Path: utzoo!utgpu!watmath!isishq!f171.n221.z1.FIDONET.ORG!izot
From: izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh)
Newsgroups: comp.sys.cbm
Subject: Re: Desterm 128 Questions
Message-ID: <2185.245690E2@isishq.FIDONET.ORG>
Date: 26 Apr 89 12:25:09 GMT
Sender: ufgate@isishq.FIDONET.ORG (newsout1.25)
Organization: FidoNet node 1:221/171 - Izot's Swamp, Kitchener ON
Lines: 33


 > From: dg@lakart.UUCP (David Goodenough)
 > Message-ID: <512@lakart.UUCP>
 
 > izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) sez:
 > ]  > From: ar1@h.cc.purdue.edu (Norton Lam)
 > ]  > 2) I am having no luck with Eight bits, no parity--only garbage. Seven
 > ]
 > ]    Perhaps the host is seven, even? I can assure you that DesTerm's word
 > ] construction is correct. If the host doesn't like 8N from DesTerm, then I
 > ] doubt it would like 8N from any other terminal.
 >
 > A distinct possibility - lakart runs all it's terminals (when not in raw
 > mode) as 7E1, and we're a UN*X system.
 
   Matt has come up with a more likely reason; because DesTerm handles PC 
graphics (hi-bit set), outcoming parity settings might be interpreted as 
graphics bits. The solution to this is to enable the "mask high bit" setting.
 
   As far as I'm concerned, "Mask high bit" is a short-cut that allows you to 
work with parity-based systems even if you don't know what parity they are 
(assuming they ignore incoming framing errors). Since you know 7E1 works, why 
not stick with it? DesTerm automatically switches to 8N1 for the duration of 
file transfers, so that isn't going to cause problems there.
 
   Geoff
 


--  
 Geoffrey Welsh - via FidoNet node 1:221/162
     UUCP: ...!watmath!isishq!171!izot
 Internet: izot@f171.n221.z1.FIDONET.ORG