Talk:RT-11
From Wikipedia, the free encyclopedia
I'd suggest including the Commons file named "DEC VT100 terminal.jpg". The image shows a directory listing on an RT-11 system.
This article has not yet been rated on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||
|
I think it would help to rewrite this to avoid saying `could be generated by the user', or to say what that means. I don't know, so I can't do it myself!
I think it means that someone with the source code could bootstrap their way up to a reasonable system through a process of assembly and site-specific modification.
I would modify the page if I was sure.
The process was known as a "SYSGEN."
Here's how RT-11 was shipped:
You got RT-11 on your choice of media from DEC -- for many early PDP-11's, this was DECtape, for later PDP-11's, it would be a series of floppies.
You'd boot the DEC-supplied version of RT-11. Then you'd run a DCL (DEC Command Language") Script named "SYSGEN.COM" -- which would invoke more DCL, a TECO macro or two and the Macro-11 assembler.
SYSGEN would walk the user through a (long!) series of questions as to which features in RT-11 the user wanted to include and what types of hardware the user wanted to support. All these responses would be put into a Macro-11 file that would basically be "FEATURE_SYMBOL==1" or "FEATURE_SYMBOL==0". This file was then included into the Macro-11 source stream of all the modules which were then assembled to create a custom-configured version of RT-11 -- including only those features and hardware drivers that the user asked for. A close equivalent today would be to run the GNU Emacs 'configure' script, which produces a "config.h" file that is then #included into the source stream that's compiled to produce Emacs. SYSGEN was exactly the same idea.
A SYSGEN process was not for the inexperienced user. Many of the questions required that you really know consequences (in both hardware and software) of what the SYSGEN process was asking you if you wanted the process to produce something usable/useful. Also, a SYSGEN was not something a user did lightly if they had a PDP-11 without a hard disk. I executed several SYSGEN's on PDP-11/34's (a relatively fast machine in it's day), but with only two RX-02 floppies (double-sided floppies -- I think they held 800Kbytes each). The slow speed of the floppy meant that a typical RT-11 SYSGEN would take (if memory serves) about 7 hours. All this time, the floppies were click-clacking and whirring, almost without any interruption. On a PDP-11 with a hard disk, a SYSGEN would take between 20 to 60 minutes.
Some other things I feel compelled to clear up:
Booting RT-11: RT-11 could be booted off DECtape (a random-access magnetic tape), floppies, hard disk or ROM.
Before RT-11 V5.0, a user could create a very functional RT-11 system with two single-sided (RX-01) floppies -- each floppy held about 400K bytes. I distinctly remember the PDP-11/03 system in high school as having only two floppies and we had on those two floppies:
a) the RT-11 OS (RT-11 SJ or "single job"), b) all the utilities (PIP, DUP, etc) TECO (the editor), c) BASIC-11, Multi-user Basic d) a swap file e) user files
In all that, we had about 120K total (between both floppies) for user storage.
Perhaps what people now don't realize is that in the 70's, a hard disk was a luxury item, especially for many PDP-11's stored in labs. A 5mb cartridge for a RL01 used to cost, oh, about $300. You could find them for less, but you would have to tolerate some bad blocks on the media.
RT-11 came in three variants: RT-11 SJ (single job), FB (foreground/background) and XM (extended memory model). SJ was just as you'd think -- no support for memory mapping, only a single task at a time. FB supported a foreground task and a background task. Most of the time, your command interpreter ran in the background. Foreground tasks were reserved for data collection. In this manner, RT-11 did support multiple tasks at the same time - provided that the foreground and background tasks weren't both trying to access the command terminal at the same time. Foreground data-collection tasks were best off if they did nothing but collect data and put it into a file.
The XM variant of RT-11 was for PDP-11's that had a memory management unit. This would allow extended (18-bit or 24-bit) addresses to be used. The OS would load the PAR (Page Access Register) and PDR (Page Description Register) for you from an extended address. Other than this, XM was like FB -- having provisions for a foreground and background task running concurrently.
While the FORTRAN-IV compiler on RT-11 was quite good (it would support many modes of optimization as well as overlays), most all real-time IO collection required that the user program in Macro-11. FORTRAN programs could call out to external libraries and it was typical that the user wrote only the IO routines in Macro-11 and then called them from a FORTRAN program. For experienced PDP-11 users, writing code in assembly using Macro-11 was not considered much of a hardship. It has been said that the C language had many features inspired by the PDP-11 -- for example *dst++ = *src++;
Well, in Macro-11, that would be:
MOVB (R2)++,(R3)++
which moves the character pointed to by R2 into the destination string location pointed by R3. Both registers are incremented by one as they're used in the instruction, just like the side effects in C. With only 87 instructions, writing assembly on the PDP-11 wasn't difficult at all and with the clean simplicity of the RT-11 OS, writing PDP-11 code on RT-11 was perhaps the easiest environment available in the market at that time for real-time process control and data collection.