Some PDP-11 info (was Re: C compilers for RSTS/E?)

From: Jerome H. Fine <jhfinexgs2_at_compsys.to>
Date: Sat Oct 23 23:19:35 2004

> Paul Koning wrote:

>>>>>>
>>>>>>
>
>
>
> Graham> Which reminds me... students at Groningen University wrote a
> Graham> multi-tasking system for the PDP that was loosely based on
> Graham> EMAS (big mainframe system from Edinburgh, sort of like
> Graham> Multics but better). I remember one feature of the OS was
> Graham> that it used an RT-11 format disk structure for raw storage
> Graham> even though the user view of files was quite different. For
> Graham> example I think RT-11 had version numbers (in the style of
> Graham> VMS), but GUTS showed only the top-level file, and had a
> Graham> "pop" command which deleted the most recent file and made the
> Graham> version below it visible.
>
>Not RT11... perhaps you're thinking of that modified system?
>
>
>
Jerome Fine replies:

You are correct. RT-11 has NEVER had version numbers!

>Sounds a bit like a project I did at the University of Illinois
>modifying RT11. It didn't get completely finished but it worked...
>Changed the USR to a collection of overlays (not one big overlay).
>Changed the file system to allow non-contiguous files while stilll
>being very efficient -- roughly speaking a RT11 style fast and skinny
>variant of ODS-1. Named directories, but no extension file headers;
>LBAs limited to 2^16. I still have the sources at least on paper.
>The overlay stuff required some assembler hacks, to make the overlays
>PIC. Basically, a feature to say "this code loads at X but executes
>at Y". There was partial support for that, as a hidden feature, in
>the older Macro-11 sources but it needed work to make it flexible
>enough. Some other systems offered that sort of thing standard (CDC
>6000s for example -- and GNU Binutils too, for that matter).
>
If you can find those sources, it would be VERY
appreciated. While the manner in which overlays
were handled is not critical, it would certainly
help reduce low memory.

BUT, even more interesting would be the information
about how non-contiguous files were handled.

PIC is standard in the USR since it moves up and
down in memory ALL the time. So I do not understand
why you even mention the PIC aspect, let alone that
something special needed to be done, although perhaps
with overlays, something extra was required. On the
other hand, device drivers which execute their overlays
within the USR buffer do that all the time.

The only aspect I see a being a REAL difficulty is that
it is on hard copy. Any idea how many pages.

At one point about 20 years ago, I started to write code
for the USR which allowed a Reference Date and Modification
Date for each file. Also useful was what VMS would call
the LNL (Logical Name List) which I would call a Path Handler
or something similar to the PATH NAME in DOS. A Pseudo
Device handler (PHX.SYS) would be used with, for example:
PH3: => LD2:, LD4:, DU3:
along with the ability to:
ASSIGN PH3: SRC:
so that the standard command files which are already
using device names such as SRC:, OBJ:, BIN:, LST: and
SAV: could be used unchanged.

Since little or no development is still being done,
especially at a commercial level, this would be of
interest ONLY for hobby users and would be done for
free. But since these would likely involve changes
to the USR and other DEC programs, the problem of
making changes to Mentec owned copyright poses a
problem.


Sincerely yours,

Jerome Fine
--
If you attempted to send a reply and the original e-mail
address has been discontinued due a high volume of junk
e-mail, then the semi-permanent e-mail address can be
obtained by replacing the four characters preceding the
'at' with the four digits of the current year.
Received on Sat Oct 23 2004 - 23:19:35 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:37:23 BST