[Simh] RSX-20F

[Timothe Litt]

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.

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.

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.

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.

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. 



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4942 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150319/2e2f40ae/attachment-0001.bin>