8 Mar
2021
8 Mar
'21
6:40 a.m.
On Mar 7, 2021, at 6:42 PM, Johnny Billquist <bqt
at softjar.se> wrote:
On 2021-03-07 23:00, Paul Koning wrote:
I realized I might have spoken too soon. There is also a comm port, and now I'm
unsure if DECnet isn't running over that one actually.
That would make a difference. The printer port is a 2661 on the Pro 350, or the gate
array equivalent on the Pro 380. Either way, it's a UART without a FIFO. The comm
port is an 8274, which has a 3 byte FIFO. So does the 2681 dual UART, which is what the 4
port comm card uses. In my tests, that FIFO makes the difference between running reliably
at 9600 baud, and getting frequent overrun errors.
On Mar 5,
2021, at 9:02 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2021-03-06 02:33, Paul Koning wrote:
DDCMP runs fairly well on RSTS with the printer port
at 9600, but I get some overruns. My guess is that the terminal driver (which is front
ending the DDCMP machinery) isn't as lightweight as the equivalent on RSX. Or do you
bypass the terminal driver and get a separate comms-specific driver for this case? > ...
I would have liked better comms. The USART has
such a tiny FIFO that you can't run it at higher than 9600 bps even with the J-11 CPU.
At least not with RSTS; perhaps a lighter weight OS can do better. The printer port is
worse, that one can't run DDCMP reliably at more than 4800 bps. I normally run DDCMP
on the PC3XC, which is a 4-line serial card that uses two dual UART chips (2681?) with
reasonable FIFO.
Hmm. I'm pretty sure I was running my -380 with the printer port for DDCMP on HECnet
for a while, and at 9600 bps. Anyway, in RSX, when running DDCMP on the serial port,
DECnet has its own device driver. So not talking through any terminal device driver, which
have all kind of features and capabilities expected for a terminal line.
Same with normal RSX, which is why you have to dedicate the whole controller to either
DECnet or TT. You can't mix.
That's probably more efficient. In RSTS I added the DDCMP support as an
"auxiliary" function attached to the terminal driver, so the regular terminal
driver does the device control and then diverts the data stream to/from the DDCMP driver.
It's a bit like how Linux does these things, I forgot what term they use. In fact, it
would be possible to add DDCMP support to Linux in the same way if someone wants to try
that... :-)
But with P/OS, you are not using the console port as
such. That's all on the graphics side.
But unless I'm confused, that's the same port. The printer port just can also be
the console port, if you short pins 8-9, right? Except it won't fully work the same as
the DL11, since interrupts work differently. But polled I/O will work the same.
But I would expect the speed characteristics to be the same for the console as for the
printer port.
Correct, printer and console are actually the same thing. If you use
the console cable (pin 8 connected to 9) then that materializes a DL11-like CSR set at
177560. Yes, with polled I/O such as the ODT microcode uses that works just like a real
DL11, but for interrupts it's different. In RSTS, either way that port becomes a
terminal port.
RSTS does have support for the graphics module, in "glass TTY" mode within the
initialization code and full VT220 emulation in RSTS proper. Well, except for blink mode,
and no bold in 132 column mode.