In the same vein as my prior note, I have made a note available on the
process of getting up and running on Unix Seventh Edition in a SimH
PDP-11 environment. The text is located at:
I welcome comments, suggestions, and even criticisms.
While I have learned a lot since my last blog entry (many thanks to
Hellwig Geisse, Nelson Beebe, Noel Chiappa, Clement Cole and several
others), I am still learning about these environments. I originally
invested time in getting v7 running so that I could more easily work
with v6, after having gone there, I believe that it was time very well
spent. I know a lot more about special devices, tape formats, and so on
than I did before as a result of taking the fork in the road.
Thanks for everyone's help.
Oh, and by the way, there appears to be quite a bit of active interest
in this topic - the blog post has been viewed several thousand times
since I posted it, two weeks ago.
I have set up v7 following  and I would like to better understand the
process of adding a disk to the environment. Here is what I know:
The system has one RP06 with two partitions rp0 and rp3 which correspond
to the two block devices rp0, rp3, and the two character devices rrp0,
and rrp3. The special files look like so:
brw-r--r-- 1 root 6, 0 Dec 31 19:05 /dev/rp0
brw-r--r-- 1 root 6, 7 Dec 31 19:04 /dev/rp3
crw-r--r-- 1 root 14, 0 Dec 31 19:01 /dev/rrp0
crw-r--r-- 1 root 14, 7 Dec 31 19:01 /dev/rrp3
This meshes with the device classes switches in c.c:
The block device switch:
struct bdevsw bdevsw =
nulldev, nulldev, hpstrategy, &hptab, /* hp = 6 */
The character device switch:
struct cdevsw cdevsw =
nulldev, nulldev, hpread, hpwrite, nodev, nulldev, 0, /* hp =
I would like to add another RP disk to the environment. After I attach
an RP04/05/06 to the system, what should I use as the major/minor device
numbers? To put it differently, it doesn't seem correct to me to use 6,1
for the block device or 14,1 for the character device on the new drive
as it's a completely different disk from rp0 and rp3 which are just
partitions on the first drive and have 6,0, 6,7, and 14,0, 14,7. If each
RP can have 8 partitions and there can be 8 drives, what is the correct
major, minor numbers to use with v7 for multiple devices?
c.c only lists one vector each for the hp device (one block vector where
hp = 6, and one char vector where hp = 15).
 Haley, C. B. & Ritchie, D. M. (1979). Setting Up Unix – Seventh
Edition (pp. 497-505) in UNIX programmer's manual, Vol. 2, Revised and
Expanded Version. Bell Laboratories: NY.
In exploring v6, I have found some uses for having a running v7 instance...
When I try to install the RP bootblock during the installation procedure
for installing Version 7 Unix following the original documentation:
I am unable to boot from the RP06 disk that I installed into the boot
block onto via:
dd if=/usr/mdec/hpuboot of=/dev/rp0 count=1
No error, it just hangs. I compared hpuboot to the bootblock at it
matches byte for byte. I also compared it to the hpuboot file in Henry
Spencer's tape image (I am using Keith Bostic's tape) and it matches
that as well.
I am asking this list because I thought y'all might know if there was a
1) the hpuboot binary on the tapes
2) v7 using RP06
3) something else helpful :) (maybe it's not supposed to be loaded to
byte 0 on the disk image, although that's how it works with v6?)
I am aware that the system can be booted from tape, but that seems hokey
(obviously it works, since that's how the installation process works in
the first place, but I think it is reasonable to expect to be able to
boot from the RP06). Interestingly, there are and RL02 and RK05 v7
images that boot from disk available, but not RP.
I will ask on the SimH list, if y'all don't think it's appropriately
I am studying Unix v6 using SimH and I am documenting the process, as I
go, as part of my own learning process. I have much to learn about Unix,
Unix v6 in particular, the PDP architecture and its relationship with
v6, and SimH's emulation of the PDP, so, I am taking notes... I thought
that I would share the notes in raw form as occasional blog posts in the
hope that the knowledge that I work to obtain, might be made available
and useful to others. I also believe that these forms of communication,
as insignificant as they may seem individually are part of helping to
preserve the knowledge of our computing history, in the aggregate. Here
is a link to the first post, a run at an installation walk-through:
I am open to feedback and criticism, but please keep in mind that I am a
relative newbie to v6 and PDP land, some of my assumptions are
probably/undoubtedly wrong, but definitely fixable :).
> From: Will Senn <will.senn(a)gmail.com>
> a deeper read will require the reader to have knowledge beyond what is
> required of most modern software developers (PDP-11 architecture,
> assembly language, and UNIX are prerequisite).
Well, for pretty much any _operating system_ (as opposed to applications),
one will need to know something about the details of the machine it is
intended to run on; depending on which part of the OS one is looking at, it
will be more or less. E.g. switching processes probably requires a fair
amount, since one needs to know about internal CPU registers, etc; whereas
working on the file system, one probably doesn't need to know very much about
> It will also require access to a lab where the ideas covered can be
> experimented with.
Actually, Lions/V6 was used in operating systems courses using simulated
machines; one at MIT, 6.828 "Operating Systems Engineering":
used it for a while before the students started complaining about being
forced to learn an obsolete machine. They thereupon wrote a V6 clone for the
x86 architecture, 'XV6' (see the top of that page), which is apparently now
used for similar courses at quite a few other universities.
> The v6 kernel ... packs in features that were either unavailable in
> larger more established systems or may have been present in some form,
> but were orders of magnitude more lines of code and attendant
> complexity. It was and remains an amazing operating system and worthy
> of contemporary study.
I don't think you will find too many people here who disagree! ;-)
> So, I was thinking that next up, I would write up notes to help the
> modern reader engage with v6 more easily in order to follow works like
Check around online to see what exists, first; there has been stuff written
since Lions! ;-)
Don't forget the Zuse machines, which were later proven to be Turing
complete. It is certainly fascinating to see handling binary floating point
numbers in a purely mechanical device (check it out if you happen to be in
Berlin). Later machines were electromechanical and electronics.
> 2015.12.04. 15:52 ezt írta ("John Cowan" <cowan(a)mercury.ccil.org>):
>> Greg 'groggy' Lehey scripsit:
>> > Take a look at CSIRAC in the Melbourne museum, the oldest computer in
>> > the world. It's worth it, even if they don't have it running.
>> Well, there's the Antikythera mechanism.
>> John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org
>> In the sciences, we are now uniquely privileged to sit side by side
>> with the giants on whose shoulders we stand. --Gerald Holton
>> TUHS mailing list
On Fri, Dec 4, 2015 at 12:02 AM, Will Senn <will.senn(a)gmail.com> wrote:
> 1. a utility on the host that is capable of copying a directory and its
> contents, recursively, onto a blank magtape/dectape/rk image that is then
> readable in the v6 environment
Right - you want a common archive format between the two systems that talk
to the tape device.
You can either create your own or better take on the old ones that exist.
> 2. a tar and unzip binary for v6 that is capable of dealing with the
> tarball (but isn't the tarball going to exceed the max file size anyway, if
> so this won't work)
I think you have a many to chose from off the top of my head I can think of
each with different advantages (more in a minute):
- ar (new format)
You seem to also want a compression tool, but you might try compressing on
the modern system - but there are solution here also.
- pack/unpack was the old v5/v6 compression tool - I've forgotten where
it was sourced check the first USENIX tape in 77
- porting a modern zip/gzip/bzip
> 3. an alternative archiver that runs on FreeBSD or Mac OS X, that can
> create a single file archive from a subdirectory's contents on the host
> (the resultant file would need to be extractable on v6, and if file size is
> too limited, won't work either).
That is a lot of work and unless this is going to be a very long term
thing, I'm not so sure it's worth it. Basically you want a virtual FS on
the v6 system and the simulator. If you are going to do this alot, then
its worth it. Think the VFS that vmware and like offer.
> 4. some kind of directory transfer utility that works over telnet that can
> be executed from a FreeBSD or Mac OS X host and that can be executed on the
> v6 system as well.
the original unix kermit will compile using the v6 compiler (maybe the
v5) compiler. You have to dig in the archives, but you want a version
from Columbia circa 1977 and you be fine. The latest version will use
things in the language first described in the white book - aka Typersetter
C (Dennis was wrote the book starting with v6, but's not published until
v7). If you a later compiler running on v6 you'll be fine.
> 5. a utility capable of creating an empty magtape/dectape/rk image and
> another capable of making a filesystem on the image and another of
> populating the image (analogous to fdisk rkimage; mkfs rkimage; rkcopy dir
You could move the file system creation tools and set of a virtual v6 FS.
It's a lot of work and unless this is going to be a very long term thing,
I'm not so sure it's worth it.
As for the archivers which in the short term is likely to be your best bet:
1. tar - there a couple of versions of tar for v6 including binaries.
I personally would start there.
2. cpio was written for PWB 1.0 which is v6 kernel based. That binary
should run. But IIRC correctly the original cpio was only binary headers
(the -c/ascii headers was added later). So you'll need to be careful on
the modern computer and make sure you set the switches so that he created
the proper endian/byte swapping -- ness in the header
3. tp/stp - on the original USENIX tape is a "super tp" that replaced
the original one. The binary should run as is. The code for it is
pre-K&R so compiling it with a modern compiler will be a little bit of
work. Also, IIRC the "directory" which is on the front of the tape is
binary, so you'll need to make sure you write everything in PDP-11 format.
4. ar - was updated by the community. Eventually, V7 took the "new ar"
from original USENIX tape. Again that binary should just run fine.
Although I don't think its directory is recursive so it may fail that
requirement for you
I am trying to figure out how to get parts of 1BSD added into a pristine
v6 install, but the question I have relates to moving more than a
handful of files from a host system into v6, which lacks several
capabilities that are taken for granted from v7 onward (tar, unzip, and
For background, in looking at the 1bsd tarball, exploded out, I saw that
ex was available on the tape in a binary form that is suitable for a
PDP-11/40 and I thought it would make life easier in v6 to have ex. So,
I used dd to move the a.outNOID file onto a file, which can be used as
a raw RK image and then off the RK image loaded in the PDP-11 into the
v6 system as the executable file ex, and that worked. I was able to run
ex (well, sort of, I get the colon prompt anyway... I haven't figured
out how it actually works yet). Yeeha! Having had success of a sort with
a single executable from the 1BSD tape, I would like to see if other
parts of 1BSD will work in the environment and if I can properly install
Individually moving files using dd is tedious in the extreme (there are
many files in the tarball). I know there has to be a better way. Since
v6 doesn't have tar, or unzip, it doesn't seem likely that using dd to
move the tarball into v6 will be help matters. But, if there was a way
to dd a subdirectory and its contents onto an RK image and get them off
again into a useable v6 file system, that would work.
My question for the group is based on the preceding discussion and the
1. given a tarball such as 1bsd.tar.gz from the TUHS archive located at:
2. with a running SimH PDP-11/40 instance
with a virtual TU10 magtape
with a virtual TU56 dectape
with a virtual RK05 hard drive
3. running v6 as the operating system
What is an efficient method of moving the files of the 1bsd
distribution, or any other set of files and directories, into the v6
Here are some approaches that seem reasonable, but that I haven't been
able to figure out, if you know better, please do tell:
1. a utility on the host that is capable of copying a directory and its
contents, recursively, onto a blank magtape/dectape/rk image that is
then readable in the v6 environment
2. a tar and unzip binary for v6 that is capable of dealing with the
tarball (but isn't the tarball going to exceed the max file size anyway,
if so this won't work)
3. an alternative archiver that runs on FreeBSD or Mac OS X, that can
create a single file archive from a subdirectory's contents on the host
(the resultant file would need to be extractable on v6, and if file size
is too limited, won't work either).
4. some kind of directory transfer utility that works over telnet that
can be executed from a FreeBSD or Mac OS X host and that can be executed
on the v6 system as well.
5. a utility capable of creating an empty magtape/dectape/rk image and
another capable of making a filesystem on the image and another of
populating the image (analogous to fdisk rkimage; mkfs rkimage; rkcopy
If I am asking the wrong questions, or thinking badly, I would
appreciate a steer in the right direction.
> From: Will Senn <will.senn(a)gmail.com>
> I am studying Unix v6 using SimH and I am documenting the process
I did a very similar exercise using the Ersatz11 simulator; I have a lot
of stuff about the process here:
It contains a number of items that you might find useful, e.g.: "V6 as
distributed is strictly a 20th Century operating system. Literally. You can't
set the date to anytime in the 21st century, for two reasons. First, the
'date' command only take a 2-digit year number. Second, even if you fix that,
the ctime() library routine has a bug in it that makes it stop working in the
closing months of 1999."
> the PDP architecture
Technically, a PDP-11 - there were a number of different PDP architectures:
is a decent listing of them; several (PDP-8, PDP-10, etc) were very popular
A few things I noted in your first post:
> I am using the Ken Wellsch tape because it boots and is stated to be
> identical to Dennis Ritchie's tape other than being bootable and having
> a different timestamp on root.
The only differences I could discover between the two are that in the Wellsch
versions i) a Western Electric rights notice (which prints on booting) has
been added to ken/main.c, and the Unix bootable images; and ii) the RK pack
images do have, as you noted, the bootstrap in block 0.
> Note: sh is critically important, don't muck it up :). The issue is
> that if you do, there really isn't an easy way to recover.
One should _never_ install a new shell version as '/bin/sh' until it has been
run and tested for a while (for the exact reason you mention). Happily, in
Unix, as far as the OS is concerned, the command interpreter is just another
program, so it's trivial to name a new binary of the shell 'nsh' or
something, and run that for a while to make sure it's working OK, before
installing it as '/bin/sh'.
> a special file (whatever that is)
Special files are UNIXisms for 'devices'. _All_ devices in Unix appear as
'special files' in the file system, usually (but not necessarily) in /dev -
that location is a convention, not a requirment of the OS.
On Sun, Nov 29, 2015 at 08:55:23PM -0800, Paul McJones wrote:
> Thanks very much for making the original and the OCR-enhanced versions
> of Doug’s scan of the “UnixEditionZero” document available
> on tuhs.org. I notice that even with Nelson’s enhanced version,
> the file size is still large for a scanned text document, apparently
> because it was originally scanned in RGB mode, 24 bits/pixel. The
> attached version is 2.5MB, and to my eye is identical looks identical
> to UnixEditionZero-OCR.pdf.
Paul, I've added your version into the same directory. Thanks!