roy@phri.UUCP (Roy Smith) (01/20/85)
I am running a number of C. Itoh CIT-101e CRTs at 9600 baud on
an 11/750 under 4.2 BSD. My termcap entries for these are straight
copies of the VT-100 entries, and my terminfo descriptions are based on
the VT-100 ones with a couple of minor additions (mostly adding
capabilities pertaining to the printer port, such as 'flush printer
buffer').
The problem is that the terminals occasionaly forget to send a
C-Q after they send a C-S. Part of the problem seems to be that the
terminal differentiates between C-S's you type on the keyboard and C-S's
it sends itself to do flow control. Note, I also have VT-102's (4800 baud)
VT-220's (yuck), ADM-5's, Volker-Craig VC-4404's (also yuck) and a
Graph-On GO-140, none of which exhibit this problem (they all have their
own problems...) plus an assortment of non-CRT's which do flow control
(HP plotter, GTCO digitizer, printers of various makes, etc) so I don't
think the problem could be in my software.
For the purposes of this discussion, the terminal can be in one
of 2 states. The 'good' state is when you power it on or do a reset. I
am not 100% sure, but I think the good state is also entered when you
type a C-Q on the keyboard. The 'bad' state is entered when you type a
C-S on the keyboard and don't balance it with a "closing" C-Q. This
occurs either by entering search mode in emacs (CCA version 162.43z) or
doing a C-S to stall tty output and use something other than C-Q to
restart it, in hit-any-key restart mode (I guess this means DECCTLQ is
off). I have classified applications where problems occur into 3 broad
classes.
1) The terminal is being used a a 'glass tty'. A good example
of this is doing ls (or ls -l) on a large directory or cat'ing a long
text file. Here text is being sent to the CRT at about as close to 960
chars/sec as you can get for extended periods of time with no escape
sequence to process. As far as I can tell, line lengths don't make a
difference. In the good state, this is handled fine. In the bad state,
the terminal will jam up every few lines. Hitting any key will restart
it, but it is still in the bad state. Hitting C-Q will restart it, and
I think put it into the good state.
2) You are printing stuff in printer-controller mode. This is
about the same as class #1 above, except that since the printer can only
go about 40-100 cps, it is sending a bunch of balanced C-S C-Q pairs.
Every few pages things will die and you have to hit C-Q on the keyboard
to restart it. I know that most printers send a C-S when their own
input buffers get some percentage full, and will send a second C-S if
the buffer gets filled to a second threshold (to guard against the first
C-S having been missed). I suspect that this occasionaly unbalanced C-S
C-Q pair is what causes the problem.
3) Running emacs. Here, as long as you are in the good state,
all is fine. As soon as you hit C-S to search, you get into the bad
state. Since terminfo does its own padding, the problem almost never
shows up while you are in emacs. It is only after you have exited and
left the terminal in a bad state with some 'glass-tty' application
running (and not doing padding) that the symptoms occur.
Another random problem is that occasionaly the terminal jumps
into smooth-scroll mode all by itself. I havn't noticed any correlation
between this problem and the C-S C-Q one.
I have been back and forth with CIT tech support in California
so many times that I suspect my phone bill exceedes the net's :-). So
far, they havn't even admitted that a problem even exists. They finally
admitted, however, that they had farmed the firmware out to some other
company to write. After endless phone conversations they let on that
the had a new version of the firmware, but said that it fixed some other
small bug, and not this problem (how could it, this problem "doesn't
exist")! I convinced them to send me a set of new proms anyway and
installed them in my terminal. They were right, it didn't solve the
problem. The 2 versions are V12C and V12De.
Has anybody out there had similar problems with the CIT-101e's?
Has anybody figured out how to solve these problems? Has anybody solved
the general problem of dealing with a defective product when the company
won't even admit anything is wrong? The most annoying part of this is
that I *like* the CIT-101e's, and would gladly buy more of them *if* the
company could fix this problem. They seem to have little inclination to
do so, howver.
If this posting harms the reputation of CIT, so be it. I think
I have invested more than enough of *my* time in trying to track down a
bug in one of *their* products. I even went so far as giving them a
guest account on my machine so they could putter around and try and
blame my system configuration somehow.
Please post replies to net.periphs, and thanks in advance.
--
{allegra,seismo}!vax135!timeinc\
cmcl2!rocky2!cubsvax>!phri!roy (Roy Smith)
ihnp4!timeinc/
The opinions expressed herein are mine, and do not necessarily
reflect the views of The Public Health Research Institute.