> From: Wolfgang Helbig
> The HALT instruction of the real PDP11 only stops the CPU
I have this bit set that on at least some models of the real machine, when
the CPU is halted, it does not do DMA grants? If so, on such machines, the
trick of depositing in the device registers directly would not work; the
device could not do the bus cycles to do the transfer to memory. Anyone know
for sure which models do service DMA requests while halted?
Noel
Something of a tangent:
In my early days with UNIX, one of the systems I helped look
after was an 11/45. Normally we booted it from an SMD disk
with a third-party RP-compatible contorller, for which we
had a boot ROM. Occasionally, however, we wanted to boot it
from RK05, usually to run diagnostics, occasionally for some
emergency reason (like the root file system being utterly
scrambled, or the time we ran that system, with UNIX, on a
single RK05 pack, for several days so our secretaries could
keep doing their troff work while the people who had broken
our air-conditioning system got it fixed--all other systems
in our small machine room had to stay shut down).
There was no boot ROM for the RK05, but it didn't matter:
one just did the following from the front-panel switches:
1. Halt/Enable to Halt
2. System reset (also sends a reset to the UNIBUS)
3. Load address 777404
4. Deposit 5.
(watch lights blink for a second or so)
5. Load address 0
6. Halt/Enable to Enable
7. Continue
777404 is the RK11's command register. 5 is a read command.
Resetting the system reset the RK11, which cleared all the
registers; in particular the word count, bus address, and
disk address registers. So when the 5 was deposited (including
the bit 01, the GO bit), the RK11 would read from address 0 on
the disk to address 0 in physical memory, then increment the
word-count register, and keep doing so until the word count
was zero after the increment. Or, in higher-level terms, read
the first 65536 words of the disk into the first 65536 words
of memory.
Then starting at address 0 would start executing whatever code
was at the beginning of memory (read from the beginning of the
disk).
Only the first 256 words (512 bytes) of the disk was really
needed, of course, but it was harmless, faster, and easier to
remember if one just left the word-count at its initial zero,
so that is what we did.
The boot ROM for the SMD disk had a certain charm as well.
It was a quad-high UNIBUS card with a 16x16 array of diodes,
representing 16 words of memory. I forget whether one inserted
or removed a diode to make a bit one rather than zero.
It's too bad people don't get to do this sort of low-level stuff
these days; it gives one rather a good feel for what a bootstrap
does when one issues the command(s) oneself, or physically
programs the boot ROM.
Norman Wilson
Toronto ON
Hi all, thanks for the wiki suggestions so far.
Does anybody have any lists of good Unix websites that I can add in to
the wiki at http://wiki.tuhs.org/doku.php?id=publications:websites
Also, any suggestions on how to organise the page, as I can see we will
end up with hundreds of links!
Cheers, Warren
Someone off-list today asked about an annotated list of Unix papers which
might be good to add to the new wiki.
I've just uploaded my own short list of Unix papers, in BibTeX format, on
the wiki at:
http://wiki.tuhs.org/lib/exe/fetch.php?media=publications:wkt_reflist.bib
If you have your own list of references in whatever format, could you
upload them into the wiki also?
Once you have registered and have write permissions, go to:
Media manager -> publications -> Upload. Select your file and upload.
The dokuwiki can deal with references in BibTeX format, I just don't know how
to do it yet. Once I do, I'll decorate links to papers with a reference.
Cheers & thanks, Warren
P.S I just uploaded some of the BSTJ papers into
http://www.tuhs.org/Archive/Documentation/Papers/BSTJ/
I decided that, given that we have a few years until the 50th anniversary,
that I would set up a wiki for Unix in a similar vein to the Multicians one.
So I've made a start at http://wiki.tuhs.org (if/when the A record propagates).
I'd love to get some other people to help out, but I'll keep adding stuff
and we will see how it goes. Any good anecdotes about Unix are most welcome!
If you want to get edit status, register and then e-mail me so I can
manually mark you as having edit status.
Cheers, Warren
> > Louis wrote a disk loaded program called RUNCOM that read command
> > lines from a file,
> Hence, presumably, the .foorc files of Unix and the rc shell.
Yes, rc files were named for runcom, but did not adhere to runcom's
curious limit of 6 commands.
Doug
I got this a couple of days ago and thought I had sent it on, but
apparently not. Here goes.
Greg
On Saturday, 26 December 2015 at 11:12:59 -0500, Tom Van Vleck wrote:
> Short answer to your question is "depends on what you mean by shell."
> Answer for Unix heads is http://multicians.org/shell.html where Louis Pouzin says he made up the name
> for Multics. We never called the CTSS command processor a shell.
>
> When I used CTSS in 1963, command processing was in (wired) code in A-core.
> A simple program tokenized input lines, looked up the token in A-core tables, and either ran an
> A-core routine or loaded a command file, passing the rest of the arguments as a string array.
> To add a command, you had to recompile CTSS. Look at the module COMC in the source.
>
> This command language is documented in the "candy stripe" CTSS manual.
> http://bitsavers.org/pdf/mit/ctss/CTSS_ProgrammersGuide.pdf
>
> About 1964 or 65, COMC was changed to not list the disk loaded commands; if the table
> lookup failed, COMC looked for a disk file in a system directory, and ran it if it was found.
> System maintainers could add a command by copying a file into the directory.
> Command files were in core image format, already loaded and linked. Conventional practice
> was to make them small and to expand the core image for things like I/O buffers at execution start.
>
> Some disk-loaded commands were listed in COMC and flagged as "privileged" so that they could
> call special supervisor entries to get the supervisor to do things forbidden to regular programs.
> the LOGIN command was an example: it could read the password file, forbidden to regular users,
> and could patch the A-core table of logged in users.
>
> Louis wrote a disk loaded program called RUNCOM that read command lines from a file, substituted
> arguments into the command, and requested the supervisor to run them, and then return control
> to RUNCOM. This is a shell-like function.
>
> Noel Morris and I wrote an author-maintained unprivileged B-core CTSS program in 1965 called
> . SAVED that was also shell-like. It read lines from the terminal, tokenized them, expanded
> abbreviations and iterations, and ran sequences of commands, and then resumed itself. It had other
> features such as inter-user text messages. It allowed power CTSS users to extend the
> system-provided command set with their own set of SAVED files, all treated uniformly.
>
> Noel and I also added a facility to CTSS that allowed the system to run batch jobs. The user
> submitted a RUNCOM file to a queue for later processing, much like Unix CRON.
>
> Revised command processing, RUNCOM, and . SAVED are documented in the second edition CTSS manual.
> http://bitsavers.org/pdf/mit/ctss/CTSS_ProgrammersGuide_Dec69.pdf
>
> Multics had a program known as the shell, which went through a long series of evolutions.
> Users could replace their command shell. A program called the listener read command lines
> and fed them to the shell, which tokenized the command lines and found and called individual commands.
> The argument-substituting run-from-a-file mode of operation of RUNCOM was done by the exec_com command.
> All of these Multics features and design were familiar to Ken and Dennis when they worked on Multics.
>
> You say you have been looking at the CTSS source. You know you can run a simulated
> 7094 running a simulated CTSS, right? http://www.cozx.com/~dpitts/ibm7090.html
>
> regards, tom
--
Sent from my desktop computer.
Finger grog(a)FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
Jon von Neumann was born in 1903; without him, we probably wouldn't have
had computers at all (but we could've had a Wintel version, I suppose,
wherein everything is controlled by BB).
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
All,
I just finished some compact analyses on the boot loaders that are
presented in "Setting up Unix - Sixth Edition" by Thompson and Ritchie.
They are in followup to the more detailed analysis of the Tape Bootstrap
Loader that I mentioned previously and the entry is posted here:
http://decuser.blogspot.com/2015/12/pdp-11-bootstrap-loaders-some-analysis.…
What was most interesting about the analyses and programs was how
related they were. At the end of the day, once I understood how the
first one worked, the other two were pretty simple and required only
minor tweaks in the coding to achieve their results.
I am moving on now that I have a pretty good idea of how these bits of
code work and will be starting to program in Macro-11 for a few weeks to
get a handle on things before I return to the deep dive into the source
code of v6 that I temporarily put on hold so I could actually make sense
of the Assembly bits.
I really appreciate everyone's help, tips, suggestions and even critiques.
Thanks,
Will
