Path: utzoo!utgpu!attcan!ncrcan!ziebmef!ross
From: ross@ziebmef.uucp (Ross Ridge)
Newsgroups: comp.sys.cbm
Subject: Re: Desterm 128 Questions
Message-ID: <1989Apr29.174422.4573@ziebmef.uucp>
Date: 29 Apr 89 21:44:20 GMT
References: <2091.244FF979@isishq.FIDONET.ORG> <2206@csd4.milw.wisc.edu>
Reply-To: ross@ziebmef.UUCP (Ross Ridge)
Organization: Ziebmef Public Access Unix, Toronto, Ontario
Lines: 75

In article <2206@csd4.milw.wisc.edu> jgreco@csd4.milw.wisc.edu (Joe Greco) writes:
>In comp.sys.cbm article <2091.244FF979@isishq.FIDONET.ORG>, izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) wrote:
>] > 2) I am having no luck with Eight bits, no parity--only garbage. Seven bits
>] > even parity works fine, though.  Any thoughts?  This garbage appears at
>] > all baud rates.  The DOV system accepts either automatically, and Kermit
>] > works fine either way.
>] 
>]   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.
>
>Funny, I had troubles too.  A local system I use constantly with 8N
>(UWM's Gandalf PACX network, on an MNP line) refused to work with
>DesTerm and 8N.  I had to switch to 7E.  And DON'T tell me it would
>not like 8N from any other terminal....  I'm using it right now.  :-?

Well, I can probabably guess what the "problem" is.  Most terminals
tend to treat 7E and 8N the same way, they ignore the high order bit.
My guess is that DesTerm, treats these differently and displays a
special character for char's above 127.  Your network maybe be 8N, but
your host computer may still be using 7E (this is the case with the
University of Waterloo's Sytek and Gandalf networks.). 

>] > 4) The VT-100 emulation seems to have many bugs.
>
>Understatement.
>
>]   Believe it or not, we implemented everything possible from the VT-102 
>]manual. We are discovering VT-100 "features" not mentioned in the DEC manuals 
>]but used by some systems.
>
>I ran into problems with 'sysline', and things went downhill from
>there.  I suggest that you have Matt look at Kermit, which has a
>beautiful VT100 emulation that I rarely have problems with (I have
>more problems with some VT100's at school....)  Also, check various
>releases of the VT100 manuals.  You know DEC... ;-)

Having written a terminal programme that can emulate the VT100 pretty
well, I know how easy is it is to goof it up.  Things like how handle
ESC[r, end of line, scrolling, and host of other sometimes obvious
looking items are easily botched. There are thousands of programmes out
there that have failed to do it properly, so don't give Geoff too hard of
a time.

I used the ANSI X3.64-1979 standard to write my terminal programme
(it's an ANSI conforming terminal programme, with VT102 additios.) For
VT102 emulation I actualy used a Rainbow manual. It turned out to be
better than the VT series manuals I've seen.

>] > While I realize that many users won't be using this
>] > program for micro <--> mainframe communications, for me it is CRITICAL
>] > to have near-perfect VT-100 emulation.
>
>Forget "near perfect."  Perfect is more important....  the last "near
>perfect" emulation I used sometimes goofed up where the cursor should
>be and I would mess up files while using my visual editor.  HIGHLY
>unsatisfactory.

Perfect emulation isn't really needed, the full VT100/102 command set
need not be implimented, but the ones that are have to be done perfectly.
My own terminal which leaves out a fair bit, works perfectly with Unix
(at least anything that uses termcap/terminfo), because it knows what
to do at the end of a line, not because it supports double
height/width characters.

							Ross Ridge

P.S. I'm not really trying to "push" my own terminal. I don't
distribute it, nor do I think it's a perfect VT100 termnial, it's just
a programme I wrote because there is nothing for a 64 with a BI-80.
-- 
 l/                   attcan!tmsoft!ziebmef!ross			 //
[OO]                   					                [oo]
-()-                                                                    -()-
 db                     6502 assembly forever!                           //