From: MERC::"uunet!WKUVX1.BITNET!MacroMan" 23-JAN-1993 04:48:27.58 To: MACRO32@WKUVX1.BITNET CC: Subj: Re: Need faster async board...dlv11-J? Something else? In article <1993Jan22.151835.1265@cmkrnl.com>, jeh@cmkrnl.com writes: > In article <9828020@zl2tnm.gen.nz>, don@zl2tnm.gen.nz (Don Stokes) writes: >> jeh@cmkrnl.com writes: >>> Good stuff! I've been mumbling about doing something along these lines... >>> I'm going to see if I can complete it and put a nice wrapper around it. >> OK, but note that I got the TT$M_MODEM!TT$M_HOSTSYNC test wrong. (It'll take >> the modified path if _either_ bit is set, not both. Originally, I just coded >> to look at TT$M_MODEM, until I realised that it would only call PORT_XOFF to >> output a BEL if HOSTSYNC wasn't set, dropping DTR until the port was >> re-initialised, which wasn't quite what I had in mind....) > > Mark Pizzolato and I were looking at using the new COMMSYNC characteristic. The > doc says that COMMSYNC shouldn't be used with MODEM, but SET TERMINAL does not > enforce this. My idea is to do RTR flow control if COMMSYNC, MODEM, and > HOSTSYNC are all set; if HOSTSYNC is set but either MODEM or COMMSYNC isn't, > send xon's and xoff's. It looks as though this will not interfere with the > standard use of COMMSYNC. This allows easy switching of the new code with the > existing SET TERMINAL command and $QIO interfaces. This sounds like the correct strategy and it has the right promise of actually working on any other modem control ports also (not just DHV stuff). I've got another problem to look into in this domain. The "Full Modem Control" port on the VS4000 (60 & 90) is either broken completely or the driver is simply broke. It doesn't even do CTS flow control correctly. I'm not sure if it doesn't even try to respond to the modem's transitions or if it simply is slow to respond due to not having an interrupt tied to the CTS transition and it determines these transitions by a periodic poll (TTY_SCANDELTA or something). >> (This is DECserver 200 V3.1) > > Yes, yes, I know that! btw, it also says > > When using CTS or DSR flow control, MODEM CONTROL must be DISABLED. > > I have never seen a DECserver 200 implement RTR (what is often called RTS) flow > control. Perhaps the RTS/CTS refers to the old half-duplex method. > > What is odd is that the 200MC *always* honors CTS from the modem (ie stops > sending when the modem drops CTS), just as the DHV and similar ports do, even > if flow control is disabled. I hope they don't "fix" this... > > But what I originally meant is that I can't manipulate the "DTE sourced" > signals, nor read the "DCE sourced" signals, from the VAX side (ie > IO$_SENSEMODE|IO$M_RD_MODEM, IO$_SETMODE|IO$M_HANGUP, > IO$_SETMODE|IO$M_SET_MODEM|IO$M_MAINT, etc., don't work). I can't even do > the equivalent of Local> SET PORT nnn FLOW CONTROL CTS, though thankfully, > changing the TT characteristics to turn off hostsync and ttsync have do have > the desired effect. Considering that the above functionality is not there, it is real odd that we CAN send a break through the Terminal server with the following code sequence: SYS$SETIMR(delay_efn, delta_200_ms, 0, delay_efn); SYS$QIOW(qiow_efn, Fdtty, IO$_SENSEMODE, &ttparms, 0, 0, &ttstart, sizeof(ttstart), 0, 0, 0, 0); /* get current settings */ SYS$QIOW(qiow_efn, Fdtty, IO$_SETMODE, &iosb, 0, 0, &ttstart, sizeof(ttstart), 0, 0, (ttparms.parity<<4)|TT$M_BREAK, 0); /* set the break bit */ SYS$WAITFR(delay_efn); /* wait (at least) 200 msec. */ SYS$QIOW(qiow_efn, Fdtty, IO$_SETMODE, &iosb, 0, 0, &ttstart, sizeof(ttstart), ttparms.speed, ttparms.fill, /* restore prev state */ (ttparms.parity>>4)|(1<