8 Mar
2021
8 Mar
'21
9:06 a.m.
On 2021-03-08 15:40, Paul Koning wrote:
Definitely more efficient from a software point of view.
Having two DHV11 in the machine, while only using 1 port on one of them,
and couple on the other, might be considered less efficient from another
point of view. ;-)
You could, of course, have done it through the terminal driver in RSX,
if you really wanted to. But I suspect they just felt the overhead
wasn't attractive.
I did SLIP in my TCP/IP going through the normal terminal driver.
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.
That jogged my brain. It wasn't reverse that was a problem. Bold was
where it could be a bit funny. Or possibly bold in combination with
something (reverse?).
The Pro would really have benefited from some hardware acceleration of
the graphics. The PDP-11 wasn't exactly a speed daemon when it came to
moving those pixels around...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Mar 7, 2021, at 6:42 PM, Johnny Billquist
<bqt at softjar.se> wrote:
On 2021-03-07 23:00, Paul Koning wrote:
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... :-) > On Mar 5, 2021, at 9:02 PM, Johnny Billquist
<bqt at softjar.se> wrote:
>
> On 2021-03-06 02:33, Paul Koning wrote:
>>> ...
>
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. 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.