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: Desterm 128 Questions
Message-ID: <2091.244FF979@isishq.FIDONET.ORG>
Date: 21 Apr 89 05:28:43 GMT
Sender: ufgate@isishq.FIDONET.ORG (newsout1.25)
Organization: FidoNet node 1:221/171 - Izot's Swamp, Kitchener ON
Lines: 68


 > From: ar1@h.cc.purdue.edu (Norton Lam)
 > Message-ID: <4521@h.cc.purdue.edu>
 
 > 1) There does not seem to be any way to send a Break.
 
   Break *will* be included in the next release.
 
 > 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.
 
 > 3) I have found that the program is reliable only up to 4800 bps.  9600 bps
 > is marginal.  (Mr. Welsh, I assume you're reading this: is there any way
 > to tweak the 9600 setting for maximum performance?)
 
(1) DesTerm's 9600 is already "tweaked for maximum performance". Our benchmark 
was the USRobotics Courier HST, which refused all other 9600 bps terminals for 
the 128 because they weren't accurate enough. Using a carefully calibrated 
oscilloscope for tweaking and the HST for verification, we chose our timing 
constants very carefully. We spent literally hundreds of hours determining the 
best code and constants...
 
(2) The 128's hardware limitations (bugs in the CIA chip as much as the lack 
of a UART) make it *impossible* for true asynchronous 9600 bps to be reliable 
if the 128 must both send & receive at 9600. No amount of tweaking will allow 
true full duplex operation at 9600. If there is demand, I may implement 
statistical duplex operation at 19,200 bps, which should provide performance 
equal to full duplex 9600 on lines that recognize the appropriate hardware 
handshaking lines.
 
 > 4) The VT-100 emulation seems to have many bugs.
 
   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.
 
 > Are there plans to upgrade the emulation for a future release?
 
   Matt and I are plotting a new release before the end of the month. When we 
let 1.01 out the door, we knew there would be problems (it supported only 
Hayes-type modems, it didn't work well with the 1670, YMODEM (batch) downloads 
*could* force the modem o hang up, etc... but we wanted to get something out 
the door. We will be improving the product constantly (or we wouls not have 
asked people to send in money to register it).
 
   By the way, the cure to the YMODEM hang-up problem (and a help to 1670 
compatiblity, though it does not cure all problems there), is to alter the 
main program with POKE 22211,44.
 
 > 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.
 
   For us, too. We use DesTerm with vi under AT&T Unix Sys V release 3.1.1, 
and with EDT under VAX/VMS.
 


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