On Jul 15, 2019, at 2:51 AM, Johnny Billquist <bqt
at softjar.se> wrote:
This is getting interesting...
On 2019-07-15 05:55, Thomas DeBellis wrote:
Thanks, this isn't quite everything that I
was wondering about, but let me elaborate.
When a DN20 (PDP-11/34) is running embedded bi-sync to speak to an IBM host (via a KMC),
it is generically called a DN60 (the name for packaging software being DN62 or DN65). I
wonder how marketing came up with those numbers? I'm certain it provided significant
value-add while cost effectively thinking out of the box to /somebody/ over there... All
communications to the KL from RSX20F, DN20's and DN60's come through DTE20's.
But this question was not about DN60's, which I won't care about until such time
as I have a Hercules emulator I feel like getting busy with.
Who knows about how marketing works? There was also the DN92, if I remember right. Which
was based on a PDP8.
I can't remember what RSX20F had grown out,
but what I had heard was that the base was 11M as this had the smaller footprint (at the
time). That effort may have been headed by Ron McLean. It is a true statement that
DTE20 driver development would have been done in Marlboro.
No, it's much closer to 11D, and very little 11M. I have no idea why this was chosen.
But it's pretty clear when you read the sources. A lot of the improvements done in the
kernel in 11M are not there in RSX20F.
However, there was a pretty vast commonality in
the RSX code base.
Maybe less than you think.
If we talk about kernel internal code, then 11M, 11S and 11M-PLUS share a lot of code.
But other RSX variants do not.
At the application side, there was a vast commonality between RSX systems.
Specifically, I was wondering about two things:
1. What is the latest Phase DECnet that 11M will run? I guess the last
release was 93?
The last/latest release of 11M was in 1999. Which is still phase IV.
Same for 11S and 11M-PLUS. Other RSX variants stopped getting new releases in the 80s.
2. MCB; what was developed on it past your
snapshot (Phase II).
I can't even remember, or realize what MCB stands for now. :-)
At least in
Marlboro on the 36 bit line, while there was competition, there wasn't always an
intense amount of NIH. So the DECnet transport code was originally developed in user mode
in Tops-10. After debugging, it got merged into the Tops-10 monitor. Once (or while)
that was being done, the same code code base got merged into Tops-20.
The KL router code will do level 1. I don't remember what the DN20 would do. I
guess maybe Shoppa's site might have the latest MCB.
Some higher level code was written in BLISS. I have yet to chase NMLT20 down (the
Tops-20 NICE implementation).
The front end (RSX20F) code have run DECnet transport in theory, but not in practice by
Tops-20 version 4. Once they shut off 'aggregating' on the DH11's to
accommodate the VT100 smooth scrolling lossage, that poor 11 didn't have time for a
blessed thing. You could really tell the difference on the front panel between 3A (not so
much blinky) and 4 (plenty blinky!!) One site that I am aware of (CW) actually used an
additional DN20 to run RSX20F in order to put lines on it to share the load. Pretty cool.
I'm getting confused here. What do you mean by "shutting off aggregating on the
DH11s"? Up until the last release, Tops-20 ran serial lines through the FE PDP-11,
using DH11. There were no way to connect serial lines directly to the PDP-10.
However, if you connect through the network (ethernet), then everything goes directly to
the PDP-10, and the PDP-11 just sits there idling most of the time. So it would have had
time for lots of things, except there was nothing to do.
At my University we had one -2060 running Tops-20 V6 with 48 terminal lines, all on the
FE. No additional DN20 hooked up. Admittedly, this is still not a very large system, but
that number of lines worked without any problems. One extra cabinet installed to just fit
the distribution panels. In total three DH11. Hmm, might have needed one extra Unibus
expansion box, when I think about it. I could look inside the cabinet in a few weeks.
And it worked fine as far as smooth scrolling was concerned as well.
They really should have fixed the ^S/^Q padding
issue for smooth scroll, though...
Didn't even know there was one. Didn't notice any problems at the places where I
used KLs.
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