Historic Unix R7 using SIMH

[ejolson]

This post describes how to set up a Raspberry Pi running Raspbian Pixel to simulate a PDP-11/70 running Unix R7. This is the last research version of Unix released by Charles Haley and Dennis Ritchie in 1979 before the proprietary Unix wars. It was also the first version to include the Bourne shell and a portable C compiler. It is quite interesting to see how much has changed and how little.

First install the simulator and a few utilities by typing

root@pixel:~# apt-get install simh tmux telnet

Next create a system account in which to run simh and set user to that account.

root@pixel:~# adduser --uid 2000 --gid 100 simh
root@pixel:~# su - simh

After this, download and unpack the archive unix-v7-6.tar.gz of the original Unix R7 tape found on the website

https://homepages.thm.de/~hg53/pdp11-unix/

using the command

simh@pixel:~ $ wget https://homepages.thm.de/~hg53/pdp11-un ... 7-6.tar.gz
simh@pixel:~ $ tar zxf unix-v7-6.tar.gz

Now follow the HOWTO file in unix-v7-6 to assemble the tape and move it to the run directory

simh@pixel:~ $ cd unix-v7-6/mktape
simh@pixel:~/unix-v7-6/mktape $ make
simh@pixel:~/unix-v7-6/mktape $ mv mktape ../V7
simh@pixel:~/unix-v7-6/mktape $ cd ../V7
simh@pixel:~/unix-v7-6/V7 $ ./mktape
simh@pixel:~/unix-v7-6/V7 $ mv unix_v7.tm ../run
simh@pixel:~/unix-v7-6/V7 $ cd ../run

The run directory contains two configuration files. By default they are set to emulate a PDP-11/45 with an rp04 disk. We want to use a bigger disk so change setup.config as

...
set rp0 rp06
...

Continuing with the HOWTO file we load the tape and proceed to follow the instructions

http://gunkies.org/wiki/Setting_Up_Unix ... th_Edition

see also

http://minnie.tuhs.org/PUPS/Setup/v7_setup.html

simh@pixel:~/unix-v7-6/run $ pdp11 setup.conf
Overwrite last track? [N] (just press return)
sim> run 100000
<ctrl>+e (the system hangs so press ctrl+e)
sim> run 0
Boot
: tm(0,3)
file sys size: 5000
file system: hp(0,0)
: tm(0,4)
Tape? tm(0,5)
Disk? hp(0,0)
Last chance before scribbling on disk. (just press return)
: hp(0,0)hptmunix
#

At this point Unix R7 is running in single-user mode in the simulator. Now, set the console so it is not crazy, generate the /dev directory, make the user filesystem, mount it and load the last part of the tape.

# stty -lcase (note that the terminal will echo this in upper-case)
# stty erase '^h'
# stty kill '^u' (note <ctrl>+c on Raspbian is <ctrl>+? on R7)
# stty cr0 nl0
# cd /dev
# make rp06
# make tm
# for i in 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15
> do /etc/mknod tty$i c 19 $i; done
# /etc/mkfs /dev/rp3 322278
# dd if=/dev/nrmt0 of=/dev/null bs=20b files=6
# restor rf /dev/rmt0 /dev/rp3
Last chance before scribbling on /dev/rp3. (just press return)
# mount /dev/rp3 /usr
# dd if=/usr/mdec/hpuboot of=/dev/rp0 count=1

Now recompile the kernel to enable the tty devices. The first version of this document enabled the DC11 device and driver; however, this device does not have interrupt driven output and creates a 100 percent CPU load on an otherwise idle system. As SIMH doesn't support the DH11 hardware the only other option is the DZ11, which has preliminary support in Unix R7 but requires a tiny patch to be enabled. We first modify mkconf in the /usr/sys/conf directory to enable the driver. The editing must be done with ed and requires adding 7 lines. I found a script on the web at

http://wsxyz.net/v7/

which works nicely. The tab characters are significant to the assembler code in this patch so I have replaced them by <tab> so they don't get lost on the web. We'll change them back to real tabs when the file is safely transferred to the simulator. The script is

Code: Select all

249a

        "dz",
        0, 300, CHAR+INTR,
        "<tab>dzin; br5+%d.\n<tab>dzou; br5+%d.",
        ".globl _dzrint\ndzin:<tab>jsr r0,call; jmp _dzrint\n",
        ".globl _dzxint\ndzou:<tab>jsr r0,call; jmp _dzxint\n",
        "",
        "       dzopen, dzclose, dzread, dzwrite, dzioctl, nulldev, dz_tty,",
        "",
        "int dzopen(), dzclose(), dzread(), dzwrite(), dzioctl();\nstruct        tty dz_tty[];",
.
45a
        "dz",
.
w
q

Now, place the above script in your mouse and then type

# cd /usr/sys/conf
# cat >dz.tmp

in the simulator. Then paste the text and finally type <ctrl>+d to save the file. Edit the file to translate the <tab> symbols back to real tabs. Please type a tab character in the following command and not just spaces where the spaces are.

# ed dz.tmp
1,$s/<tab>/ /g
w
q
# ed mkconf.c <dz.tmp
14422
14839
#

If everything went as planned, the configuration system has been patched to recognize the dz driver and we can procede as before.

# date 8610200930 (can't set date to anything more than 1999)
# cd /usr/sys/conf
# cp hptmconf simhconf
# ed simhconf (editor a=append, .=stop appending, w=write, q=quit)
a
dz
.
w
q
# ./mkconf <simhconf
# make
as - -o l.o l.s
as -o mch.o mch0.s mch.s
cc -c c.c
ld -o unix -X -i l.o mch.o c.o ../sys/LIB1 ../dev/LIB2
# mv unix /
# ls -l /unix
-rwxrwxr-x 1 root 54866 Oct 10 10:24 /unix
(make sure the size is right, otherwise, redo)
# cd /etc
# ed ttys
18,$d
1,$s/00/14/
1,$p
14console
14tty00
14tty01
14tty02
14tty03
14tty04
14tty05
14tty06
14tty07
14tty08
14tty09
14tty10
14tty11
14tty12
14tty13
14tty14
14tty15
w
q
#

Before rebooting, rename the "dmr" user to "pi", move the root home directory to someplace more sensible and set the passwords.

# cd /etc
# ed passwd
s/dmr/pi/g
p
pi::7:3::/usr/pi:
1p
root:KycUDzoHvjyg6:0:1::/:
s/:$/root:/
p
root:KycUDzoHvjyg6:0:1::/root:
w
q
# mkdir /root
# cd /usr
# mv dmr pi
# passwd pi
New password: (please don't enter raspberry)
# passwd root
New password: (again not raspberry)

Now halt the system.

# sync
# sync
# sync
<ctrl>+e
sim> quit

At this point you should be back in Raspbian. Now change the file run.conf to enable the tty devices and upgrade the cpu to a PDP-11/70 with more RAM by editing the first lines to read

set cpu 11/70
set cpu 2048k
set cpu idle
set rp0 rp06
attach rp0 system.hp
set tto 7B
set dz enabled
set dz lines=16
attach -m dz 2000
set dz 7B
d cpu 2000 042102
...

Reboot the simulator with the command

simh@pixel:~/unix-v7-6/run $ pdp11 run.conf
boot
: hp(0,0)unix
mem = 2020544
# <ctrl>+d
RESTRICTED RIGHTS: USE, DUPLICATION, OR DISCLOSURE
IS SUBJECT TO RESTRICTIONS STATED IN YOUR CONTRACT WITH
WESTERN ELECTRIC COMPANY, INC.
MON OCT 20 09:43:54 EDT 1986

Now login and create a .profile with the commands that make the console sensible. Again note that <ctrl>+? means <ctrl>+c in R7 and there seems no way to change this other than patching the source. Also note that <ctrl>+? is often produced by the <delete> or <backspace> key on terminal emulators.

login: root
Password:
# ed .profile
a
stty erase '^h'
stty kill '^u'
stty cr0 nl0
.
w
q
# . ./.profile
# cp .profile /usr/pi
# cd /usr/pi
# chown pi .profile
# chgrp bin .profile
# sync
# sync
<ctrl>+e
sim> quit

Configuration of the Unix R7 image is essentially complete so lets make a backup copy.

simh@pixel:~/unix-v7-6/run $ cp system.hp system.bak

Now let's run the pdp11 inside tmux so we can leave it running in the background.

simh@pixel:~/unix-v7-6/run $ tmux
[3] 0:bash* "pixel" 09:03 20-Oct-16
simh@piexl:~/unix-v7-6/run $ pdp11 run.conf
boot
: hp(0,0)unix
# <ctrl>+d
RESTRICTED RIGHTS: USE, DUPLICATION, OR DISCLOSURE
IS SUBJECT TO RESTRICTIONS STATED IN YOUR CONTRACT WITH
WESTERN ELECTRIC COMPANY, INC.
MON OCT 20 10:13:33 EDT 1986

login:
<ctrl>+b d (detach the tmux session)

You are now back in Raspbian with the pdp11 emulator with the console running detached in the tmux session. There are 16 ttys accessible from the telnet port 2000 that can now be used to log into the system.

simh@pixel:~/unix-v7-6/run $ telnet localhost 2000
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

Connected to the PDP-11 simulator DCI device, line 0

login: pi
Password:
$ ls
.profile
$ <ctrl>+d
login:
<ctrl>+]
telnet> quit

Using telnet is fine when connecting locally. To make things secure it is a good idea to firewall port 2000 from remote connections. This can be done by adding a few lines to rc.local as follows.

/sbin/iptables -F
/sbin/iptables -P INPUT ACCEPT
/sbin/iptables -A INPUT -p tcp --destination-port 2000 \
! -s 127.0.0.0/8 -j DROP

You can also enter these commands manually as

root@pixel:~# /sbin/iptables -F
root@pixel:~# /sbin/iptables -P INPUT ACCEPT
root@pixel:~# /sbin/iptables -A INPUT -p tcp --destination-port 2000 \
! -s 127.0.0.0/8 -j DROP

to avoid rebooting. Now, to access the simulator remotely. Add your public key to the /home/simh/.ssh/authorized_key file with the prefix

command="telnet -E 127.0.0.1 2000" ssh-rsa ...

Note that ... represent the rest of your public key. Now on the remote host where you will log in from edit /home/username/.ssh/config to add

Code: Select all

Host simh
        User simh
        Hostname pixel
        EscapeChar ^]

where pixel is the name of the Pi running the SIMH simulator. Now you should be able to connect remotely to the SIMH simulator using

eric@remote:~ $ slogin simh
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is 'off'.

Connected to the PDP-11 simulator DZ device, line 0

login: pi
Password: (since you are connected through ssh the password will not be
transmitted in a readable way over the internet)
$ ls
.profile
$ <ctrl>+]. (disconnect using the EscapeChar followed by a period)
Connection to pixel closed.
eric@remote:~ $

If you try setting up SIMH following these directions, it would be great to post here how it went.

[ejolson]

Here is another note about SIMH on the Raspberry Pi. It appears the version that comes with Raspbian is a bit old and there is a little bug that leads to buffer overruns when pasting from a mouse into a telnet session connected to the DZ11 serial port emulator. This can be remedied by compiling a current version of the pdp11 simulator. It takes about 3 minutes. Here are the steps.

pi@pixel:~$ mkdir work
pi@pixel:~$ cd work
pi@pixel:~/work$ git clone https://github.com/simh/simh.git
pi@pixel:~/work$ cd simh
pi@pixel:~/work$ make pdp11
pi@pixel:~/work$ cp BIN/pdp11 ~/unix-v7-6/run

Now start the simulation as

pi@pixel:~/work$ cd ~/unix-v7-6/run
pi@pixel:~/unix-v7-6/run$ ./pdp11 run.conf

PDP-11 simulator V4.0-0 Beta git commit id: 2acdf26c
Disabling XQ
Listening on port 2000
Modem control activated
boot
Boot
: hp(0,0)unix
mem = 2018560
#
RESTRICTED RIGHTS: USE, DUPLICATION, OR DISCLOSURE
IS SUBJECT TO RESTRICTIONS STATED IN YOUR CONTRACT WITH
WESTERN ELECTRIC COMPANY, INC.
MON OCT 20 22:36:15 EDT 1986

There are no more buffer overruns; however, when you log in the baud rate is set to 300. After logging in through the telnet connection that was set up through ssh in the previous section type

$ stty 4800

to obtain more reasonable speeds. While it wouldn't normally be safe to put this command in the .profile, it appears safe for the simulator. This can be done with

$ ed .profile
a
stty 4800
.
w
q
$

[PeterO]

I'll have to give this a whirl It dates from just before my first introduction to Unix, which was on a VAX-11/750 running 4.2 BSD at the University of Essex in 1983.
PeterO

[ejolson]

I'll have to give this a whirl It dates from just before my first introduction to Unix, which was on a VAX-11/750 running 4.2 BSD at the University of Essex in 1983.
PeterO

I've not tried BSD on the VAX-11/750 simulator in SIMH. Setup should be slightly different, but I expect it would work just as well.

Apparently Unix R6 was used as recently as 2005 to teach operating systems at MIT, because of John Lion's rather good Commentary on the Sixth Edition UNIX Operating System. I was interested in Kernighan and Pike's, "The Unix Operating System," which relies on the Bourne shell not included in R6. I've also been quite amused by the physical computing projects which use the Raspberry Pi to recreate the PDP-11/70 front panel. Neither of these Unix versions support sockets, shared memory, multi-core CPUs or graphical user interfaces. At the same time, it is amazing how similar they are to Raspbian. I expect BSD running on a VAX-11/750 simulator would share even more similarities.

I've got Unix R7 working pretty smoothly on the PDP-11/70 simulator now. The remote login with ssh using SIMH 4.0-Beta has smooth output, no buffer overruns when I paste with the mouse and less then 10% CPU use of the Pi when idle. The delete key functioning as <ctrl>+c is a little irritating, but not a problem once you set the backspace key to send <ctrl>+h like it used to before the EMACS crowd decided <ctrl>+h should mean help.

Note that tmux has delete hard coded to the point where it even maps <ctrl>+h on the keyboard to delete if you are not careful. In details, tmux checks what character is used for erase in the current stty settings and then maps that character to delete. Obviously, if you've set your physical backspace key to <ctrl>+h then you've probably set erase in Raspbian to <ctrl>+h as well. In this case tmux will decide to translate all <ctrl>+h's to delete. There are lots of reports about this, patches to fix it but upstream won't change. Maybe they use EMACS. One work around is to use stty to set erase to delete just before starting tmux and then set it back afterwards. In my Linux system the script

Code: Select all

#!/bin/sh
i=`stty | grep erase`
case $i in
erase\ =\ *)
    erase=`echo "$i" | sed "s/erase = //;s/;$//"`
    stty erase "^?"
    /usr/bin/tmux "$@"
    r=$?
    stty erase $erase
    exit $r ;;
*)
    /usr/bin/tmux "$@" ;;
esac

fixed things for me.

After this fix, tmux can be used to transfer source files into the emulator using

$ cat >filename
<ctrl>+b:load-buffer filename
<ctrl>+b:paste-buffer
<ctrl>+d

As mentioned before, pasting with the mouse also works just fine.

I thought I would check how the speed of the Pi 3B based SIMH emulator compares with a real PDP-11/70. For this I downloaded the whetstone benchmark from an online archive of DECUS, the DEC users group. The comments in this code indicate that a real PDP-11/70 has a speed of 631.96 in single precision and 479.04 in double precision. Because the simulated SIMH system clock seems a little unreliable, I modified the benchmark to make a warm-up pass before collecting the timings. In single precision the PDP-11/70 SIMH simulator reaches a speed of 1700, which is happily more than double the original DEC hardware.

More accurate timings could be made using an external clock. It's also possible that removing "set cpu idle" from the SIMH configuration would speed things up. However, that would also cause SIMH to use 100% of a Pi 3 core all the time, which is not a realistic use case for me.

[MaxK1]

Thank you for that write up! I never got back to the emulated pdp 11 - this might spur me on. Something to do on one of these cold Minnesota days...

[ejolson]

Thank you for that write up! I never got back to the emulated pdp 11 - this might spur me on. Something to do on one of these cold Minnesota days...

You're welcome!

There is a lot of low-hanging fruit in historic Unix R7 that can be reached with minor coding efforts. While some would claim these efforts amount to reinventing the wheel, the same can be said of almost all science and engineering homework until about graduate school. The well accepted practice of teaching simple things first can be made difficult in computer science and computer engineering when all the simple things in a computer system have been automated with a resulting increase in total complexity.

For example, the Pixel version of Raspbian automates expanding the partition on the sdcard and logging into the system. While automating both of these tasks only increase the complexity of the Raspian system slightly, it is no longer possible to learn about computers by doing these tasks manually or even to learn how to automate them oneself. If all low-hanging fruit has been harvested, with what does one begin?

One answer is to start with a historic computer system that has been preserved in its original form and still retains enough low-hanging fruit to allow a new user to slowly understand the system one small step at a time. Ignoring the fact that Windows NT was originally based on VAX/VMS, almost all computers in the world today run operating systems that were based on historic Unix. Luckily Unix R7 has been preserved in it's original form and is available open source. These two features make it useful for learning about computers.

One example that can be reached with minor coding efforts is as follows: By default the original "ls" program writes the directory listing one line at a time. The goal is to write a shell script that formats the directory listing into a nice table. One solution might be

Code: Select all

case $# in
0)
    if tty -s <&1
    then
        /bin/ls | pr -4 -t -l1
    else
        /bin/ls
    fi ;;
*)
    /bin/ls "$@" ;;
esac

Naming this script $HOME/bin/ls and then adding $HOME/bin to the path allows "ls" to display directories more nicely. Alternatively, since full C source is available, one could modify the ls program to directly create the table.

Another example is as follows: The shell included in R7 is the original Bourne shell written by Bourne. When compiled it consists of 17k compared to 843k for the GNU "Bourne Again Shell" bash. This fits nicely with a model of exponential code growth at a rate of 10% per year. The original Bourne shell is missing many features from bash. One of these is tab completion and history. Consider the exercise add these features to the original Bourne shell. Here is my solution:

First create a working directory and copy the source code for the Bourne shell into it.

$ mkdir esh
$ cd esh
$ cp /usr/src/cmd/sh/* .

Download the files tabcomp.c and tabcomp.h which are the result of my programming for this exercise and copy them into the directory $HOME/esh. In case there is any doubt I have named the new shell esh for extended shell. A few modifications also need to be made in the original source to link the routines in these files. These changes consist of three changes to main.c, two to word.c and a couple to the makefile.

In details, I added includes for tabcomp.h into main.c and word.c. In word.c I further replaced

read(f->fdes,f->fbuf,f->fsiz)

by

ejoread(f->fdes,f->fbuf,f->fsiz)

and in main.c I added a global variable to remember the current prompt by replacing

prs(ps1nod.namval) and prs(ps2nod.namval)

by

prs(ejoprom=ps1nod.namval) and prs(ejoprom=ps2nod.namval)

The changes to the makefile are obvious and are not described here. I have put an uuencoded R7 compatible tar file esh.tar.uue if you would like to take a quick look. The resulting executable is now 19k, so I'm done with my 10% growth for the year. However, if you find any problems, bug reports are welcome.

Note that uudecode is part of the Debian sharutils package on Raspbian, but I needed to download source and compile from scratch to get it running on historic Unix R7. This encoding is useful for transferring binary files over the emulated 7-bit serial lines of SIMH using tmux. Since uuencode and tar on Raspbian can unpack files created using Unix R7 you can look at the files even without SIMH installed.

[ejolson]

As I don't seem to have provided the link in the previous post, for reference, the source code files uuencode.c and uudecode.c can be compiled on R7 to provide the uuencode and uudecode commands sufficient for transmitting binary files over the emulated 7-bit serial lines.

Since vi was not included in Unix R7 only the line editor ed is available by default. There is a version of vi in BSD 2.x that comes with notes on how to install it on R7. The installation process is complicated by the fact that the symbol table in the default C compiler needs to be enlarged before compiling vi. Also, the termcap library needs to be installed. As a temporary measure, I downloaded and installed the stevie editor. This source code only needed minor modifications to configure the tty and automatically detect the window size of an xterm connected to the emulated DZ11 terminal controller. My modifications are available in the uuencoded tar file stevie.tar.uue. The modern vim editor is based on the stevie code base; however, vim has become much too complicated to run on a PDP-11.

Unlike ed and vi, the stevie editor keeps the entire file in memory. In practice this means stevie is limited to editing files of about 16K. Since the PDP-11/70 hardware supports a split address space of 64K for instructions and 64K for data I had expected to be able to edit larger files. If anyone knows how too increase the size of files stevie can edit, I would be happy to hear from them.

[MaxK1]

For the life of me, I can't get the 'dz' device working. The multi-user build always results in a /unix that is about 2K shorter than it should be (i've tried your recipe and everything works except telnet access on port 2000 and a couple of similar ones I found). Patching and recompiling completes with no errors except the kernel

PDP-11 simulator V4.0-0 Beta git commit id: 55e211dd
Disabling XQ
run.conf-9> attach dz 2000
Listening on port 2000
boot
Boot
: hp(0,0)unix
mem = 2020544
# RESTRICTED RIGHTS: USE, DUPLICATION, OR DISCLOSURE
IS SUBJECT TO RESTRICTIONS STATED IN YOUR CONTRACT WITH
WESTERN ELECTRIC COMPANY, INC.
SAT FEB 15 04:04:55 EST 1986

login: root
Password:
You have mail.
# ls -al /unix
-rwxrwxrwx 1 root 52850 Feb 15 03:43 /unix
#

Any ideas?

[MaxK1]

As Roseanne Roseannadanna would say: "Never mind...". Cockpit Error...

[ejolson]

As Roseanne Roseannadanna would say: "Never mind...". Cockpit Error...

Glad you got it working. Have you seen this PiDP-11 project?

[MaxK1]

Yup - I missed out on the PDP-8/PDP-11 experience back in the 70's (Having way too much fun on big stuff - CDC computers - Having your choice of $10M+ systems all to yourself for about 6-7 hours at a time 2-3 nights a week spoils you...)

Which brings me to: Emulating "old iron" on SBC's - We have simh which emulates a raft of mini computers, Hercules for IBM 360/370 mainframes, DtCyber for CDC6000/Cy70/Cy170 series and someone has a Cray emulator, but no O/S (or very little) software for it. Oh, an ICL 1900 running George 3 (I think) Can't remember the name of it...

Any others?

[ejolson]

Yup - I missed out on the PDP-8/PDP-11 experience back in the 70's (Having way too much fun on big stuff - CDC computers - Having your choice of $10M+ systems all to yourself for about 6-7 hours at a time 2-3 nights a week spoils you...)

Which brings me to: Emulating "old iron" on SBC's - We have simh which emulates a raft of mini computers, Hercules for IBM 360/370 mainframes, DtCyber for CDC6000/Cy70/Cy170 series and someone has a Cray emulator, but no O/S (or very little) software for it. Oh, an ICL 1900 running George 3 (I think) Can't remember the name of it...

Any others?

I suppose retropi is more an example of emulating old plastic than old iron. Still, if you were involved with real computers during that time, then you probably missed out on the Amiga, the Apple and the BBC Micro as well.

I was primarily interested in the R7 and R8 releases of the research versions of Unix, as these are the systems discussed in "The Unix Programming Environment" by Kernighan and Pike. I remember using RT11 on a PDP-11 but my first experience with Unix was AIX on an IBM RT. Still hoping that the IBM Power architecture becomes an affordable alternative to x86 and ARM, but after so many years it hasn't. Maybe the ShenWei SW26010 will be available as a commodity processor sooner. I wonder if it suffers from the Meltdown and Spectre bugs affecting other hardware.

[pbnelson]

Many thanks to ejolson for writing this up. I am posting a few minor but crucial edits.

Like MaxK1, I too am trying this on a cold Minnesota day, and I couldn't get the `dz` device working; the `ls -l unix` command returned only 52580 bytes, not 54866. Also, I got an error `dz: cannot find` when running the `mkconf <simhconf` command.

The simple reason for this is because these instructions are missing a crucial step: rebuilding mkconf. I can't explain how anyone got it to work without knowing this.

In brief, the simple solution is to change the line that reads `./mkconf <simhconf` to this:

Code: Select all

cc -O mkconf.c -o mkconf; ./mkconf <simhconf

Note that that's a Capital Oh, not a zero. If working correctly, this will output the following text:

console at 60
clock at 100
clock at 104
parity at 114
tm at 224
hp at 254
dz at 300

The message `dz at 300` means your rebuilt mkconf recognized the dz terminal device. Much better than `dz: cannot find`

On more thing: the mount command is not in the path for some reason, it's in /etc/, which is just weird. Ergo the line that reads `mount /dev/rp3 /usr` should actually be:

Code: Select all

/etc/mount /dev/rp3 /usr

[W. H. Heydt]

I was primarily interested in the R7 and R8 releases of the research versions of Unix, as these are the systems discussed in "The Unix Programming Environment" by Kernighan and Pike. I remember using RT11 on a PDP-11 but my first experience with Unix was AIX on an IBM RT. Still hoping that the IBM Power architecture becomes an affordable alternative to x86 and ARM, but after so many years it hasn't. Maybe the ShenWei SW26010 will be available as a commodity processor sooner. I wonder if it suffers from the Meltdown and Spectre bugs affecting other hardware.

Since you were emulating a PDP 11/70, it would be appropriate to use what Berkeley was running on them in the early '70s...bsd 2.9.

[ejolson]

Many thanks to ejolson for writing this up. I am posting a few minor but crucial edits.

Like MaxK1, I too am trying this on a cold Minnesota day, and I couldn't get the `dz` device working; the `ls -l unix` command returned only 52580 bytes, not 54866. Also, I got an error `dz: cannot find` when running the `mkconf <simhconf` command.

The simple reason for this is because these instructions are missing a crucial step: rebuilding mkconf. I can't explain how anyone got it to work without knowing this.

In brief, the simple solution is to change the line that reads `./mkconf <simhconf` to this:

Code: Select all

cc -O mkconf.c -o mkconf; ./mkconf <simhconf

Note that that's a Capital Oh, not a zero. If working correctly, this will output the following text:

console at 60
clock at 100
clock at 104
parity at 114
tm at 224
hp at 254
dz at 300

The message `dz at 300` means your rebuilt mkconf recognized the dz terminal device. Much better than `dz: cannot find`

On more thing: the mount command is not in the path for some reason, it's in /etc/, which is just weird. Ergo the line that reads `mount /dev/rp3 /usr` should actually be:

Code: Select all

/etc/mount /dev/rp3 /usr

Thanks for the update. It seems I failed to record everything I did to get it to work. Your clarification comes at the perfect time as Oscar is now shipping the PiDP-11 front-panel which is powered by Raspberry Pi running SIMH. Thanks to the generosity of my wife I'll be building one after Christmas.

[ejolson]

Since you were emulating a PDP 11/70, it would be appropriate to use what Berkeley was running on them in the early '70s...bsd 2.9.

That's another option. Have you tried BSD 2.9 on Raspberry Pi using the PDP-11 simulator in SIMH?

[W. H. Heydt]

Since you were emulating a PDP 11/70, it would be appropriate to use what Berkeley was running on them in the early '70s...bsd 2.9.

That's another option. Have you tried BSD 2.9 on Raspberry Pi using the PDP-11 simulator in SIMH?

Sigh... No, I haven't. But then, I don't have a copy of bsd 2.9 lying around.

[pbnelson]

Looks like this guy has everything you need for installing BSD 2.9 on a PDP 11/70 under SIMH, including instructions and a source "tape".

http://gunkies.org/wiki/Installing_2.9_BSD_on_SIMH

p.s. I'm super envious of the PiDP 11/70 kit. I sure wish I was building one tomorrow, but I have to wait until another batch is ready. I didn't know they existed until last week, the further exploration of which is what brought me to this page.

[pavelanni]

Thanks for the great instructions, Eric! Almost everything worked as described with two minor corrections already mentioned by @pbnelson: 1) you must compile mkconf before running ` ./mkconf <simhconf` and 2) yes, the correct path for `mount` is `/etc/mount`. Everything else just worked!

One question: what is the recommended way of copying files inside the machine? If I want to compile the STEVIE editor, how would I do that?

[ejolson]

Thanks for the great instructions, Eric! Almost everything worked as described with two minor corrections already mentioned by @pbnelson: 1) you must compile mkconf before running ` ./mkconf <simhconf` and 2) yes, the correct path for `mount` is `/etc/mount`. Everything else just worked!

One question: what is the recommended way of copying files inside the machine? If I want to compile the STEVIE editor, how would I do that?

I tried to get Kermit to work but failed. Instead I use some tmux scripts to copy uuencoded files back and forth between the simulator and Linux. When I get home I'll make another post with details.

[ejolson]

When I get home I'll make another post with details.

I have two tmux scripts: tupload and tdownload. They both assume that you have compatible versions of uuencode and uudecode properly installed on both the emulator and on the host Linux machine.

The tupload script is

Code: Select all

#!/bin/bash
# tupload -- upload a file to Unix R7 running under SIMH

def_win=0

help(){
    cat <<END
Upload a uue encoded file from a tmux session.
Usage: $0 [options] <filename>
Options:
    -t n      Specify n as the tmux window number      ($def_win)
END
    exit 0
}
win=$def_win

while getopts t: name "$@"
do
    case $name in
t)
    win=$OPTARG ;;
*)
    help ;;
    esac
done
let shiftind=$OPTIND-1
shift $shiftind
if test "$#" != "1"
then
    help
fi
file=$1
echo Uploading $file from window $win...
tmux send-keys -t $win "uudecode" Enter
sleep 1
uuencode $file <$file | while read -r line 
do
    echo "$line"
    tmux send-keys -l -t $win "$line" </dev/tty
    tmux send-keys -t $win Enter </dev/tty
    sleep 0.1
done

and the tdownload script is

Code: Select all

#!/bin/bash
# tdownload -- download a file from Unix R7 running under SIMH

def_win=0

help(){
    cat <<END
Download a uue encoded file from a tmux session.
Usage: $0 [options] <filename>
Options:
    -t n      Specify n as the tmux window number      ($def_win)
END
    exit 0
}
win=$def_win

while getopts t: name "$@"
do
    case $name in
t)
    win=$OPTARG ;;
*)
    help ;;
    esac
done
let shiftind=$OPTIND-1
shift $shiftind
if test "$#" != "1"
then
    help
fi
file=$1
pipe=$PWD/tpipe.$$
mknod $pipe p
echo Downloading $file from window $win...
tmux pipe-pane -t $win "cat >$pipe"
tmux send-keys -t $win "uuencode $file <$file" Enter
uudecode <$pipe
tmux pipe-pane -t $win
rm $pipe

Please let me know if you have any trouble getting uuencode and uudecode installed or using these scripts.

[pavelanni]

Thanks, Eric! Your scripts work fine and now I can copy files between my host and Unix inside the simulator. I copied and compiled uudecode / uuencode (one minor issue was when I tried to do it using cat via a telnet session; from a normal console login everything worked perfectly).
I'm still working on compiling stevie, but that's a separate thing. Also, BTW, I first tried your instructions on a Raspberry Pi, but now I'm running SIMH on my Linux laptop and your instructions were 100% applicable.
It's so much fun to tinker with all these old Unixes! I've also tried BSD 2.9 and BSD 2.11 and it's literally visible how Unix has evolved between the versions.
Thanks for your instructions, now I understand it much better.