[Simh] RSX-20F

[Timothe Litt]

> 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.
>
Timing depended on what all was going on.  DECtapes were slow.  Floppy
seemed faster, but still very slow.  The RP06, being dual ported with
the -10 could take a while to acquire.  -20F did small I/Os, had no disk
cache and didn't worry much about caching ACP data.  All that was
secondary.  Running the peripherals was its real-time job.  Everything
else was secondary, and heavily overlaid to fit.  Plus, usually GEN
wasn't empty, and loading the parser wasn't preemptive.  Something else
had to finish and be kicked-out.

Yes, on an idle system running from disk it could be a few seconds
(though I don't think as few as 2).  On a busy system, a minute wasn't
unrealistic.

> 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.
>
I know all that.  I wrote device drivers and random applications under
11M V2, V3.something on 11/20s long before suffering with -20F.

I tracked down anti-social behavior in F11ACP - a truly miserable piece
of code that took modular programming to an extreme.  I know all too
well how it worked.  Zillions of files that had 3 pages of copyrights &
docs, a label, a set carry instruction and a return.  File pointer
windows that were cached in the UCB to do VBN to LBN translation.

Many un-mapped systems had (and have) loaders capable of relocating
tasks when activated.  You see some of that today on Unix, when a
sharable library is loaded.  VMS could deal with that as well.  In an
unmapped system, the big issue was fragmentation as tasks load and
unload.  Partitions were a cheap way of pushing that back on the programmer.

Partitions were also a way of avoiding runtime relocation overhead - an
idea (and a term) copied from older machines.  A design trade-off, but
not the only way.  But IIRC later version of 11M allowed multiple tasks
in the GEN partition.  I'm not sure if that was supported without memory
management.  There's no technical reason it couldn't have been, with
enough work.  I left 11M behind around that time.

-20F was not a general purpose OS.  It reused code from various sources,
but ended up being its own hybrid thing.

Mapping your own experience with those sources onto the -20F doc will
lead you astray.  It took enough from the other code to make you feel
comfortable -- then turned around and did something different without
telling you.

Truth is in the bits, not your expectations.

>
> So some things is not pure -11M.
>
Isn't that what I said?  And the doc said?


> 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+.
>
Probably.  But unless you also have 11D code, don't be too sure.  11M
practiced code reuse before it was popular.  M may have started with D's
BOOT.

> 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...
>
I dealt with 11D in the mid-70s.  Had the joy of benchmarking some telco
OEM applications - including COBOL.  Yes, COBOL on 11D with
unaccelerated packed decimal.

I seem to recall that 11D had loadable device drivers that ran as tasks
(before 11M added loadable driver support.)  But those I loaded; I
didn't write any.  I rather suspect this was the basis of the 20F drivers.

Oddly enough, I don't make this stuff up.

Keep digging, and you will validate what I have written. 



-------------- 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/40fc030a/attachment.bin>