On 2015-03-19 15:15, Timothe Litt wrote:
On 19-Mar-15 09:13, Johnny Billquist wrote:
On 2015-03-19 04:21, Timothe Litt wrote:
On 18-Mar-15 20:34, Rich Alderson wrote:
[1] Developed mostly from RSX-11M, with a few nods to RSX-11D, at
least as far as the doc writers were concerned.
-11M, but -11D device drivers and a heavy dependence on event flags.
No memory mapping; it was a stripped-down environment.
1 RP04/6 disk dual ported; the 11 driver had to deal with 18-bit (576
byte)
formatted sectors.
The queued protocol provided access to unibus peripherals, including
async lines, card reader, LPT and (my secret contribution, a
battery-backed-up
TOY). This wasn't pure pass-thru; the 11 did a lot of the low-level
control and
presented abstracted devices.
This is getting rather far off-topic, but anyway...
Do you have any source for the claim about -11M with -11D device
drivers? As far as I know, one of the major differences between -11M
and -11D is just the device drivers, as the whole I/O subsystem was
redesigned in -11M, for a smaller memory footprint and better efficiency.
-11D could not run without an MMU, while -11M can. Thus it sounds
strange that you'd have -11M with -11D device drivers. I would suspect
that would be impossible, and in addition the -11D device drivers
would require more resources than their -11M counterparts, which would
be rather opposite of what was required of the 11/40 FE, which is
rather limited on resources.
My recollection of RSX-20F is that it very much feels like an unmapped
-11M system. Some changes because of the special requirements, but
nothing major.
Johnny
Well, I spent more time than I should have needed to debugging RSX-20F.
It was rather a fragile environment. There are source listings available
on the later swskit tapes. Look for yourself.
I started poking around some, but I've not seen any listings for the
kernel itself, only some tools so far.
Thankfully, I didn't write -20F. So the origin story is what the developers
told the corporate support folks, who told me. Plus what I found in the
sources. I didn't dig into why the design choices were made. I just lived
with the consequences. I can provide some context.
:-)
20F seemed to have been patched-together to produce something a bit
more user-friendly than KLDCP. From working with it, it appeared
to value programmer efficiency and time to market over performance
or making best use of the available hardware. It 'met requirements',
barely. Activating the command parser, the primary user interface,
took the better part of a minute. And it took over the one
partition available for UI tasks. 20F was not DEC's best engineering.
I've definitely been using RSX-20F on a KL-10 myself a few times. On our
machine it certainly did not take anything close to a minute to get the
command parser. It took a couple of seconds.
Did you run on a DECtape based system or something? Actually, since it
booted of the RP06 anyway, the console storage should matter even less.
Yes, you could only run one thing at the time. That's a pretty normal
effect from running on an unmapped system. In addition to there not
being much memory, all tasks also have to be task built (linked) to
physical addresses. You do not have virtual memory on the RSX-20F system.
And all programs are task built to run in the same memory partition, so
it's pretty much impossible to run two programs at the same time in the
common sense of the word. F11ACP is an example of a separate program
that runs at the same time as your command. But F11ACP runs in a
different partition. And there are a few other tasks that are task built
to run in that partition as well, so F11ACP can also be forced out of
memory.
But it did do remarkable things, like fix microcode parity errors
on the fly. Something no other DEC product did successfully for
another DECade or so.
That sounds like scary magic.
I had worked on -11M systems prior to dealing with -20F, and it didn't
look at all like -11M from a system services point of view. If there
was 11M in there, it was not exposed. Devices didn't do the usual
11M fork. The ISRs set an event flag, and a user-mode (well, non
interrupt task) did the work typically done by an 11M fork. I can't
say for sure that's how 11D did its drivers - I'd used 11D, but never
got into its internals.
This is one thing I'd like to find some more code for.
One difference I noted from -11M though, is that RSX-20F have a doubly
linked active task list, with an explicit NULL job in there. -11M do not
have such a structure, or a NULL job. The NULL job in -11M is actually
just the scheduler sitting around rolling its thumbs.
So some things is not pure -11M.
But looking at a few bits and pieces I manage to find list files for,
BOOT.MAC is definitely from RSX-11M. I can even see some of that code
still in the latest version of -11M+.
I also found the device driver list files, and you are absolutely right
that those do not work like -11M device drivers do. They seem to
actually be tasks in some magic way. Very interesting. There are more
details I'd like to know, but I don't have the time to dig further into
that right now...
So it would appear to be a strange mix.
It was a miserable environment to work in. In theory, one could
build from sources on the 11/40, but I don't think I ever succeeded.
I think I let the build run for a couple of days once...never failed,
but never completed.
I did rebuild bits and pieces. Real work was built on another 11 -
11/70, I think, which also had the 16/18-bit mode RP drivers & knew
how to navigate the 10/11 overlaid file system. When I was dealing
with it (as a customer, then on behalf of some customers), I
eventually could cross-assemble & tkb bits and pieces on the -10 and
drop them into the 11's filesystem. Someone had written code to
read/write files-11 from the -10 side. Might have come from a
customer... Eventually, that was shipped with TOPS-10 as a much faster
install medium than DECtapes and RX01s.
By the time the 20F manual was written AA-BS94A-TK, the developers had
moved on and the tech writers did the best they could to reverse engineer
it. There is remarkable detail, courtesy of the listings (which were
pretty well documented.) And a lot of code reviews with people who'd
had to reverse-engineer bits and pieces. It's pretty accurate about
'what is', but 'how it came to be' was archeology. I think the manual
was first written in late '83; by that time, 20F was 5 or 6 years old.
The Intro states that 11M and 11D were the base on which 20F was built.
But the source for that statement was folklore, not the original
developer. I think I saw more references to 11D in the listings/
sources than to 11M - but I should refresh my memory. It's been
a while.
Settling which bits came from where might be an interesting project
for someone with endless time & period source kits for 11M, 11D & 20F.
I don't think you'll get Roland to fess up - if he's still around and
remembers...he didn't want to talk about it back in the day.
The bottom line is that 20F is not a good candidate for simulation.
It knew a lot about the DTE20 & hardware. Even black-boxing a
combined DTE/20F behavior 'device' is non-trivial, as KLH found
out.
This communication may not represent my employer's views,
if any, on the matters discussed.
Thanks for the details. It definitely sounds more messy that I want to
get into. :-)
Johnny
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
