> 
> 
> [[Per Fogelstrom  suggests setting the vt200 to 7bits, no parity check]]
> 
> Hi,
> I tried that already, and also a :np: gettytab entry.
> Neither seemeed to make any difference.
> 
Ahh!!! NO I KNOW WHAT IT IS! Silly me, i fixed this about a year ago
when i did the R3081 port. This piece of code is from sccstart.

        if (tp->t_flags & (RAW|LITOUT))
                cc = ndqb(&tp->t_outq, 0);
        else {
   I========>>  cc = ndqb(&tp->t_outq, 0200);
   I            if (cc == 0) {
   I                    cc = getc(&tp->t_outq);
   I                    timeout(ttrstrt, (void *)tp, (cc & 0x7f) + 6);
   I                    tp->t_state |= TS_TIMEOUT;
   I                    goto out;
   I            }
   I    }
   I
The second call to 'ndqb' is done with flag = 0x80. This will catch chars
with the parity bit set and that char will be treated as a delay value.
I don't know why the scc driver uses this call with flag = 0x80 but
obviously it creates some undesired behaviour.

> 
> I also discovered that the mapping from tty numbers for SCC
> DECstations (all but 3100 and 5k/200) aren't mapped to bulkhead
> connectors in any sensible way.  I beleive I created mine with
> 
> 	(cd /dev; /bin/sh MAKEDEV scc0)
> 
> but tty0 ends up being the bulkhead connector labelled "3", and I
> assume tty1 is the bulkhead connector labelled "2", which *I* think is
> a bug.
> 
This is out of my universe, since i dont have a dec/mips. I could think
of dtop bus or/and mouse etc. Maybe historical reasons ?

Per