Installing the software for the PiDP, Oscar Vermeulen’s re-imagining of the PDP-8/I, couldn’t be easier. But that wasn’t going to stop me making life harder for myself.
I mean, why do we play with machines like this? It’s to learn, to explore, to discover, to take things apart and occasionally to break them. I haven’t done that last one yet, but give me time.
So here’s how I tweaked the PiDP installation. And the reason I did this is because I want to use the PiDP as a SIMH machine running a number of simulations.
The standard install
First, some basics. Let’s run through how the PiDP gets set up using Oscar’s install script. Go here if you want to get the full details of the hardware and to download the software (which will work even without the PiDP hardware). I think this would also be an appropriate place to let Oscar himself talk about the PiDP:
The software gets installed to /opt/pidp8 where there are directories for the hacked SIMH source code files, Oscar’s source code to work the lights and switches, disk image files and other goodies. Installing involves running a simple make command in two directories and then running an install script.
The install script puts a symbolic link to a bash script – pdp.sh – into the home directory of user pi. This script looks like this:
procs=`sudo screen -ls pidp | egrep '[0-9]+\.pidp' | wc -l` echo $procs if [ $procs -ne 0 ]; then sudo screen -r else
The idea behind this is that, by using screen, you can flip between the SIMH process and using the RPi as normal.
The install also puts a symbolic link in /etc/init.d to a script that is used to start or stop the SIMH PDP-8. And finally, a line is added to user pi’s .profile file to run the script detailed above. (As an aside, the install script also ensures that usbmount and screen are installed.)
The result of this is that when the machine is booted, the PDP-8 simulation gets started. And whenever you log in as user pi — directly at the Raspberry Pi or via SSH — you get redirected, using screen, to the simulation, so you’re dropped straight into the PDP-8. And it all works brilliantly. Except I didn’t want to do it that way.
The contrarian way
SIMH uses a lot of CPU. And when you’re not actually using the PDP simulation, the LEDs don’t do anything very interesting. These are blinkenlights, for heaven’s sake. They should be blinken. (I think that’s German but I’ll have to look it up.)
The first thing I did was to remove the symbolic link at /etc/init.d/pidp8 and then ran update-rc.d pidp8 defaults so that the simulation no longer starts automatically at boot. You can always start it manually by running /opt/pidp8/etc/rc.pidp8 start — but that’s a non-intuitive name and place. So I created a link:
$ ln -s /opt/pidp8/etc/rc.pidp8 /opt/pidp8/scripts/pidp8
So starting the simulation is a matter of issuing the command:
$ /opt/pidp8/scripts/pidp8 start
But that doesn’t put you into the simulation itself. The script that the standard install puts at /home/pi/pdp.sh does that. But this brings up another matter. I don’t want to run the PDP-8 as user pi — I want to run it as user pdp. I also took issue slightly with the existing script — if the simulation isn’t running, the script simply prints a 0 to the screen, which isn’t terribly informative.
So, I created a user called ‘pdp’. I’ve also created users called ‘altair’, ‘altairz80’ and ‘vax’, so you can see where I’m going with this. The idea is that when you log into the PiDP machine as one of these users, you get dropped into the appropriate simulation. Given that I’m sometimes trying to run a MIcroVAX on this tiny board, you can see why I don’t want the PDP-8 running automatically every time.
It’s my habit to always create a /home/<user>/scripts/ directory, and my standard setup is that $HOME/scripts is in the standard path (I define this in /etc/profile. I could have done it in /etc/environment. I didn’t. I don’t know why.)
So I then created the following script at /home/pdp/scripts/startpdp
#!/bin/bash echo "Attempting to shut down any running versions of deeper..." sudo killall deeper echo "Attempting to start PiDP..." sudo /opt/pidp8/scripts/pidp8 start procs=`sudo screen -ls pidp | egrep '[0-9]+\.pidp' | wc -l` if [ $procs -ne 0 ]; then sudo screen -r else echo "PiDP isn't running. Use sudo /opt/pidp8/scripts/pidp8 start" fi exit 0
Essentially, I’ve combined the startup process that was called from /etc/init.d and the user script that was originally at /home/pi/pdp.sh and added a more descriptive error message. I’ve added user pdp (and the other users, for that matter) to the sudoers file (/etc/sudoers) to avoid the inconvenient typing of passwords. There will be people who will indulge in a great wailing and gnashing of teeth over this. “Security!” they’ll cry. “Oh, the security!” But seriously, the number of Ukrainian cyber-criminals and Chinese cyber-warriors who are trying to hack my Raspberry Pi is fairly small. Most of them I count as friends. (As a journalist, cyber-security is my beat.)
I’ve left the pdp.sh script in /home/pdp, and I’ve also put a call to it in /home/pdp/.profile. The result is that, whenever I log in as user PDP, I get a message that the SIMH simulation isn’t running and I need to start it up. Similar to the script above, I have modified /home/pdp/pdp.sh slightly:
procs=`sudo screen -ls pidp | egrep '[0-9]+\.pidp' | wc -l` if [ $procs -ne 0 ]; then sudo screen -r else echo "PiDP isn't running. Use: startpdp" fi
That’s how things stand at the moment. At some point, I will change the call to pdp.sh in /home/pdp/.profile to a call to ~/scripts/startpdp — that way the simulation will start up automatically.
Now, at least one of you is bouncing up and down in your seat with a hand in the air crying, “But what about those references to ‘deeper’ in the startpdp script?”. Well quite…
There’s a famous program for the PDP-8 called ‘Deep Thought’ that basically just blinks the lights in a fascinatingly random way, as though the computer is engaged in meaningful introspection. You could run this on the SIMH PDP-8, but your poor little Raspberry Pi would be good for little else. Norman Davie, a member of the PiDP Google group, came up with a concise bit of C code called ‘deeper’ that uses Oscar’s software for reading the switches and blinking the lights. As it runs on the RPi directly, it uses a very modest amount of resources. You can adjust the nature of the blinking using the switches.
Here’s Norman’s video of it doing its stuff:
I put a call to deeper in /etc/rc.local so that it gets called at boot-up time. But if I run the PiDP code, I don’t want the two programs competing for the lights and switches. So the startpdp script first kills deeper. As deeper has to be run as root, the killall call is run with sudo.
We’re still not quite done. As I mentioned, I’m using this machine for multiple simulations. That meant building them all. As the PiDP binaries were already installed below /opt I decided to put the others there, too. So I put the SIMH files in /opt/simh/simh-master and did a simple make to build all the machines. This means the binaries are in /opt/simh/simh-master/BIN.
I then created a symlink:
$ ln -s /opt/simh/simh-master/BIN /opt/simh/BIN
And I added /opt/simh/BIN to the default path for everyone. (Again, I did this in /etc/profile. I still don’t know why.) Why the symlink? Well, the version of SIMH I’m using is 4.0 Beta. Note the beta part. This is software that’s going to change. And when it does, I may decide to leave the existing (and known good) 4.0 Beta code intact on the machine and build any new versions elsewhere, rather than replacing. Then all I need do is change one symlink to point to the new binaries – and then change it back again when everything goes horribly wrong. (Yeah, I’m a half-empty type.)
Finally, that screen business. The standard PiDP install uses screen to allow switching between SIMH mode and normal RPi mode. I don’t really need that because I have the PDP-8 simulation running as a separate user. I can still log in with another terminal to user pi. So I see a change in the future. But for the time being, where did I put that copy of Adventure…?