Wednesday, May 11, 2016

Containerizing simh: BSD in a box

Containers (almost) everywhere

One of the buzzwords of the year is "container". Since it seems that containers and containerized systems are here to stay, I decided to take a look at that technology. Specially after good'ol IBM has blessed it, as can be read here. So it looks the Big Blue is going to push that technology to their Holy zOS land. Or something like that.

So I went to Docker Land and started reading about the stuff. This post is not an explanation about what containers are and how does Docker implements them. There are much better text in the web to learn about that, and I am just the last guy to learn about them, so my explanations would be probably wrong. This blog is about old computers, real and simulated. So let's do some retrocomputing...

Containerizing the past
The idea of packaging an application as a service, with all the dependencies solved so it is basically a software appliance is, of course nice. And, of course, it is not new. We have been able to do that using virtual machines for some time. The main difference is containers pretend to be lightweight and just package what is needed. A VM must include the whole operating system to run, and today operating systems tend to be multi-gigabyte monsters. So the idea of putting, let's say, a PDP-11 simulator with its configuration files and probably also an Operating System (of the "just megabytes" kind) in a nice, ready to run, packaging is appealing. So I wanted to know if that was posible.

It, indeed, is.

And I can offer now the results of this little research, in the form of five docker "images", that you can download and convert into multiple "containers" as you want. The images are the following:

  • jguillaumes/simh-allsims: Contains just the simulator binaries, compiled and ready to run.
  • jguillaumes/simh-pdpbsd: Contains the pdp11 simulator plus a BSD 2.11 image.
  • jguillaumes/simh-vaxbsd: Contains the vax780 simulator plus a BSD 4.3 image.
  • jguillaumes/simh-vaxnbsd: Contains the vax simulator plus a NetBSD 6.0 image.
  • jguillaumes/simh-vax: Contains the vax, vax780 and pdp11 simulator plus a pair of example config files.
To use those images you need to download and install the docker runtime in your machine. There are versions for Windows, Mac OSX and Linux. Oh, you must have a 64 bit system or it wont work at all. 

Using the images

To use the images you can "pull" them from the public Docker repository where I have uploaded them, You can do this explicitly or you can simply try to run the images. Docker will automatically pull what you need. 

Self-contained images

Let's take the PDP-11 BSD 2.11 for a ride:

docker run --name pdpbsd -p 2323:2323 -it jguillaumes/simh-pdpbsd
Unable to find image 'jguillaumes/simh-pdpbsd:latest' locally
latest: Pulling from jguillaumes/simh-pdpbsd

d0ca440e8637: Already exists 
a1e3125132f8: Already exists 
5fc723fb3b91: Already exists 
22f14ee4456b: Already exists 
fe58eb150210: Already exists 
3cacf15d9073: Already exists 
d95addc21743: Pull complete 
a3770888ba4a: Pull complete 
7e7599d06256: Pull complete 
705a1c43d99d: Pull complete 
Digest: sha256:51d3b466eda25296668302bd1ce6f599d2897a077b04d4d289ee27e07f7f4ef5
Status: Downloaded newer image for jguillaumes/simh-pdpbsd:latest
Uncompressing OS image file...

PDP-11 simulator V4.0-0 Beta        git commit id: 7bd58c6d
Logging to file "console.log"
Disabling RK
Disabling HK
Disabling TM
Listening on port 2323
LPT: creating new file
Eth: opened OS device eth0

73Boot from ra(0,0,0) at 0172150

At this point just press RETURN to proceed to boot BSD


: ra(0,0,0)unix
Boot: bootdev=02400 bootcsr=0172150

2.11 BSD UNIX #7: Thu Jun 8 21:53:04 PDT 1995
    root@:/usr/src/sys/DOKBSD

ra0: Ver 3 mod 3
ra0: RA81  size=891072
attaching qe0 csr 174440
qe0: DEC DEQNA addr 08:00:2b:aa:bb:cc
attaching sl
attaching lo0

phys mem  = 4186112
avail mem = 3730240
user mem  = 307200

May  9 05:49:32 init: configure system

dhv 0 csr 160440 vector 300 attached
lp ? csr 177514 vector 200 skipped:  No autoconfig routines.
ra 0 csr 172150 vector 154 vectorset attached
rl 0 csr 174400 vector 160 attached
tms 0 csr 174500 vector 260 vectorset attached
erase, kill ^U, intr ^C
#

Now you are in single user mode. It is a good moment to edit some /etc files, or simply press CTRL-D to exit single user mode and proceed to full multiuser...

 Fast boot ... skipping disk checks                                                        
checking quotas: done. 
Assuming NETWORKING system ...
add host dokbsd: gateway localhost
add net default: gateway 172.17.0.1
starting system logger
May  9 05:49:39 dokbsd vmunix: ra0: Ver 3 mod 3
May  9 05:49:39 dokbsd vmunix: ra0: RA81  size=891072
checking for core dump... 
preserving editor files
clearing /tmp
standard daemons: update cron accounting.
starting network daemons: inetd rwhod printer.
starting local daemons: sendmail.
May  9 05:49:39 dokbsd ntpd[98]: init_ntp: bad drift compensation value
Mon May  9 05:49:39 PDT 2016
May  9 05:49:39 dokbsd init: kernel security level changed from 0 to 1


2.11 BSD UNIX (dokbsd) (console)

login: root
erase, kill ^U, intr ^C

Login as root with no password... and voilĂ ! You are logged into a BSD 2.11 system running on a PDP-11 simulator. The kernel has network support, which is functional. Just edit /etc/resolv.conf to use a working DNS server and you will be in the internets:

# echo "nameserver 8.8.8.8" >> /etc/resolv.conf 
# ping www.google.com
PING www.google.com (216.58.214.164): 56 data bytes
64 bytes from 216.58.214.164: icmp_seq=0 ttl=37 time=33.334 ms
64 bytes from 216.58.214.164: icmp_seq=1 ttl=37 time=16.667 ms
64 bytes from 216.58.214.164: icmp_seq=2 ttl=37 time=16.667 ms
64 bytes from 216.58.214.164: icmp_seq=3 ttl=37 time=16.667 ms
^C
--- www.google.com ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 16.667/20.833/33.334 ms

(Of course I'm supposing your Docker installation is properly configured and your machine has internet access...).

The pdp11 simulator is configured with a DZ terminal multiplexer attached to the port 2323 in the container. This port is mapped to the same 2323 port in the host so you can TELNET into it. If you start several containers you will have to use a different local port for each one (specified as the first number in the -p parameter: if you want to map the 2323 port in the container to the 9999 port in the host, specify -p 9999:2323). If you are using Linux, you can TELNET to localhost; if you are using OSX or Windows you must use the IP address of the Docker host, which can be obtained with the docker-machine ip command. 

You should shut down the system properly (those old unices have filesystems that break easily if you simply stop the simulator) and you will be back at your host prompt:

# shutdown -h now
Shutdown at 06:11 (in 0 minutes) [pid 118]

        *** FINAL System shutdown message from root@dokbsd ***

System going down IMMEDIATELY

System shutdown time has arrived
May  9 06:11:01 dokbsd shutdown: halt by root: 
May  9 06:11:04 dokbsd syslogd: going down on signal 15
CAUTION: some process(es) wouldn't die
syncing disks... done
halting

HALT instruction, PC: 000014 (MOV #1,11616)
Goodbye
Eth: closed eth0
Log file closed
macjordie:~ jguillaumes$ 

Now you have a container in your Docker host. To run it again, do not use the docker run command, which would create a new container. Use the docker start command, followed by a docker attach.

macjordie:~ jguillaumes$ docker start pdpbsd
pdpbsd
macjordie:~ jguillaumes$ docker attach pdpbsd

: ra(0,0,0)unix
Boot: bootdev=02400 bootcsr=0172150

2.11 BSD UNIX #7: Thu Jun 8 21:53:04 PDT 1995

If you are not very fast, you will not see the ":" boot prompt (because at the attach time it will already be in the "console"). Just press enter and the boot will continue.

The simh-vaxbsd and simh-vaxnbsd images work just like this one. The BSD 4.3 boots straight into BSD, and the root is also passwordless. The NetBSD one asks for the boot device (just the first time it boots), and its root account has the password "manager". The other two images are a little bit different.

Non self-contained images

The other two images do not contain an OS image for the simulators, so you have to provide one. This can be done in two ways: 

  • Copy the image from your host to the container using docker cp
  • Mount the directory that contains your image into the /machines volume in the container, using the -v parameter of the docker run command as this: 
-v your_image_directory:/machines 

In any case, when you start the machine you will find youself in a shell in the /machines subdirectory, where you can start the simulator you want, providing your own configuration file (the simh-vax image has some samples). The images contain the nano editor so you don't need to fight vi.

There is an annoying bug, probably caused by the linux distribution I've based the images on (Alpine Linux), which does not use the regular C runtime library and somehow messes the console input in simh. It does not display any prompt, but you can type in commands and it works.

Building your own images

The dockerfiles and additional material needed to build those images are available in github. Feel free to clone/fork/reuse whatever you find there. The compressed images for BSD 2.11 and BSD 4.3 are in the repository. The one for NetBSD is not. Check the README.txt file in the vaxnbsd subdirectory for a link to download it (it weights about 260MB). The README.md file contains details and instructions to build the docker images, and suggestions to add your own OS images to build containerized systems. Please remember it is not allowed to distribute VMS under the hobyist license, so keep any VMS image to yourself.

Further information and updates

The images mentioned in this post are available at Docker Hub. Just search for "jguillaumes" and you will find them. The descriptions contain information about its usage. Of course, feel free to contact me with comments, suggestions or bug reports!

Enjoy your containerized PDP-11 and VAXen!

Thursday, February 12, 2015

TOPS-20: Making more space in the public structure

The Panda distribution is for sure the easiest way to make contact with TOPS-20, and in a previous entry I explained how to set it up to run in a Raspberry Pi (or similar) computer. One of the challenges of using those ancient operating systems is the lack of support and/or documentation. Fortunately, there is a whole treasure of information in the internet, and a quite active newsgroup devoted to the PDP10 class computers, where some of the actual designers of those machines and those operating systems is happy to answer a beginners question about the work of their life.

On the other hand, one of the fun things one can do is to dig around and find the answers from himself!

The problem: lack of disk space in the public structure

The "public structure" is what in other environments we would call the "system disk" or the "root filesystem". The Panda Distribution comes with a public structure defined in a RP07 class disk. Those disks held about 476 Megabytes, and as far as I know the "regular" TOPS-20 did not support those devices for the public (boot) structure. The late Mark Crispin modified heavily the montitor (what we could call "kernel" nowadays) to support those big (at the time) disks. Just after the first boot, there is plenty of available space in Panda's TOPS20 structure:

@info disk
 TOPS20:<OPERATOR>
 3 Pages assigned
 500 Working pages, 500 Permanent pages allowed
 82831 Pages free on TOPS20:, 133545 pages used.

That is about 160 MBytes of space (remember that the PDP10 was a 36 bit machine, so our eight-bit bytes are not really the best unit in that environment). For a casual use it is obviously more than enough. But if you start installing stuff, testing things and messing around you can find yourself with a few thousands of pages left. In that case, you can do several things:

  • Purge the old versions of the log files to free up space. Those files, called LOGFILE.LOG, accumulate themselves in the SYSTEM: directory (that is a logical which points to TOPS20:<SYSTEM> and can take a big chunk of space.
  • Create another structure and mout it as a USER structure, using it to do your stuff.
  • Add another volume to the TOPS20: structure. This is the best long-term solution and it will be explained in this blog entry.

Preparation

We must do two things before we start adding space: preparing a DUMPER tape and actually dumping (backing up) the TOPS20: structure.

Creating a bootable DUMPER tape.

The first thing we must do is to make a bootable TAPE which must contain the DUMPER utility. The DUMPER utility is the TOPS-20 backup program. Since we will create a new, pristine structure we need to be able to boot directly into DUMPER from tape to restore our current information.

The good news is that it is really easy to create a dumper tape:

  • First, we will create a virtual tape, escaping to the KLH10 console (pressing CTRL-\) and typing:

@[HALTED: FE interrupt]
KLH10> devmount mta0 dumper.tap create
Mount requested: "dumper.tap"
KLH10> [mta0: Tape offline]

KLH10> cont
Continuing KN10 at loc 01063335...

@

  • Now we have to copy the monitor program and DUMPER itself into the tape. We will use Mark Crispin's monitor, which supports big structures:

@copy system:monitr.exe mta0:
 <SYSTEM>MONITR.EXE.1 => MTA0:MONITR [OK]
@copy tops20:<subsys>dumper.exe mta0:
 <SUBSYS>DUMPER.EXE.1 => MTA0:DUMPER [OK]
@rewind mta0:
@unload mta0:
@

  • And we are done. We just have to detach the virtual tape from the emulator, and keep the file safe

@[HALTED: FE interrupt]
KLH10> devunmount mta0
Unmount requested
[mta0: Tape offline]
KLH10> 


Backing up the system

Now we need to get a backup copy of our running system on tape. To do this we will shut down the system, and then we will use DUMPER to create the backup. These are the steps:
  • Enable privileges and shut down the system typing CTRL-E followed by CEASE NOW

@enable
$^Ecease now
 TOPS20 Will be shut down IMMEDIATELY 
[Confirm]
12-Feb-2015 12:54:20 ACJ: System shutdown set by job 9, user OPERATOR, program C
EASE, TTY5
$
[Timesharing is over]

OPERATOR - Wait for the message "Shutdown complete" before
entering commands to PARSER.
[ni20_cmdchk: Illop=0 wd=4,,0 qe=1443101]
[dpni20-W: "tap0" multicast table ignored - interface not dedicated]
[ni20_cmdchk: Illop=0 wd=4,,0 qe=164061]
SJ  0: OPR>Killed Job 1, User OPERATOR, TTY13, at 12-Feb-2015 12:54:21
SJ  0:  Used 0:00:00 in 0:17:24
[dpni20-W: "tap0" multicast table ignored - interface not dedicated]
[ni20_cmdchk: Illop=0 wd=4,,0 qe=164061]
12-Feb-2015 12:54:24 HSYS: Shutdown complete
  • Create a virtual tape to hold the backup. We do this as we did before, pressing CTRL-\ to access the console:
[HALTED: FE interrupt]
KLH10> devmount mta0 backup-tape.tap create
Mount requested: "backup-tape.tap"
[mta0: Tape online]
KLH10> cont
Continuing KN10 at loc 01003136...

$


  • Run DUMPER and take the backup. This step can take some time. You must be careful to not forget to issue the CREATE command before the SAVE. The CREATE command allows you to do the full restore you'll need afterwards, adding to the backup tape the image of the directory structure.

$r dumper
[Using MTA-DUMPER:]
DUMPER>tape mta0:
DUMPER>create
DUMPER>save tops20:

 DUMPER tape #1, Thu 12-Feb-2015 1257. 

 TOPS20:<ALGOL>
 TOPS20:<BBOARD>
 TOPS20:<BLISS>
.
.
.
 TOPS20:<UNSUPPORTED>
 TOPS20:<UTF9>
 TOPS20:<UTILITIES>
 TOPS20:<WINDOW>



 Total files dumped:   7403
 Total pages dumped: 104812
 Directories dumped:    141

 CPU time, seconds:  570.00


  • Detach the backup tape and shut down the simulator. Remember the system was already shut down, so we can quit KLH10 without damaging anything.
Now it is a good practice to make a copy of the virtual disk we are about to replace, just in case we are unable to restore the tape we have just made. Since we are going to create the disks from scratch, you can simply rename the file to avoid it to be overwritten. That is one of the nice things of emulation: we can do things we couldn't dream about if we were using real devices!

Creating the new system disks

Now we are going to create the new disk structure. The KLH10 distribution included in panda contains a configuration file which is appropriate to install a system from scratch. That file is inst-klt20.ini. We will modify this file to acomplish what we want to  do. The part of the file which contains the device definitions is:


devdef dte0 200   dte   master
devdef rh0  540   rh20
devdef rh1  544   rh20
devdef dsk0 rh0.0 rp    type=rp06 format=dbd9
devdef mta0 rh1.0 tm03  type=tu45


We will change the disk type to rp07 add another disk definition, so it will become:


devdef dte0 200   dte   master
devdef rh0  540   rh20
devdef rh1  544   rh20
devdef dsk0 rh0.0 rp    type=rp07 format=dbd9
devdef dsk1 rh0.1 rp    type=rp07 format=dbd9
devdef mta0 rh1.0 tm03  type=tu45

Now we will start the simulator. Be sure you have the mtboot.save file in the current directory and start kn10-kl using the modified configuration file:

$ ./kn10-kl inst-klt20.ini 
KLH10 V2.0H (MyKL) built Feb 12 2015 00:50:35
    Copyright ? 2002 Kenneth L. Harrenstien -- All Rights Reserved.
This program comes "AS IS" with ABSOLUTELY NO WARRANTY.

Compiled for LINUX on ARM with word model USEINT
Emulated config:
CPU: KL10-extend   SYS: T20   Pager: KL  APRID: 3600
Memory: 8192 pages of 512 words  (SHARED)
Time interval: SYNCH   Base: OSGET
Interval default: 60Hz
Internal clock: COUNT
Other: MCA25 JPC DEBUG PCCACHE EVHINT
Devices: DTE RH20 RPXX(DP) TM03(DP) NI20(DP)
[MEM: Allocating 8192 pages shared memory, clearing...done]

KLH10# ; Sample KLH10.INI for initial installation
.
.
.
KLH10# ; Load tape bootstrap directly
KLH10# load mtboot.sav
Using word format "c36"...
Loaded "mtboot.sav":
Format: DEC-CSAV
Data: 4067, Symwds: 0, Low: 040000, High: 054641, Startaddress: 040000
Entvec: JRST (120 ST: 0, 124 RE: 0, 137 VR: 0,,0)
KLH10# 
KLH10# ; Now ready to GO
KLH10# [EOF on inst-klt20.ini]
KLH10# 

Now we must attach the bootable dumper tape we build before, and start the virtual frontend:

KLH10# devmount mta0 dumper.tap
Mount requested: "dumper.tap"
[mta0: Tape online]
KLH10# go
Starting KN10 at loc 040000...

BOOT V11.0(315)

MTBOOT>

To load the monitor from the mounted tape, we will issue a '/L' command (without the quotes) and after that we will invoke the disk formatting procedure issuing a '/G143':
KLH10# go
Starting KN10 at loc 040000...

BOOT V11.0(315)

MTBOOT>/L

[BOOT: Loading] [OK]

MTBOOT>/G143



[For additional information type "?" to any of the following questions.]

Do you want to replace the file system on the system structure? 

The whole disk and structure formatting is as follows:
Do you want to replace the file system on the system structure? YES

Do you want to define the system structure? YES

How many packs are in this structure: 2

On which "CHANNEL,CONTROLLER,UNIT" is logical pack # 0 mounted? 0,-1,0

On which "CHANNEL,CONTROLLER,UNIT" is logical pack # 1 mounted? 0,-1,1

Do you want the default swapping space? Y

Do you want the default size front end file system? Y

Do you want the default size bootstrap area? Y

Do you want to enable password encryption for the system structure? Y

What is the name of this structure? TOPS20

[Structure "TOPS20" successfully defined]

[TOPS20 mounted]
?TOPS20 unit 0 has no BAT blocks.
Do you want to write a set of prototype BAT blocks? Y
?TOPS20 unit 1 has no BAT blocks.
Do you want to write a set of prototype BAT blocks? Y
PANDA PROGRAMMING, PANDA TOPS-20 Monitor 7.1(21733)-4 Internet: Loading host names
%%No SETSPD.

Be aware of the numbering of the controller (it is -1), and take almost all the defaults, excepting for the structure name, where you must specify TOPS20 explicitly. After that, our monitor will complain about not being able to load the internet address list and other stuff we don't need now. Eventually, the messages will stop. The next step will be to restore the backup we made previously.

Restoring our system

To begin the process we will press CTRL-C and will get a MX> prompt. Following from the last screen capture:

%%No SETSPD.

System restarting, wait...
Date and time is: Thursday, 12-February-2015 9:17PM
Why reload? 12-Feb-2015 21:17:48 ***BUGINF NOADDR*** Failed to find SYSTEM:INTERNET.ADDRESS file  Job: 0, User: OPERATOR
12-Feb-2015 21:17:48 ***BUGINF NOHSTN*** Failed to find host name file SYSTEM:HOSTS.TXT  Job: 0, User: OPERATOR
12-Feb-2015 21:17:48 ***BUGCHK NOACTF*** No account database - account validation disabled  Job: 0, User: OPERATOR

Why reload? OTHER - Question timeout
 DDMP: Started

No SYSJOB
12-Feb-2015 21:18:49 ***BUGCHK KNICFF*** PHYKNI - Cannot reload the NIA20  Job: 0, User: OPERATOR, Data: 600104
NO EXEC
MX>

Now we will load DUMPER into memory, following these steps:

MX>GET FILE mta0:
?
MX>GET FILE mta0:
MX>sTART
DUMPER>

Yes, the first command gives out and error, and the second one works. Notice you just have to type the first letter of the commands. A 'G' for GET FILE and an 'S' for START.

Now we must drop to the KLH10 console and mount the virtual tape which contains our backup:

DUMPER>[HALTED: FE interrupt]
KLH10> devmount mta0 backup-tape.tap 
Mount requested: "backup-tape.tap"
[mta0: Tape online]
KLH10> c
Continuing KN10 at loc 01053253...

DUMPER>

We are almost there. To restore the contents of the tape we will use the CREATE and RESTORE commands. Again, do not forget to issue the CREATE before the RESTORE. Ignore the error messages and be ready to wait for a while.

DUMPER>TAPE MTA0:
DUMPER>CREATE
DUMPER>RESTORE TOPS20: TOPS20:
UNNAMED saveset 12-Feb-2015 2057
%Failed to create TOPS20:<ROOT-DIRECTORY>Cannot find error message file - RETRYING
12-Feb-2015 21:24:52 ***BUGINF RTCRAT*** JSYSF: ROOT-DIRECTORY CRDIR attempted  Job: 1, User: OPERATOR, Data: 777576170026, 60000000
0000
12-Feb-2015 21:24:52 ***BUGINF RTCRAT*** JSYSF: ROOT-DIRECTORY CRDIR attempted  Job: 1, User: OPERATOR, Data: 777576170026, 60000000
0000
?Directory TOPS20:<ROOT-DIRECTORY> not created - Cannot find error message file
TOPS20:<ACCOUNTS> created
TOPS20:<ALGOL> created
TOPS20:<BBOARD> created
TOPS20:<BLISS> created
TOPS20:<BLISS-SOURCES> created
TOPS20:<CHIVES> created
TOPS20:<CHIVES.V1> created
TOPS20:<CHIVES.V1.CONFIG> created
TOPS20:<CHIVES.V1.DOCUMENTATION> created
TOPS20:<CHIVES.V1.SOURCE> created
TOPS20:<CLISP> created
TOPS20:<DECNET-SOURCES> created
.
.
.
TOPS20:<UTILITIES> created
TOPS20:<WINDOW> created
 Loading files into TOPS20:<ALGOL>
 Loading files into TOPS20:<BBOARD>
 Loading files into TOPS20:<BLISS>
.
.
.
Loading files into TOPS20:<TSU>
 Loading files into TOPS20:<UNSUPPORTED>
 Loading files into TOPS20:<UTF9>
 Loading files into TOPS20:<UTILITIES>
 Loading files into TOPS20:<WINDOW>
 End of Tape.


 Total files restored:   7402
 Total pages restored: 104811
 Directories created:   140
 Files skipped:     1
DUMPER>

And we are almost done! Now we just go back to the KLH10 console and quit the simulator. If we check the working directory we'll found two disk images (and possibily the old, renamed image). Now we have to modify the working configuration to add the newly created disk (the original name is klt20.ini) and start the simulator. If everthing has been done properly, we will be able to enjoy our new, super-sized public structure!

@info disk
 TOPS20:<OPERATOR>
 3 Pages assigned
 500 Working pages, 500 Permanent pages allowed
 297809 Pages free on TOPS20:, 134943 pages used.

Remember you can get the panda distribution, which includes both the PANDA TOPS-20 image and the KLH10 emulator (compiled for x86 linux) here. Enjoy!

Thursday, January 30, 2014

Networking a virtual KS-10

SIMH is in continuous evolution, adding new enhancements practically each month. The last oficially released version is still 3.9, but the new 4.0 version can be downloaded (as source) from the development git repository, and it is usually stable enough to be used (with all the caveats about using beta software).

The communication devices for several of the emulated DEC machines have received some attention in the last months. Right now it is posible to configure synchronous communication devices for the PDP-10, PDP-11 and VAX simulators, and those emulated devices have reached a point so useful things can be done with them. Specifically, it is now posible to give DECNET connectivity to TOPS-10 running over the pdp10 simulator. That simulator impersonates a KS based DECSYSTEM-2020, which had no ethernet devices supported in DECNET, so the only chance to network it is to use the serial devices. Right now simh includes support for the KDP/DUP combo and for the DMR controller. The DMR controller is still a little bit green and does not work properly, but the KDP/DUP is good enough to set up a decnet link. This article will tell you how to do it.

Communication devices in simh 4.0

Most communication devices emulated in simh share a common framework, so they have similar setup commands. They can be wired to real communication ports in the host computer, so actual wires and communication lines can be used to hook virtual machines. Nevertheless, we are going to use "virtual" wires based on TCP/IP connections. For each virtual line, we have to configure both communication endpoints:
  • We must attach our endpoint to a local port (TCP or UDP)
  • We must peer with the IP address and port number of the remote endpoint
This is the relevant stanza of my vax780.ini configuration setting un two lines of a DMC-11 device:

set dmc enable
set dmc lines=4

set dmc0 peer=192.168.0.12:21080
att dmc0 33061,UDP

set dmc1 peer=192.168.0.10:21911
att dmc1 34061,UDP                                                              

The values are self-describing. Line 0 is attached to the local UDP port 33061, while it is paired to the remote UDP port 21080 in the machine with address 192.168.0.12. Of course if you are running all the machines in the same host you would unse 127.0.0.1 here.

Now, the DUP device is an exception, since it does not share the same underworks as the DMC, DZ, VH and other serial stuff. The config stanza in the pdp10.ini file is:

set kdp enable
set dup enable
ATTACH DUP0 21080,Connect=192.168.0.8:33061,UDP
                                                   
Instead of using two separated statements, the attaching and pairing is done in just one line. Just check the "wires" are correctly connected and it will be ok. The choice between UDP and TCP (to use TCP just don't specify UDP) is basically up to you. If you plan to use the link between an instance running in a laptop and your home system you will probably want to use TCP, since it makes it easier to set up the port forwarding and NAT stuff.

Generating a TOPS-10 monitor with KDP/DUP and DECNET

I am assuming you have a TOPS-10 version 7.04 up and running. If not, refer to this article. Once you have it up, you will need to know the name and address you want to assign to your future new TOPS-10 DECNET node. You will want also to get:
Be aware those manuals are for the 7.03 version of the monitor, and there are important differences in the install process. They can be just a guideline. 

To generate a monitor with the necessary components, just follow the standard MONGEN procedure described here, with some differences. This is the section with the most important changes. The non-default responses are in red.

.
.
.
IPCF (YES,NO) :
ENQ/DEQ (YES,NO) :
Disk sets (ALL) :
Configure non-autoconfigured hardware (NO,YES) : YES
Number of RX211s (0,0-2) : 0
Number of KMC/DUP Lines (0,0-2) : 1
Type of line for KDP0 (ANF10,DECNET,USER,IBM) : DECNET
Number of DMR11 Lines (0,0-8) : 0
Number of PTYs (20,1-476) :

Network software (YES,NO) : YES
Node name : BTES11
Number of remote TTYs (456,0-456) : 16

ANF-10 software (YES,NO) : YES
  Node name (BTES11) :
  Node number of central site (1,1-77) : 11
  Remote terminals (YES,NO) :
  Virtual terminals (YES,NO) :
  Remote card readers (YES,NO) :
  Remote line printers (YES,NO) :
  Remote paper tape punches (NO,YES) :
  Remote paper tape readers (NO,YES) :
  Remote plotters (NO,YES) :
  Remote DN8x DDCMP devices (YES,NO) : no
  Remote data entry terminals (YES,NO) :
  Remote task-to-task (YES,NO) :
  Number of connects (256,1-512) : 16

DECnet software (YES,NO) : YES
  Node name (BTES11) :
  Area number of central site (1,1-63) : 7
  Node number of central site (1,1-1023) : 911
  Router type (ROUTING,NONROUTING) : ROUTING
  Transmit password (DECNET20) :
  Remote terminals (YES,NO) :

Decimal "symbol,value"    
.
.
.

It is very important to not take the default to the "Number of remote TTYs" and "Number of connects" questions. If you take the default the resulting monitor will not fit in the KS-10 memory space and it will not boot. Use your own node name and address. By the way, you must configure ANF10, or else the link step will fail with undefined symbols. It is also important to set up the machine as a ROUTING node; NONROUTING works only for ethernet connected nodes.

I use the following MIC file to automate the compilation and linking of the monitor:

. compile/compile f,s        
. compile/compile devprm,netprm,d36par        
. compile/compile syscnf+<common,comdev,commod>        

. r link newsys/save/noinitial/hash:13k = /locals -        common,comdev,commod,tops10[10,7,mon,ks]/search-
/patch:200/counters/go        
^Z        
. r pip        
new:newsys.exe=newsys.exe        
^Z

This procedure leaves the new monitor at NEW:NEWSYS.EXE, so it can be booted answering [1,5]NEWSYS to the BOOT> prompt.

Configuring DECNET-10

The monitor will start up the required components (NML, MX) automatically, but you have to add the commands to start up the circuit and the FAL listener to SYS:SYSTEM.CMD:

NCP SET CIRCUIT KDP-0-0 STATE ON
SET FAL-STREAM 0 NETWORK DECNET
SET FAL-STREAM 1 NETWORK DECNET
START FAL-STREAM 0
START FAL-STREAM 1                   

And while you are in it, make sure you have got also the following line:

CONFIG ADD MEMORY 512K 1024K

This one should go just before the NCP line shown above. This configuration allows for two simultaneous FAL operations (that is, you will be able to access your TOPS-10 files from two DECNET nodes at the same time). You can add more FAL streams, or leave just one, as you wish.

Booting the new monitor and testing the network

Now you can boot your newly created monitor. First shut down the system using SET KSYS NOW at the OPR> prompt, then stop the simulator using CTRL-E and boot it again.

sim> b rp
BOOT V4(76)

BOOT>[1,5]newsys
[Loading from DSKB:NEWSYS.EXE[1,5]]

BTES11 30-Jan-14
Why reload: new
Date:
Time:
Startup option: go
[Rebuilding the system search list from the HOM blocks]

[Rebuilding the active swapping list from the HOM blocks]

[Rebuilding the system dump list from the HOM blocks]


BTES11 15:05:25 CTY system 4096                           
.
.
.

Hopefully the machine will boot up and you will get the OPR> prompt. Now you can use NCP commands to check the network status (this is the result in my "production" machine):

OPR>enter ncp
NCP>show exec char
NCP>
14:07:10        NCP

Request # 3; Show Executor Node Characteristics Completed

Executor Node = 7.80 (BITXT1)

  Identification = DECnet-10 Version 4.0
  Management Version = 4.0.0
  Loop Count = 1
  Loop Length = 127
  Loop With = Mixed
  Incoming Timer = 30
  Outgoing Timer = 60
  NSP Version = 4.0.0
  Maximum Links = 65535
  Delay Factor = 48
  Delay Weight = 10
  Inactivity Timer = 120
  Retransmit Factor = 10
  Routing Version = 2.0.0
  Type = Routing IV
  Routing Timer = 600
  Broadcast Routing Timer = 40
  Maximum Address = 1023
  Maximum Circuits = 20
  Maximum Cost = 100
  Maximum Hops = 16
  Maximum Visits = 20
  Maximum Broadcast Nonrouters = 64
  Maximum Broadcast Routers = 32
  Maximum Buffers = 80
  Buffer Size = 576
  Segment Buffer Size = 576
NCP>show known circuits
NCP>
14:07:27        NCP

Request # 4; Show Known Circuits Summary Completed

Circuit     State                  Loopback    Adjacent
                                     Name        Node
KDP-0-0     On                                 7.61 (BITXOO)              

If the wiring of the KDP/DUP and the DMC interfaces is right and the VAX has the corresponding circuit (DMC-0) defined and up , you should get an adjacency up in your VAX machine (configured as router) and your network will be up and running:

.network
[ANF10 network: connected to BITXT1(10), located at BITXT1(10), 1 node]
Node    BITXT1  (10)    BITXT1  24-Jan-14

[DECnet network: local node BITXT1, 12 reachable nodes in area 7]
BITXOM  BITXOO  BITXOR  BITXOT  BITXOU  BITXOV  BITXOW  BITXOX  BITXOZ  BITXT0
BITXT1  MBSERV          

.r nft

*dir bitxov::
BITXOV::DUA1:[FAL$SERVER]BASIC-PLUS-2-RSX-V2-5.ZIP.1
BITXOV::DUA1:[FAL$SERVER]BASIC-PLUS-2-RSX-V2-7.ZIP.1
BITXOV::DUA1:[FAL$SERVER]CRDRV.MAC.1
BITXOV::DUA1:[FAL$SERVER]F77-V5-4.ZIP.1
BITXOV::DUA1:[FAL$SERVER]INFO.TXT.15
BITXOV::DUA1:[FAL$SERVER]NETSERVER.LOG.111
BITXOV::DUA1:[FAL$SERVER]TOPS10KLB.ZIP.1
BITXOV::DUA1:[FAL$SERVER]TOPS20PI.ZIP.1
BITXOV::DUA1:[FAL$SERVER]VAX-ULTRIX-4-5-INSTALL.ZIP.1
Total of 9 files            

The performance is good enough for SET HOST, but it is a bit slow for file transfers. You can get "Insufficient resources at remote node" trying to pull files from a VMS node. I have been poking around to fix that, but the lack of knowledge and available documentation has stopped me from progressing on that. The error seems to appear randomly, so it is not a big problem anyway.

And that is all! If you try to do this recipe and come into trouble, feel free to drop a comment and I will do my best to help you to fix it.