Talk:RT-11

I'd suggest including the Commons file named "DEC VT100 terminal.jpg". The image shows a directory listing on an RT-11 system.

---

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.

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.

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.

Although it probably doesn't need to be mentioned in the RT-11 article, in fact Unix *could* support real-time data acquisition; we did that at Geotronics Corp. in Austin TX by adapting 6th Ed. Unix in two ways: (1) added a real-time priority scheduler that always had precedence over the original scheduler; (2) added an A/D device driver that had double buffers (so it could fill one while the other was being read by the user-space app). We also added a Matrox bit-mapped display for field use, and RG-512 and VT640 Retrographics upgrades to our office terminals, for Tektronix-compatible interactive graphics. — DAGwyn (talk) 09:56, 8 September 2017 (UTC)

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 :(

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)

• Tiny C, maybe? --jpgordon∇∆∇∆ 17:46, 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)

I believe one of the authors of DecusC was Martin Minow (rip) Meganbg 22:49, 16 January 2007 (UTC)

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)

(4) Such messages were not equivalent of a panic. Trap to 10 indicated that the program you were running had attempted to execute an instruction which was unknown to that machine. Trap to 4 indicated that the program had attempted to access non-existent memory. Both errors result in the termination of the program, but not of the system.

re: Atlant's comments, maybe I should pull out the RT-11 documentation I have in my collection and provide some citations...

Meganbg 22:26, 16 January 2007 (UTC)

Citations are good!

Re (1) -- VMS V1 had significant components that ran in compatibility mode. I no longer remember specific examples. Those were likely to be in Macro-11, that being the primary application language for PDP-11 based OSs.

Re (3) -- Tek terminals, since they were plain async terminals, could be connected to anything that supported a Teletype and could be made to do interesting stuff given a bit of application software. I've seen them on RSTS, RSX, IAS (the latter two for Typeset-11) and I would assume they were found elsewhere. xterm has long had Tek emulation so presumably Unix systems had Tek terminals on them.

Paul Koning 14:45, 8 August 2007 (UTC)

Tektronix terminals were widely used throughout the interactive computer industry, but RT-11 didn't have any Tektronix-specific features. — DAGwyn (talk) 10:07, 8 September 2017 (UTC)

Question:

Are we sure that the foreground task is the non-interactive one and the background task is the interactive one in the RT:11FB. That seems backwards to me, though I don't know anything about RT:11 besides what I've read on this page.

207.172.129.146 04:53, 27 December 2006 (UTC)Jimmy

To be more precise, the only job from which commands can be issued is the background job. This is not to say that the only job which can be interactive is the background one. Any job can do terminal I/O, but only at the request of a program running attached to it (ttyin, ttyou, print, etc). They are not attached to the keyboard monitor (KMON). The only job which can issue commands is the background job, which is attached to the KMON.

Additionally, the 6 system jobs (when that feature is enabled via sysgen) are just like the foreground job in that they can do terminal I/O under program control, but are not connected to the KMON.

--Meganbg 21:45, 16 January 2007 (UTC)

Just made another change on the base page -- about the jobs having fixed priorities. The background was the lowest priority, then came the system jobs with priorities which matched their job number (1-6), and then the foreground with the highest. In actuality, completion routines for a given job had higher priority than the mainline for that job, but lower priority than the mainline for the next higher job.

--Meganbg 19:13, 18 January 2007 (UTC)

Re some recent edits

As a former member of the RT-11 development team and one who ran RT-11 on everything we supported (and the person who generally tested RT on several new -11s while they were still in the prototype stage), I have to say that I don't ever remember seeing a "PDP-11/08" which is mentioned on the main page. There were PDP-11s and PDP-8s, but until the 11/{83,84,93,94}, there were no -11s which even had an '8' or '9' in their name.

If someone can provide proof of one, I will stand corrected... until then, I'd like to remove that reference.

Any comments?

—The preceding unsigned comment was added by Meganbg (talk • contribs) 22:15, 16 January 2007 (UTC).

• Well, if anyone should know! Go for it. --jpgordon^∇∆∇∆ 23:35, 16 January 2007 (UTC)

Done... I also removed reference to the Rainbow... RT-11 definitely did not run on it.

--Meganbg 19:14, 18 January 2007 (UTC)

• I'd sure think not, since the Rainbow was a combination 8088/Z80 machine. Pity it took so long to come out; I liked it. --jpgordon^∇∆∇∆ 19:16, 18 January 2007 (UTC)

Monitor variants

In earlier versions of RT-11, the single-job version of the monitor was called SJ. In later versions (I think around 5.5 or so), we renamed it to SB.

It was more than a cosmetic change. Prior to that point, the SJ monitor was built from a different RMON (resident monitor) source and actually did things differently than the RMON of the FB monitor. For example, when a program was exiting, the monitor knew there was only one job and that a RESET was safe to do. Following the RESET, the interrupts were turned back on and control passed to the KMON.

With the advent of the single source for the resident monitor, we created the SB variant to indicate that it was a single-job variant of FB and acted the same way as the background job of the FB variant. This provided predictability in program operation for customers.

We also used to have (around the V4 timeframe) a variant called the AI monitor for use in automatic installs.

So, the total list of RT monitor variants (V4 and later) is: AI, FB, SB, SJ, XB, XM, ZB, ZM
(prior to V4, the typical names for monitors was of the form xxRMyy where xx was the two-character device name, and yy was the monitor variant. So RKMNSJ was the SJ monitor for the RK05)

I also remember an attempt at a memory-resident version of RT, called MRRT, and a stripped-down distribution called $RT^{2}$ (RT-Squared)

—The preceding unsigned comment was added by Meganbg (talk • contribs) 22:46, 16 January 2007 (UTC).

TSX clarification

TSX+ was not really an extension to RT-11 with which one could develop a time-sharing system. TSX+, when running, was in full control of the machine as a replacement for RT-11. The only thing TSX+ needed from RT-11 was the boot function to get to a point where it, as a program, could be loaded and run. Once it had control, it basically kicked RT-11 out of memory and took over complete control, offering an environment which was similar to RT-11. All the utilties provided with RT-11 simply ran, as did user-developed programs.

--Meganbg 19:27, 18 January 2007 (UTC)

Mentec

User Dojarca (talk · contribs) recently added

RT-11 is now supported and distributed by Mentec company.

So I eagerly went to www.mentec.com ... and couldn't find anything. A little Googling shows that they used to sell processor boards and software (including not just RT-11 but also RSTS/E and several RSXs, plus DECNET, several compilers, DATATRIEVE, etc). However, they seem to have stopped in 2000, after doing a lot of Y2K fixes (eg., RT-11 v5.7) and today Google finds no occurrence of "PDP" in www.mentec.com. Sigh. So I've removed that sentence from our article. Disappointedly yours, CWC 09:20, 28 March 2007 (UTC)

Probably they sold the business to somebdy?--Dojarca 09:20, 31 March 2007 (UTC)

I think to XX2249 LLC. Paul Koning (talk) 17:37, 12 August 2016 (UTC)

Is there any operating system template?

--Dojarca 09:19, 31 March 2007 (UTC)

Squeezing versus defragmenting

The difference between squeezing as RT-11 does it, and defragmentation as Windows does it is that with RT-11, the files are always contiguous. They are moved 'down' (towards lower block numbers) as the empty space is moved 'up' (towards higher block numbers) and consolidated. With Windows, the defragmentation consolidates the scattered files back into contiguous ones (for the most part) while consolidating the free space.

--Meganbg 17:54, 9 April 2007 (UTC)

Does the Elektronica BK info belong?

Although it is interesting to see what runs on the E-BK, that information rightly belongs in that wikipedia entry, not in the entry for RT-11.

Instead of a list of OSes which run on the E-BK, a list of machines on which RT-11 runs might be more appropriate.

Meganbg 15:36, 24 May 2007 (UTC)

I've expanded the section on hardware, so the above-mentined info could be removed Meganbg 15:58, 24 May 2007 (UTC)

This is not a list but a navigational template placed in all oses which run on Elektronika BK.--Dojarca 17:15, 31 July 2007 (UTC)

But as such, the list belongs in the Elektronika section, with links to all the OSes which run on it. Not the full list for each OS. This is, after all, the *RT-11* wikipedia page, not the Elektronika page. Also, the image you added should more appropriately be displayed down in the section with USSR clones. It does not demonstrate what RT-11 looks like. What do other people think? Meganbg 19:31, 6 August 2007 (UTC)

I like Meganbg's reorganisation. If that image goes into the article, the USSR clones section is the right place for it.

I'm not sure this article needs that "Operating systems for Elektronika BK" infobox, but the infobox is small enough that I don't really mind it.

Thanks again, Meganbg, for all your work on RT-11 (ambiguity intentional). Cheers, CWC 00:18, 7 August 2007 (UTC)

In the main article, it mentions "Several clones of RT-11 were made in the USSR" and lists them. The question I have is whether they were clones of RT-11 or the PDP-11? I suspect the latter, and that the text should be corrected. Meganbg 19:52, 15 October 2007 (UTC)

Minimal config inconsistencies

The "minimal system configurations" discussion rambles a bit and is quite inconsistent. It starts out by talking about a floppy based system with gigantic memory :-) and then goes on to configurations with small memory but large disks (5 MB).

The smallest memory supported, to the best of my knowledge, was 8 kW (16 kB). The smallest supported system device was the DECtape (289 kB); the smallest real disk would be the RF11 (512 kB). Then again, RT-11 also worked on an RC-11 disk (128 kB); that was not supported by DEC because DEC no longer had any of those by the time RT-11 was developed. But Lawrence University did, and I wrote the support for it (in RT-11SJ V2A).

So I think the correct statement for minimal config, for older versions, would be 16 kB of memory and 128 kB of disk, minimum supported by DEC would be 16 kB of memory and 289 kB of disk-like storage.

Paul Koning 14:54, 8 August 2007 (UTC)

Hey Paul! Long time no see...

Somewhere in deep storage I have some V1 manuals... when I can find them I should see if there is any comment about minimum memory and disk requirements. Obviously the minimum requirements changed over the years. I think the minimum by the time V56 came out was 16kw/32kb for memory, and RX02s for disk (based on the smallest distribution medium).

Meganbg 16:24, 8 August 2007 (UTC)

MSDOS and family follows RT-11 and similar OSes, not vice versa

I'm concerned that some of the recent changes are done from the seeming standpoint that MSDOS and Windows are the gold standard, and other OSes modelled things after them.

THEY DIDN'T!!!

In fact, in a quick search, I find that the first MS/DOS was first released in 1981. RT-11 was first developed in 1969/1970.

Files with extensions of .SAV were seen in TOPS-10, which was first released in 1964. They were also seen in OS/8, which was 1973... so these clearly predate MS/DOS.

Other "facts" are also incorrect.

On RT-11, batch files use the file extension ".BAT". Files with the extension ".COM" were known as command files and are simply a set of commands to be executed in the same order, regardless of outcome of any of them.

Finally, the source model for RT-11 should not be considered "open source". The software was owned by DEC and the only official distributions came from DEC (and later Mentec). The binary distribution kit only provided the uncommented sources for the monitor and the device drivers so that users could do a system configuration and generation. The sources for utilities and libraries were no provided. One would have to purchase a source kit to get those. And even then, some sources were still not provided (such as the sources for MACRO, which was actually maintained in-house at DEC by a different group). It should probably be considered "Proprietary".

Meganbg 22:09, 11 October 2007 (UTC)

Of course, MS-DOS followed RT-11 not vise-versa. But the systems much more similar than for example MS-DOS and UNIX. Besides Macro there were also various assembler systems from third parties.--Dojarca 13:37, 12 October 2007 (UTC)

I recently added some text about basic commands in RT-11 which are implemented in KMON. An edit which followed mine added a number of commands in such a way that it appears that they, too, are implemented in KMON. This is not correct. For a number of them, KMON calls out to various utilities (PIP, DUP, DIR, FORMAT) which actually perform the operation. This section needs to be restored or rewritten. Meganbg 20:00, 15 October 2007 (UTC)

I also added text describing the CSI, to which later edits added text referring to unix shells. This really needs to be removed as the CSI is not a shell at all. KMON is the equivalent of the shell, CSI only knows about input filenames, output filenames and single-character switches. Meganbg 20:18, 15 October 2007 (UTC)

By the way, FORMAT was used to lay down the low-level disk formatting on some disks. Not all disks supported this. The INIT command was used to actually impose the RT-11 filesystem on a formatted disk. Meganbg 20:09, 15 October 2007 (UTC)

Finally, recent text referred to 'BY0:, MZ1:, VD5: (for network drive)'. RT-11, as distributed, did not have the concept of network drives. The network device drivers were NC (for PRO-series), NQ (for qbus) and NU (for Unibus).

I'd like to strongly suggest that any edits to the RT-11 article be consistent with RT-11 as distributed by DEC/Mentec. Other information is, of course, welcome, but should be clearly marked as being applicable to a clone, a third-party product, or whatever. Meganbg 20:28, 15 October 2007 (UTC)

VD was used in SOSNET network environment. By the way, this reference [1] says nothing about BAT file extention, neither I can remember any such file. Can you please provide source?--Dojarca 00:10, 16 October 2007 (UTC)

RT-11 Mini-reference for V5.2 (nearest thing I can put my hands on), AA-M241B-TC, page 292. The reference you point to only has 21 file types listed. The mini-reference has 42 file types listed. Meganbg 13:24, 17 October 2007 (UTC)

Just to let you know, I started reading the document that you referenced... It has very clear errors and should not be considered a reliable source of accurate information about RT-11 and certainly not the definitive source for information placed in the RT-11 article. For example, in the section on "RT-11 Monitor (KMON)":

              DXMNSJ.SYS         -Contains the bootstrap
                SWAP.SYS         -Contains the RT-11 Monitor
              STARTS.COM         -Commands used on startup.

The DXMNSJ.SYS file is the monitor (RX01, SJ monitor). It contains the RMON, KMON, USR, CSI, and device tables. The bootstrap is written using information in this file, but does not execute from this file. SWAP.SYS is not the monitor, it is the file into which parts of user programs are written. The most glaring error is the section on RMON. What it appears to be describing is the hardware bootstrap-board-supplied ODT. Meganbg 12:37, 18 October 2007 (UTC)

Fair use rationale for Image:Osbk11.png

Image:Osbk11.png is being used on this article. I notice the image page specifies that the image is being used under fair use but there is no explanation or rationale as to why its use in this Wikipedia article constitutes fair use. In addition to the boilerplate fair use template, you must also write out on the image description page a specific explanation or rationale for why using this image in each article is consistent with fair use.

Please go to the image description page and edit it to include a fair use rationale. Using one of the templates at Wikipedia:Fair use rationale guideline is an easy way to insure that your image is in compliance with Wikipedia policy, but remember that you must complete the template. Do not simply insert a blank template on an image page.

If there is other fair use media, consider checking that you have specified the fair use rationale on the other images used on this page. Note that any fair use images uploaded after 4 May, 2006, and lacking such an explanation will be deleted one week after they have been uploaded, as described on criteria for speedy deletion. If you have any questions please ask them at the Media copyright questions page. Thank you.

BetacommandBot 10:32, 7 November 2007 (UTC)

I posted a question on the discussion page of that image: is the assertion that the image is copyrighted actually valid? Who would own the copyright? DEC, perhaps, but that seems odd since they didn't create that software. The creators of the bootleg copy? But that seems odd because they had no legal right to create it. Can a thief hold copyright in what he steals? Paul Koning 16:58, 7 November 2007 (UTC)

Replied there.--Dojarca 08:18, 10 November 2007 (UTC)

Image copyright problem with Image:DEC,VT52.jpg

The image Image:DEC,VT52.jpg is used in this article under a claim of fair use, but it does not have an adequate explanation for why it meets the requirements for such images when used here. In particular, for each page the image is used on, it must have an explanation linking to that page which explains why it needs to be used on that page. Please check

• That there is a non-free use rationale on the image's description page for the use in this article.
• That this article is linked to from the image description page.

This is an automated notice by FairuseBot. For assistance on the image use policy, see Wikipedia:Media copyright questions. --08:21, 20 May 2008 (UTC)

File:Osbk11.png Nominated for speedy Deletion

An image used in this article, File:Osbk11.png, has been nominated for speedy deletion for the following reason: Wikipedia files with no non-free use rationale as of 17 November 2011 What should I do? Don't panic; you should have time to contest the deletion (although please review deletion guidelines before doing so). The best way to contest this form of deletion is by posting on the image talk page. If the image is non-free then you may need to provide a fair use rationale If the image isn't freely licensed and there is no fair use rationale, then it cannot be uploaded or used. If the image has already been deleted you may want to try Deletion Review This notification is provided by a Bot --CommonsNotificationBot (talk) 11:46, 17 November 2011 (UTC)

Fragmentation

Regarding my restoration of the defragmentation link, the RT-11 file system didn't fragment individual files (each file was a contiguous series of disk blocks). But, you could end up with little bits of unused space between files, which needed to be periodically coalesced. I would certainly call this file system fragmentation. -- RoySmith (talk) 16:01, 8 June 2014 (UTC)

I'm afraid I have to strongly disagree. If every file has to fit in contiguous free space, and there's no provision for splitting up a file to fit in the available free clusters - then it's simply not possible for the *filesystem* to become fragmented, the capability doesn't exist! I suppose one might think of the free space as being fragmented. But it's absolutely incorrect to refer to the process of coalescing the free space as 'defragmentation' as the files were never fragmented in the first place. DEC named the free space optimisation function "SQUEEZE." Acorn called it "COMPACT." Nobody called it "defrag..." Shalroth (talk) 17:05, 8 June 2014 (UTC)

Whatever the name of the command may have been, "defragmentation" is a reasonable description of the operation. See, for example, https://groups.google.com/d/msg/alt.sys.pdp11/u-eJhMdyM60/sfqAnKkp2uYJ : you may also need to squeeze the disk to move all the files next to each other (this is defragmentation..) -- RoySmith (talk) 22:54, 8 June 2014 (UTC)

May I toss third-party two-cents into the debate? To me, “defragmentation” is an MS-DOS-era buzzword that was never sufficiently well-defined to judge whether or not it would apply to a file system like that used by RT-11 — which may explain some of the recent disagreement. The defragmentation and file system fragmentation articles don't help, as they're written from an (unfortunately) limited technical perspective; I definitely would not recommend linking either of those to the current article, whatever one's opinion of the term “defragmentation”. And as for the Google link, I really don't find it all that convincing that the word was once used by someone on an Internet forum. Here's a neutral suggestion: Drop the defrag term now, and the first person who can find the term “defragmentation” used in a reliable source contemporary with RT-11, referring explicitly to RT-11, can add that word, with its citation, to the article.  Unician ∇  11:08, 9 June 2014 (UTC)

I have added a link to File_system_fragmentation#Free_space_fragmentation. It seems like it describes precisely the concept we're talking about here. I don't understand the reluctance to use this perfectly reasonable, descriptive, and widely used term (and, yes, I did use RT-11 extensively). -- RoySmith (talk)

• Lecture notes talking about fragmentation on RT-11 file system:

1. [2]
2. [3]

I'll yield to your superior experiences in this matter. It would seem like the lecture notes infer that fragmention of files (as we understand it today) was unsupported - "No external fragmentation at the cost of fast file access" - but I'm happy with the reference to free space fragmentation, which seems to be what we're describing here. Sorry if I caused friction or ill-will, I get hung up on precise terminology sometimes and I forget that some terms have to remain fluid. Shalroth (talk) 21:01, 6 March 2015 (UTC)

Some comments about early versions

My experience with RT11 is mostly with V2, which gives me a somewhat different perspective. For example:

1. V2 didn't have the DCL user interface. So, for example, no "rename" command. Instead, you'd say "r pip" then in response to the pip prompt: "new=old/re".
2. V2 didn't have SYSGEN. I don't remember if the (stripped) sources were included so you could rebuild the OS or if that didn't happen until later. In any case, it's not clear why you would, since I don't think there were any build options apart from a choice of disk type for your system disk.
3. The article claims that in early versions the device drivers were built into the kernel. I don't think so, with the exception of the system disk. All the other device drivers, as far as I remember, were loaded from dev.SYS files as needed. But yes, a specific kernel build was for a specific kernel device, which is why you'd see file names like "RKMNSJ.SYS" on old RT kits. (That translates to: monitor (kernel) for RK05 system disk, Single Job kernel). Update: I just found an RT V1 manual, and it's clear the article is incorrect.

Paul Koning (talk) 17:54, 12 August 2016 (UTC)

SYSGEN was useful for many applications; for one thing it was how support for several options was enabled. For example, in at least some of the RT-11 distribution kits, a SYSGEN was required to allow RT-11 (and TECO/EDIT) to use the VT11 or VS60 graphics options. Of all the available ways to edit text files on RT-11, by far the nicest was TECO+VS60. — DAGwyn (talk) 10:22, 8 September 2017 (UTC)