Thursday, May 2, 2013

Ten over Pi

In a previous post I did a small incursion into the business oriented data processing. The system I used to illustrate an example of a CODASYL database was a simulated PDP-10 running the TOPS-10 operating system hosted in a Raspberry Pi computer.

TOPS-10 was quite a nice operating system for its time. It has some "modern" capabilities associated to mainframe-class computing, including a somehow advanced accounting system, job protection, resource allocation based on user and group, priority based scheduling, operator interface and batch system. Its command language is, anyway, quite basic and its help system is limited.

The successor to TOPS-10 for the PDP-10 architecture was named, in a show of originality, TOPS-20. It was itself based on a previous operating system developed by a private company named TENEX. TOPS-20 supported the execution of TOPS-10 binaries, but was an enormous improvement over its predecessors...And we could say it was also a big improvement over its successors too. Its command processor has an awesome feature, similar to the command completion we find in "modern" shells as bash or ksh. The difference is that the TOPS-20 command processor "knows" about the syntax and options of whatever you are typing and offers you a choice of suitable completions. And that facility can be used from user programs too... Incidentally, those of you who are openVMS users or hobbyists can experience that kind of help in the MULTINET command. Press '?' and you will get a list of options. Press 'ESC' and your current typing will be completed, as long as there are just one possible completion.

In this post we will see how we can set up a simulated TOPS-20 system. And, specifically, we will set it up on a Raspberry Pi computer. So we will have a mainframe class computer within a credit-card sized gizmo...

Simulating a KL10 system

Our good friend simh is not a good option to run TOPS-20. The reason is simh emulates a Decsystem-10, based on the KS-10 CPU. The KS-10 was a scaled down version of the "big" PDP-10 machines. It is posible to run TOPS-20 in a KS-10, but it is limited to the 4.something version. The last TOPS-20 version, the one we will want to run, is 7.1. Nevertheless, the real reason we will not want to use simh is the lack of the NI20 networking interface, necessary to plug the simulated machine into the network, either internet, decnet or both. Fortunately, there is another simulator we can use: Ken Harrenstien's KLH10

KLH10 has not been enhanced for some time. The newest version you can get, as far as I know, comes with a full image of TOPS-20, ready to be used. This is the work of Mark Crispin, and can be found also here. Unfortunately, the package contains binaries just for Linux over intel processors. Since we want to use a Raspberry, which is ARM-based, we will have to compile KLH from sources. 

The directory structure we get after expaning the tarball is:

panda-dist -- klh10-2.0h --- doc
                         +-- contrib
                         +-- run
                         +-- src
                         +-- bld  --- fbppc
                                  +-- fbx86
                                  +-- lnx86
                                  +-- lnxarm
                                  +-- lnxppc
                                  +-- nbaxp
                                  +-- nbx86
                                  +-- osfaxp
                                  +-- solsparc

We must start the compilation from the appropiate bld subdirectory. For the pi we could use the lnxarm one, but in my experience the setup in that directory does not work very well. What I did was to create another subdirectory (which I called lnxarmpi) and to copy everything from lnx86. Then, open the Makefile in your editor of choice and edit the stanza:

               -DKLH10_DEV_LITES=1 \

So it reads:


That is, change CENV_CPU_I386 to CENV_CPU_ARM and remove the KLJ10_DEV_LITES definition (there is no parallel port in the Pi).

Before trying to compile KLH10 we must do another change. Move to the src directory and search for the base-kl rule. You can now create a new rule with a different name or simply edit the current one, changing these lines:

     -DKLH10_ITIME_INTRP=1   \
     -DKLH10_CTYIO_INT=1     \

     -DKLH10_ITIME_SYNC=1   \
     -DKLH10_CTYIO_INT=0    \ 

This magic spell comes from this alt.sys.pdp10 post.The reason is "high performance" computers wreck the asynchronous mechanisms of KLH10. Of course, KLH10 was written during the late 90's so almost every current computer is a "high performance" platform. Even the humble Rapsberry Pi. Oh, and aparently there is no fix for that problem (I guess the whole simulator would have to be reengineered). I tried changing some timer related constants, just as a wild try, and did not succeed.

Once you have done this, change to the bld/lnxarmpi directory and issue the "make base-kl" command (unless you created a new rule; in that case use that new rule name). And then go for a coffee. Or two. The Raspberry Pi is not a fast machine!

Once the compilation is over, just follow the instructions you will find in the panda distribution package to do the initial run and setup of TOPS-20. If everything goes well you will have a telnet-accessible TOPS-20 system, connected to the internet (or, at least, to your local network). The system has a bunch of goodies: FORTRAN, COBOL, PASCAL and other compilers. Several games (text based, of course), including the original ADVENTURE (type "run advent" to play), colosal cave, a VT version of STARTREK and some more.

To learn about the system itself, nothing better than the original user manual. You can find a webified copy at The original manuals are also available in scanned format at If you want to get deeper into TOPS-20 you will need at least the administration manuals.

Finishing touch

Having an internet connected TOPS-20 emulated system is cool, but it is even cooler to enable the "native" networking of those machines: DECNET. To do it just add the following lines at the end of the SYSTEM:7-1-CONFIG.CMD file:


Use your own nodename instead of NODNAM and your area and address instead of A.NNNN. Reboot your system and DECNET should come up. Remember to set up adequately the network interface (check the KLH10 documentation about setting up a DECNET capable configuration). Now, to populate your DECNET databases, you must use the SETNOD program:


The SAVE command saves the entered nodes into a binary file. The INSERT command updates the live tables with the defined nodes (something similar to the SET KNOWN NODES ALL command in VMS NCP). To reload the node database at startup, add the following lines to SYSTEM:7-1-SYSJOB.RUN, just after the ^ESET LOGIN ANY:


Replace FILENAME by the name you used when you saved the node database from SETNOD.

You must also uncomment three lines from the file SYSTEM:SYSTEM:CMD


And this is all for now. As always, if you want to try any of these recipes and have any kind of trouble, just drop a commend and I will try to help..


This post has been in draft status for a while. I begun to wrote it just after the one about TOPS-10. When I was about to publish it, Mr. Mark Crispin, the man behind the PANDA distribution and a lot of other things, passed away. I did not have the pleasure to know him, neither personally nor thru electronic communication, but I have read his comments in the PDP-10 mailing lists and other places. It would be presumptuous to pretend to pay him an homage in this humble blog post, so all what I will say is a very big THANK YOU. We human beings all pass away, but for some admirable people, their work will live forever.


I have just run into this post:, which explains clearly and succintly the steps to do to run KLH10 in the Raspberry Pi, including a patch for KLH which makes it much easier to network. To apply the tap patch, just download it into the main panda distribution unzip directory and run:

$ patch -p0 < tuntap.patch

And then rebuild KLH10.

Wednesday, January 16, 2013

Blinkenlights: Not so difficult as I thought

I have to make a confession: I am a very, very clumsy person. That is one of the reasons I work in the software side of Computer Science. It is guaranteed I will break anything I try to repair or to fix. It is quite a miracle my VAXen  are still alive. I even had to replace a fan of my MicroVAX 3300. I made a... patchwork, and it works.

So, when I begun my little blinkenlights project I did not have a lot of faith about my manual abilities. Fortunately, electronics prototyping has advanced a lot and now it is posible to build circuit prototypes without having to struggle with a soldering iron. I will eventually try to do some soldering, but right now it is all about solderless breadboards.

And I been able to get some blinking leds :). I won't post again a video... just check the previous entry!

Goals and basic design

My goals are quite modest: I wanted just to have the equivalent to the display data lights one can find in a "classic" PDP-11 console, like the one in the PDP-11/70. That console has more lights than those: a 22 lights address display and several status and error reporting indicators. My "console" will have just 18 LEDS: 16 leds for the 16 bits of a PDP-11 word, plus a parity indicator and a generic error light.

The data to be displayed will be selected depositing values into three "registers" in SIMH, belonging to a new device which I have called "BLNK":
  • DATASEL will represent the "Data select" key in the real console. The posible values are:
    • 0 for Register
    • 1 for Data Path
    • 2 for Bus Register
    • 3 for micro Address
  • DISPSEL will represent the "Display select" key. The values are:
    • 0 for Console Physical
    • 1 for User - Instruction
    • 2 for User - Data
    • 3 for Super - Instruction
    • 4 for Super - Data
    • 5 for Kernel - Instruction
    • 6 for Kernel - Data
    • 7 for Program Physical
  • DISPADD will hold the displayed value.
The default values will be zero for all three registers, so the "console" will show the value for R0. The light chasers implemented in several PDP-11 operating systems rotate and shift bit patterns in R0 which are shown in the lights, so it seems like a decent default setting.

Functional design and implementation

I have not done any simh hacking before, so one of my goals was to go the easy way. I implemented the console lights as a new device, so I didn't had to patch neither the scp (the control program for all the simh emulators) nor the core pdp-11 implementation. All the simh part functionality is in two new files (one of them being a header) and a small, controlled modification to pdp11_sys.c just to add the new device. This way it will be easy to merge my patches with future versions of simh. If you want to check it you can download from This patch is for the current development version (4.0-beta), but it should apply to 3.9 too (I have not tried that).

If you want to build simh with this patch you will need too the code which actually implements the blinking lights. My implementation has two parts:
  • A server part, which holds the real (or virtual) lights to be shown. This server gets the bits to represent via UDP packets or via serial connection. 
  • A client library, which sends the information to display to the server, either via UDP or serial connection.
I have written three different servers. Two of them are real, and the other one is virtual. 

  • I wrote also a Raspberry Pi version which gets the data listening to UDP packets. 
  • And finally, I made an Arduino controlled version, which gets the data via serial port.
The rasperry and the arduino versions use basically the same hardware; the only difference is in the resistors used to limit the current going thru the leds. The Arduino operates at 5V, while the Raspberry uses 3.3V (it has also a 5V current source pin, but it is not wise to mix both tension levels). The resistors for the Rasp-pi version are of 330 Ohms, while for the Arduino I use 470 ohms. Oh, the circuit is basically the one described in this tutorial, with a minor modification.

The code for the client library and the servers is also accessible here The arduino sketch is also there. To build simh with the client code you have to build the client library and install it (the makefile installs it in /usr/local, edit it if you want to use a different location). Then build the pdp11 simulator using the patched makefile.


Once you have built the pdp11 simulator, you will be able to use the new BLNK device (which is disabled by default). Enable it with:


And attach it to a running udp server using:

sim> ATTACH BLNK udp:ip-address:port

If you are running the java application, it should be:

sim> ATTACH BLNK udp:localhost:11696

If you build the arduino circuit, then the attach command is:

sim> ATTACH BLNK tty:/dev/name-of-your-arduino-serial-usb

The only modifier is RATE. The command


will try to establish an update refresh rate of 50 Hz (the leds will be updated 50 times at a second). The default value is 100. Don't push it too hard if you are using an Arduino, since the poor thing will not be able to cope with the load and will hang up...

If you attach BLNK and boot RSX-11M+ you will enjoy a nice light show. 

As usual, your comments and suggestions will be very welcome!


I have made some corrections to the simh part and to the arduino side. I have created a simh repositoy at github, accessible via The master branch of that repository will follow the "official" simh tree ( The branch "BlinkenLights" will contain my modified version ( I will try to keep it in sync with the master, so it should build without too much trouble. I don't plan to ask Mark to merge my changes, since there is the possibility of developing an "official" blinkenlights support into simh (which would make mine obsolete).

The current version works more closely to the original hardware. So to watch a CPU register you have to load into the address register the correct "pseudoaddress" (R0 is at 017777700, R1 at 017777701 and so on). The "bus" and "micro" settings do not work (they just lite the red LED). But I was able to use the blinky thing to debug some work I did in the CR (card driver) emulation in simh :).

Friday, January 4, 2013

Let there be... blinkenlight!

This is a short post. I have been playing a little bit in the hardware side. Any serious computer MUST have blinkenlights, so I am adding some to my simh-simulated PDP-11s:

I have to work out the timing and the sampling rate, and I have not finished yet the integration with simh. But it works (somehow), and the lights blink (a litle bit). It is a distributed "blinkenlight server" which gets the data to show via UDP packets, although I plan to develop also a "local" version for instances of the simulator running in the same Ras-Pi. And at this moment, the address of the "server" and the item to use to make the lights move are hardcoded into a simh device. :)

I will publish the code (of both the server and the client side) and the schematics of the electronic part when they are presentable. But I'm very excited with the result and I wanted to share what I have got ;)

Oh, by the way, happy  new year to everyone!