[Simh] RSX-20F

[Johnny Billquist]

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