> On Mar 7, 2021, at 6:42 PM, Johnny Billquist <b...@softjar.se> wrote:
>
>
>
> On 2021-03-07 23:00, Paul Koning wrote:
>>> On Mar 5, 2021, at 9:02 PM, Johnny Billquist <b...@softjar.se> wrote:
>>>
>>> On 2021-03-06 02:33, Paul Koning wrote:
>>>>> ...
>>>
>>>> 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.
>> 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 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.
> 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.
>
> Well, in P/OS you do have the option of also play graphics, and do different
> resolutions. But the "terminal" handling for it have similar limitations. I
> think blink isn't working the same as in a VT100, nor is reverse (if I
> remember correctly). And of course, smooth scrolling do not work you you
> don't scroll the whole screen, since the hardware isn't capable, and doing it
> in software would be way too slow.
Right, I forgot about partial smooth scroll. Blink could be done fairly easily
with EBO through the color lookup table; I haven't bothered doing that. Same
for bold. Reverse wasn't a problem in my experience.
paul
