[TUHS] Lions laboratory and a short excursion into DOS-11

[Aron Insinga via TUHS]

Very cool, thanks for posting this.

I kind of liked using DOS/BATCH-11 on a PDP-11/20 when I was young and 
foolish.
I did some class exercises on it along with learning about PDP-11 assembler.

Calling the operating system the Monitor is, I think, from the 
PDP-6/PDP-10 Monitor (later renamed TOPS-10) and I would not be 
surprised if there was a developer or two in common; that's before my time.

Lower down the scale from DOS-11 was the Paper Tape programming system 
(manual DEC-ll-XPTSA-A-D) with PAL-11A (absolute instead of relocatable 
like PAL-11R).  But DOS-11 also supported DECtape (block-structured 
magnetic tape similar to the LINCtape and TX-2 tape) (and so did PDP-11 
Unix!).  They might have been for bare metal application users; again. 
not something I touched that I can recall.  There was also KLDCP, the 
diagnostic operating system for the KL10 that ran on the PDP-11/40 front 
end; it was replaced for normal users by RSX-20F.

(DEC used Keyboard Monitor for things that watched the keyboard, and 
Disk Monitor if they also supported a disk, going back to the PDP-8 if 
not earlier.)

Other PDP-11 operating systems were the many different 
sizes/applications of RSX-11, descended from RSX-15 for the PDP-15 
(http://b67c.com/DECPDP11RSX11.html) (PDP-7+=2 from the Unix point of 
view), and earlier ones for the 18-bit machines, listed in Supnik's 18b 
paper.

Anyway, we used DOS-11 to build (edit CONFIG.MAC, assemble, link) 
RSTS-11 (BASIC-Plus timesharing) although maybe it wasn't too long 
before the build migrated to RT-11 and later to RSTS/E (PDP-11/50) it 
was self-hosted, IIRC with RSTS/E's RT-11 run-time-system.  (So the 
Run-Time System would take RT-11 operating system calls and then ask 
RSTS to do the operation.)  (Another student and I got all the way 
through using the summary pages of the installation manual but forgot to 
run the 'hooker' to 'hook' the bootstrap loader to the CIL/SIL [image 
library] and had to start over.  Gak.  But the second time we did it 
from memory.)

IIRC, If you want an equivalent to "text\r\n" try .ASCII /text/<15><12> 
(or .ASCIZ if you want the \0 at the end).

IIRC, For a comparison to cat >file, try using PIP to do # file<KB:

(I hope those are all accurate memories, no time to look them up in the 
manuals right now.  Somebody yell if you have corrections, of course.  
Thanks for listening!)

Best,

- Aron


On 8/8/26 11:42, Will Senn via TUHS wrote:
> All,
>
> A while back I mentioned that I was putting together an OpenSIMH 
> laboratory for working through V6 alongside Lions. I've now put the 
> repository up:
>
> https://github.com/decuser/lions-laboratory
>
> Besides the V6 distribution, installation guide, PDP-11/40 
> documentation, SIMH configurations, and known-good checkpoints, I've 
> been adding notes from the things I've actually tried while reading 
> Lions.
>
> So far these include working backward through the RK05 boot process 
> from the kernel to the filesystem-aware |rkuboot| and finally to an 
> 11-word first-stage bootstrap; stepping through |rkuboot| as it 
> relocates itself to high memory, clears core, walks the V6 filesystem, 
> loads |unix|, strips the 0407 header, and transfers control to it; and 
> then following the early PDP-11/40 kernel initialization far enough to 
> watch the MMU PAR/PDR registers being established.
>
> I've also been making small changes to make sure I understand what I'm 
> reading rather than merely following it. I added |/dev/zero| as a new 
> character-device minor, rebuilt and tested the kernel, and modified 
> the RK05 filesystem bootstrap so that it automatically loads |unix| 
> instead of prompting with |@|. There are notes and debugging 
> transcripts for these experiments in the repository.
>
> The idea is not to turn V6 into something modern, but to provide a 
> laboratory in which the machine and system Lions describes can be 
> stopped, examined, modified, broken, and put back together.
>
> On a related note, while working through the V6 assembler sources, I 
> wandered a little farther afield. Ritchie's UNIX Assembler Reference 
> Manual says:
>
> |The input syntax of the UNIX assembler is generally similar to that 
> of the DEC assembler PAL-11R... |
>
> and specifically points readers to DEC-11-ASDB-D, the PAL-11R manual, 
> while warning that the internals and output formats are quite different.
>
> I read that manual to get more comfortable with the PDP-11 addressing 
> modes and V6 assembler syntax, and eventually wondered what it was 
> actually like to use PAL-11R in its native environment. That led to 
> DOS-11.
>
> I now have DOS-11 V004A running on an emulated PDP-11/40 with a 32KB 
> configuration and RK05, starting from the original DOS002 DECtape 
> distribution (DEC-11-MW2C-UC, 11/15/71). The process is wonderfully 
> hands-on: boot SYSLOD from DECtape, use the switch register to 
> initialize the fresh disk, boot the Monitor from RK05, use PIP to 
> populate it, relink LINK-11 for the machine configuration, and then 
> rebuild PIP, EDIT-11, ODT-11R, LIBR-11, PAL-11R, etc.
>
> The resulting system is:
>
> |DOS Monitor V004A PIP-11 V005A LINK-11 V007A EDIT-11 V004A ODT-11R 
> V002A LIBR-11 V002A PAL-11R V005A MODS-11 V003A |
>
> I wrote up the procedure, including a small PAL-11R "hello, world" 
> using DOS Monitor EMT services, and compared it with the equivalent V6 
> as program using UNIX system calls. The DOS-11 excursion is admittedly 
> peripheral to UNIX history, but it gave me a much better feel for the 
> DEC environment against which the early UNIX toolchain was developed 
> -- particularly since Ritchie himself points the reader toward PAL-11R.
>
> Here is the post on getting DOS11-004A up and running and programming 
> HELLO.LDA: 
> https://decuser.github.io/posts/getting-dos-11-v004a-running-on-a-pdp-11-40/
>
> One thing this excursion changed for me was my sense of what it meant 
> to program a PDP-11 in 1971.
>
> The name "DOS Monitor" can be misleading to modern ears. It is 
> tempting to imagine something only slightly removed from a front-panel 
> monitor, with the programmer otherwise dealing directly with the 
> machine. That is not the environment I found. DOS-11 is the operating 
> system; the Monitor is its resident executive, and the normal 
> programming environment is already a hosted one. EDIT-11, PAL-11R, 
> LINK-11, LIBR-11, ODT-11R, and PIP operate within that environment, 
> and an ordinary application can obtain system services from the 
> Monitor rather than implementing the hardware operations itself.
>
> The little DOS-11 |HELLO.PAL| program made this particularly clear. 
> Although it is PDP-11 assembly language, it does not drive the 
> terminal directly. It uses EMT calls to ask the Monitor to open the 
> terminal, write the message, close it, and terminate the program.
>
> Of course, one could program the PDP-11 directly. Bootstrap loaders, 
> diagnostics, device code, and dedicated applications provide obvious 
> examples, and the front panel makes the machine unusually tangible to 
> a modern programmer. But direct hardware programming should not be 
> confused with the normal application-development model DEC was 
> providing by 1971. The DOS distribution itself contains an editor, 
> assembler, linker, librarian, debugger, file utility, filesystem, and 
> resident Monitor services. This was already a substantial software 
> environment in which to write programs.
>
> That made the comparison with V6 more interesting to me. UNIX did not 
> introduce the basic idea that a PDP-11 application could execute in an 
> operating-system environment and request services from it; that world 
> was already familiar. What changes dramatically is the environment and 
> the abstraction it presents. The corresponding V6 hello-world is 
> almost startlingly small:
>
> |mov $1,r0 sys write; message; message_end-message sys exit |
>
> The contrast is therefore not simply "primitive monitor versus 
> operating system," nor "bare metal versus UNIX." Both are hosted 
> programming environments on the same processor. Looking at them side 
> by side makes the differences in their abstractions, tools, 
> interfaces, and assumptions much easier to see.
>
> I'm continuing to work downward through V6 rather than upward toward 
> later UNIX, so corrections to either the Lions laboratory or my 
> understanding of the contemporary DEC environment are very welcome.
>
> Will
>