🚀 go-pugleaf

jeh@cmkrnl.com writes:
> There was a VT1xx terminal that worked in block mode... I want to say VT105,
> but that was a half-assed attempt at a graphics terminal.  

VT131.  There's one in my junk shed with dud video.  Yes, those things
are likely yo be a problem.  Of course there's nothing stopping one from
setting the COMMSYNC bit via a short program, even if there isn't a SET
TERMINAL command to do the trick.  Actually, that's probably a more
appropriate way to do things: have the program that loads the flow control
intercept stuff take a parameter of a terminal to set up.  It should sense
whether the intercepts have already been installed, and not do it again if
so.  But it can also set the COMMSPEC bit in the UCB of the device specified.

It's probably a good idea to have the loader check what type of terminal mux
it's dealling with before loading the intercepts -- it could load code for
other devices as appropriate -- the DHV11 isn't the only terminal mux DEC
developped!  8-)  (Of course the DHU11 uses the same driver.  What does the
DHQ11 use?)

Something along the lines of:

$ HWFLOW :== $UUCP_BIN:HWFLOW
$ HWFLOW TXA0:	! DHV11 code for TXAn loaded. COMMSPEC!HOSTSYNC set on TXA0
$ HWFLOW TXA2:	! COMMSPEC!HOSTSYNC set on TXA2. Intercept code already loaded
$ HWFLOW LTA100:! Will fail
%HWFLOW-E-NOSUPPORT, hardware flow control not supported for device LTA100:

etc

> Implements flow control for outbound data based on, I believe, the DSR 
> line.  The idea is that if you have a serial printer that waggles DTR for
> flow control (which is fairly common in PC stuff; Diablo or someone like that
> did it early on, and lots of others followed suit, even though it isn't 
> standard) you can wire this to the DTR input of the VAX port.  I don't know
> why they bothered since wiring it to CTS always worked fine for me. 

I take it the silly thing doesn't work with modem control enabled?

Is this likely to have compatibility problems with the RTS stuff?

> > The half-duplex method requires that [RTS] be held low unless transmitting
> > (or at least preventing the other side sending).  
> 
> And is therefore useless!  For our purposes anyway.  

Oh, yes.  But if it was doing it that way, you'd have noticed by now!

> They also put out some release note on, I believe, DS200 3.1 code, talking
> about the server "asserting RI [ring indicator]", when RI is of course not
> sourced by the terminal server! 

Some doco didn't know what he/she/it was talking about....


--
Don Stokes, ZL2TNM (DS555)                        don@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre            don@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand              +64-4-495-5052