Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!psuvax1!psuvm!art100
From: ART100@psuvm.psu.edu (Andy Tefft)
Newsgroups: comp.sys.apple2
Subject: Re: vt100 terminal software
Message-ID: <90066.163534ART100@psuvm.psu.edu>
Date: 7 Mar 90 21:35:34 GMT
References: <490534e1.1b80e@scuzz.engin.umich.edu>
 <90064.233949SAB121@psuvm.psu.edu> <SCOTT.90Mar6214739@offa.cs.odu.edu>
 <1990Mar7.155826.25065@mintaka.lcs.mit.edu>
Distribution: na
Organization: Penn State University
Lines: 15

In article <1990Mar7.155826.25065@mintaka.lcs.mit.edu>, dcw@lcs.mit.edu (David
C. Whitney) says:
>
>Another problem is that the interrupt servicing overhead on a //e (or
>//c) is pretty high.  After the firmware and ProDOS have finished
>ignoring the interrupt, at least one or two characters have been lost
>IF YOU'RE GOING OVER 2400 BAUD. I've not had anyone complain of
>lossage at 2400 baud, but they have for 4800 and 9600. At those
>speeds, you'd want a Zip chip or something.

Actually, I've used Kermit on an enhanced (not accelerated) //e at 9600
baud with only very minor character losses (usually one every couple of
full screenfuls of data) and never while doing kermit protocol file
transfers. I think I tried Zlink on it, with the same results (but
no file transfers).