> 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

Reply via email to