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.
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.
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.
There was even a window system available, which sortof reminds of
Windows before 3.1. Played a little with it. It works, but it's a bit
limited. But from the pure graphics point of view, it's nice.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
