Talk:RT-11

From Wikipedia, the free encyclopedia

You have new messages (last change).

Contents


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.

[edit] Some fine points about the base entry

The VT11 was not a 'display device', it was the vector graphics co-processor which was a device on the unibus. The VR-14 (14") and VR-17 (17") monitors were the actual display devices. The VT-11 would be 'told' where in memory to find the graphics instructions to process, which it would process and render to the screen. Alterations to memory resulted in immediate (or almost immediate -- at the next refresh) update to the display.

RT-11 did not run, in any way, on the PDP-10. It did run, however, on the entire line of PDP-11s from the first (the PDP-11/20) to the last (the PDP-11/93,94). It also runs on numerous PDP-11 clones.

[edit] All this trivia interesting information

A lot of this should be in the main article -- it's just the sort of stuff I like to see in articles on operating systems that I don't know anything about.

I do, however, know a lot about RT-11; it was and is my favorite operating system to program into. So easy! And so remarkably fast. I particularly liked the way disk I/O was kept efficient: all files were contiguous blocks on the disk. This meant you could get the OS to position you at the right place in the file, and from then on read or write with virtually no OS overhead. The kinda thing you want for a real-time system.

It was also fun programming in C under RT-11, even if it was that remarkably peculiar Whitesmith dialect of the libraries. Debugging C was a breeze (as on any PDP-11 system).

Wish I still had a reason to use it! Jpgordon 00:18, 12 Sep 2004 (UTC)

I second that, JP. RT-11 was a programmer's paradise.

So... It could do multitasking, to a degree.

Also, there were rumours about some TS kernel in versions earlier than 5 that was said to be multi-user and multitasking. These very rumours went on to say that it was separated from the rest of RT-11 and eventually became TSX-Plus. Hope that there is someone better informed out there to shed some light upon this. After all, I wasn't supposed to be aware of DEC products at all back then. ;)

6.3 (and global variables') names were case insensitive, so the RAD50 coding was used to store them. This coding allowed to stuff 3 alphanum characters in 2 bytes. Hey, it did matter at the time!


Now, to the previous comments.

If you want to learn what SYSGEN was like, get a Linux kernel and 'make config'. It's similar enough to make a brave man screech. :)

You could also generate all three kinds of kernel (was it called 'monitor'?) and boot them at will. SJ and FB used the same driver binaries. You had to generate a separate set of the drivers for XM.

Also, unless my memory fails me, XM could run up to 8 tasks.

[edit] word on USSR

same like RSX-11M was cloned for big machines, RT-11 was cloned for small ones. In many areas, including schools, there was small machines of 3 series (with a number of models in each):

  • ДВК - Диалогово-вычислительный комплекс (complex for dialogue-style computation)
  • БК (Бытовой компьютер, computer for home)
  • УКНЦ (учебный компьютер нацчного центра, educational computer for scientific centres).

In my school, there was УКНЦ of third generation. I heard also of 4th generation of it, but it was designed too late, to overcome the flood of cheap 2nd handed IBM PCs, when it finally fallen.

Those computers had a number of quite interesting little word processors, graphics editors, games, utilities (like KD.sys, turning 2/3 of video RAM into virtual disc), et cetera.

Most of core software, including Basic, that couls be booted from network w/o OS itself, was developed in Vilnus institute.

And i saw different versions of RT-11 clones, namely CD (same like SJ, perhaps with subtle difference) and FB.

Documentation of the computers was quite strange - there co-existed quite interesting ideas with a ery poor ones. Seems that enthusiasts tried to overcome shortness of money and technology, while non-enthusiastic people designed over parts. Manuals had finely documented pages, who were real textbooks to learn from. And they had almost senseless 2-3 word comments one many very inportant aspects as well :(

УК-НЦ for example had 2 processors: 8MHz (800K op's/sec) as CPU and 4 or 6 MHz as P(eripheral)PU. This PPU with it's own BIOS simulated absent hardware controllers for Video, sound, floppy, network and so one. Each of those processors had built-in debugger.

Lately, when i wrote in assmebler for IBM PC, i remembered that 1st computer i touched. Interrupts vectors in PDP-11 had no systematic way to find in memory, but taking them from some manual, You known who to control them. Opposite, IBM PC had systematic table of interrupt vectors - but no standard way to control devices, throwing interrupts.

Oooo... that is a lot offtopic here.

Turning back to OS itself, it's design made quite hard to make and install resident program into it, and impossible to unload it lately. But for device drivers management was much better. Guess it was the only OS, where many applications, like file manager (clone of famous NortonCommander) was implemented not as application, but rather as a device driver :-)

There was a number of projects to simulate ДВК or БК on IBM PC. Ad several attempts to simulate УКНЦ. Alas, i do not no of single successfull attempt for last :(

[edit] C Compiler

This page has been quiet for a long time, but I wanted to point out (and will eventually tweak the page) that a C compiler was never a part of RT-11, there were several after-market ones available, including (my aged brain cannot remember whose) an interpreted (!) one. I still have the 8" floppy disks in my basement somewhere. I will have to dig them out and see. -- Gnetwerker 06:23, 19 March 2006 (UTC)

That was it! I think the first compiler I remember was from Whitesmith's. -- Gnetwerker 18:41, 19 March 2006 (UTC)
There was a fairly good free C compiler from DECUS. I wrote a few software tools in it, and adapted ratfor to RT-11 and DECUS C. I learned a lot by reading the source that came with it (IIRC, the library came as MACRO-11 and C). I wish I could remember the names of the main authors. CWC(talk) 13:37, 20 April 2006 (UTC)
Dave Conroy. --jpgordon∇∆∇∆ 14:07, 20 April 2006 (UTC)
Thanks! Google shows a lot of Dave Conroys out there, but he's got to be the one at http://homepage.mac.com/dgcx/. Cheers, CWC(talk) 15:15, 20 April 2006 (UTC)

[edit] October 2006

Thanks to users Alaric 69 (talk • contribs) and 67.189.91.187 (talk • contribs) adding lots of information to the article, and thanks too to Gnetwerker for subsequent edits. I'd thought I'd pull out a few portions for discussion:

(1) "Even most early versions of VMS were written in MACRO-11."

It's true that VMS was descended from RSX-11M, which was written in MACRO-11, but AFAIK VMS was written in MACRO-32 and BLISS.

(2) In the para about SYSGEN: "(The Linux kernel uses a similar approach; see menuconfig.)"

I put this in partly to explain SYSGEN for modern techies and partly because I thought it was an interesting example of a discard engineering technique being resurrected. It's not important.

(3) ... the Tektronix 4010 family, "which was prominently displayed (and credited) in the original Battlestar Galactica."

Tek 4010s were used with many, many operating systems, not just RT-11.

(4) "The core OS ran as a process called RMON, or Resident MONitor, and if you saw an 'RMON-F-' message, you knew it was time to resort to the switches and lights that the PDP preferred to talk to you with."

Error messages of the form "?RMON-F-Trap to 10" were the equivalent of a kernel panic. IIRC, on some early PDP-11s, you had to use the Front panel to reboot the machine. (Later models had a small bootstrap ROM in I/O memory space.)

(5) "... while 'real' PDP's used UniBus (later MassBus), these used QBus, an LSI-logic oriented dual-state bus much more akin to modern bus layout."

Unibus was a backplane bus. (Aside: it played an interesting role in the history of the computer industry.) MassBus was a high-speed bus for mass storage devices that connected to a backplane bus. Q-Bus was a later, low-cost backplane bus.

(Please put your comments underneath this one, using "(1)", "(2)" etc to show which of these points you're commenting on.) Cheers, CWC(talk) 12:46, 19 October 2006 (UTC)

  • (1)Without a doubt. The deep parts of the kernel, the device drivers, and the like were written in Macro-32 and the file system, DCL, and CUSPs were written in BLISS-32.
  • (5) The Unibus and the Q-bus were very culturally compatible, differing primarily in the fact that the Q-bus multiplexed addresses and data and provided an interrupt scheme requiring fewer wires. (Later, the Q-bus allowed 22-bit addressing instead of the Unibus's 18-bit addressing.) Either bus could be transmitted over a combination of backplanes or cables.
Atlant 13:02, 19 October 2006 (UTC)


I also value the previous editors' contributions. I tried to comment out items that I could not figure out how to rephrase in a more encyclopedic tone. As someone who worked for several years building and developing RT-11 systems (and still have manyboxes of 8" floppies in my basement), I understand the desire to document the details that might give versimilitude or interest to the story, but I think that makes the article digressive and hard to read, not to mention, "unencylopedic" (admittedly a judgement call). I think the biggest problem with this article is not too little detail, it is that we have no supporting citations for what is here. Everything I left is consistent with my personal memory, but that was 25 years ago! I'd rather a smaller but well-sourced article than a discursive memoir, and I think it fits better. However, everyone's opinion counts, so feel free to disagree. Here are my comments:

(1) (VMS in MACRO-11) -- true, but not useful. It is perhaps interesting that MACRO-11 had such a complex (overblown?) macro system that you could write code for a (somewhat) foreign instruction set in it. This, however, it a fact that belongs in the MACRO-11 page, not here, IMHO; (2) SYSGEN -- It is interesting that RT-11 was compile-time configurable. It is perhaps interesting that Linux resurrected an old idea. That Linux did so is relevant to Linux, not so much to RT-11, unless you think there is a direct connection or lineage (I doubt it); (3) 4012s -- I worked at Tek in the early 1980s, actually, and on 4010s and 4012s, etc, were I did my first graphics programming. However, without a tighter connection to RT-11, I think the "Battlestar Gallactica" comment is irrelevant; (4) RMON -- The tone of the sentence isn't right. The colloquial tone of the system "wanting to talk with you" just doesn't fit an encyclopedia article. Something about RMON is perfectly appropriate; (5) Unibus/Massbus/Qbus -- The Unibus was not later called the Massbus, they were different, and the Massbus only appeared on the PDP-11/70, IIRC, and later the VAX 11/780. The differences between the (physically large and also expensive) Unibus and the smaller, slower Qbus are largely independent of the O/S, except at the detailed device-driver level. I think this belongs in the PDP-11 hardware pages, not here;

My thoughts. -- Gnetwerker 22:15, 19 October 2006 (UTC)

(The Massbus also was present on PDP-10 systems.)
Atlant 00:38, 20 October 2006 (UTC)
I've removed all 5 commented-out bits.
Instead of "backplane" bus I should have used "main system bus" or the like.
Does anyone want to add something about RMON? I see no great need to do so.
What was the name of the piece of the OS that implemented .CSI and could be unloaded from memory? Was it "USR"? Does anyone think we should mention it in the article? (I don't.)
I also removed this bit from the end of the "Filesystem" paragraph:
One problem with this structure (which DEC took pains to point out) was that this 'squeeze' operation (analagous to a defragment operation) could often only be performed once before problems arose, although in practice, most disks were 'squeezed' many times{{fact}}.
I don't think we need to go into that much detail, and it saves us hunting for a cite (which would be hard work at this stage!).
Cheers, CWC(talk) 13:55, 22 October 2006 (UTC)
Retrieved from "http://en.wikipedia.org../../../r/t/-/Talk%7ERT-11_db9b.html"