erast1@unix.cis.pitt.edu (Evan R Aussenberg) (02/16/91)
(ISC Unix/386, Comtrol Ultra16 & AT&T drivers)
Branching the Equinox thread... I have a Comtrol Ultra16.
Works very nicely. It will do (at your option) DTR and/or RTS
handshaking. I was getting printer overruns at 19.2 to the printer
(Xerox 4045) while loading fonts. Because the Xerox doesn't support
RTS handshaking and because the Ultra16 doesn't use the DTR line for
data handshaking (if that's the correct term) I made an easy mod to
the cable to unite the Xerox's DTR to the Ultra's RTS handshaking.
Works great. When people (this is an office) try printing to the
Xerox and its not powered-up the spooler now waits patiently.
Having done this, I thought I'd try the same thing for one of
our Wyse 150s. It seems the Wyse keeps up fine at 19.2 (usually) but
not at 38.4. Our Wyse doesn't support RTS so again I mapped its DTR
handshaking to the Ultra's RTS handshaking. Works great. But then I
ran Vpix. Worked Great. But, coming back to the shell by either
entering one from Vpix or quiting Vpix, at the point where the Wyse
must be handshaking (say- deleteing/inserting 20 lines in vi) I get
logged out and all my processes are killed as if I was on a modem line
(which I'm not) and DTR dropped. By the way, the DTR pins on the Ultra
side are not even connected for this particular terminal.
To summarize: RTS handshaking seems to work up until quiting
from Vpix. In Vpix, handshaking works. After quiting Vpix, the first
attempt at handshaking kills all processes and gets you a login. This
state remains until at least a warm reboot. Also- this state is only
for the port(s) that ran the Vpix session. Other ports will continue
to RTS handshake correctly.
I am talking with Comtrol, but I haven't had a chance to talk
to this one tech-support person in particular yet. In the meantime
any thoughts/experiences are welcome. If you can replicate my problem
I'd be interested as well.
Thanks- Evan.
--
Evan Ron Aussenberg
erast1@unix.cis.pitt.edu
IN%"erast1@pittunix"