NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/vmsnet/misc/1175

Internet Message Format | 1993-01-23 | 4.3 KB

Xref: sparky vmsnet.misc:1175 vmsnet.internals:1788 comp.sys.dec:7091 comp.org.decus:1138
Path: sparky!uunet!elroy.jpl.nasa.gov!sdd.hp.com!hplabs!nsc!decwrl!infopiz!mark
From: [e-mail]
Newsgroups: vmsnet.misc,vmsnet.internals,comp.sys.dec,comp.org.decus
Subject: Re: Need faster async board...dlv11-J?  Something else?
Message-ID: <[e-mail]>
Date: 22 Jan 93 22:08:37 PST
References: <[e-mail]> <[e-mail]> <[e-mail]>
Distribution: world
Organization: INFO COMM - Computer Consulting, Redwood City, Ca
Lines: 75

In article <[e-mail]>, [e-mail] writes:
> In article <[e-mail]>, [e-mail] (Don Stokes) writes:

>> [e-mail] 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<<TT$V_ALTRPAR), 0);

--
Mark Pizzolato - INFO COMM Computer Consulting, Redwood City, Ca
PHONE:    [phone]    UUCP:  decwrl!infopiz!mark or uunet!lupine!infopiz!mark
DOMAIN:    [e-mail]