Cannot boot a specified OS from the front panel

[Three Jeeps]

I completed assembling the 11/70 front panel and attached the RPi and the system responded correctly when I went through the 4-5 check out steps, e.g. load, deposit, halt, continue, etc.

I disconnected the monitor, keyboard, and mouse, rebooted the Pi  (all the SR switches were in the 'down' position, enable/halt was in halt), and the system went into IDLED 'monitor' program, with the LEDs flashing.

Now it is my understanding that if I select a OS to boot, e.g RT11 (0003) and hit the address rotary knob, the monitor should boot the specified OS...except it doesn't. 

All the LEDs turn off. When I connect to the pidp11 via VNC, open up a terminal window,

Type cd /opt/pidp11/bin , and restart the simulator using ./pidp11.sh 0003

it responds saying the client is connecting and then it goes into a continuous loop, spitting out the following:

PDP-11 simulator V4.0-0 Current  REALCONS build Dec 19 2023
Goodbye
Ignoring SR switches, argument provided to script: 0003

*** booting rt11 ***
./pidp11.sh: line 43: /run/pidp11/tmpsimhcommand.txt: Permission denied

*** Start client/server ***

PiDP-11 FP 2023

control-C stops the output looping

I looked at tmpsimhcommand.txt  and it contains one word: exit

Permissions are -rw-r- -r-- Tmpsimhcommand.txt

So what is the problem? How can I boot an os from the front panel?
Thanks

J

[Ggrinton]

I am having the same issue here.

Totally new build, out of the box, and I am following the instructions in the manual at https://obsolescence.dev/pidp11/PiDP-11_Manual.pdf.

Since it appears the file is being recreated by the script, I did a CHOWN to 777, and that appears to have resolved the issue. However, it woul dbe good to have the distribution fixed to avoid this problem.

Geoffrey

[Tim Geuy]

I started seeing the same issue ever since I rebuilt my system a few weeks back. Any time I attempt switching the OS from the front panel I see...

/opt/pidp11/bin/rebootsimh.sh: 4: cannot create /dev/shm/pidp11/tmpsimhcommand.txt: Permission denied

Simulation stopped, PC: 000166 (RTI)

Changing the file permissions of tmpsimhcommand.txt from 644 to 666 before attempting an OS change seems to stop the crash but just restarts IDLED whatever the switches are set to. I've also tried changing the owner and group to pi as that's the login account. Still no joy. Manually switching the OS from the simh command line works fine. That being said, I have observed that any changes made to tmpsimhcommand.txt  are reset to a group and owner of root and permissions of 644 by a system reboot.

I'm going to try an OS up rebuild in a couple of days (doesn't take long) unless someone has a fix for this bug.

Thanks,

Tim

[Ggrinton]

I'm starting to get a handle on this, but the multiple possibilities make it complex.

One (the most common, I think) reason for the error reported about tmpsimhcommand.txt is that an attempt is being made to start (restart) using the /opt/pidp11/bin/pidp11.sh command. 

Remember that when the Pi is booted, a Simh instance is created, and attached to a virtual console using the 'screen' utility. You can attach to this using the screen command using /opt/pidp11/etc/pdp.sh  (see the PiDP-11 Manual). If you want to start Simh manually, you first need to stop this instance (Ctrl/E and exit). Otherwise the tmpsimhcommand.txt file still exists, and trying to recreate it generates the reported error. The file /run/pidp11/tmpsimhcommand.txt is recreated each time a new OS is selected, and deleted on a clean exit.  It's a bit of a trap, as the default instance is connected to screen, and so is only visible on a console if you actually attach to the screen instance. 

Now, addressing the other issue raised:

If you start simh manually with a command like "/opt/pidp11/bin/pidp11.sh xx" (xx is a number) and then restart using the Address rotary switch, then the front panel switches are ignored. The same OS as previously selected is restarted. The script that starts Simh is still running, and still has the argument "set". You can see this as it reports something like:

          Ignoring SR switches, argument provided to script: 3

To start Simh isn a way that allows the console switches to be read on a restart, you need to start if without an argument:  "/opt/pidp11/bin/pidp11.sh"

Geoffrey

[Tim Geuy]

Geoffrey

For testing I was rebooting the Pi, logging in which grabs the simh console, setting a number on the SR switches, and pushing the rotary dial. This would fail with a permission error unless logged in on a second session (which grabs the console) and use the first session to change permissions on the tmpsimhcommand.txt file. 

In addition, when I quit (ctrl/E followed by the quit command) I get a message asking if I want to delete tmpsimhcommand.txt which then fails with a permission denied error.

Prior to my recent rebuild I was using the older manual build for 64 bit Pi OS which was working fine. When the new build process (option #2) for 64 bit Pi OS became available recently, I did a wipe and rebuild which is when the issue appeared.

Tim

[Ggrinton]

OK, we may be on different builds. I am using  http://pidp.net/pidp11/2024/pidp11.tar.gz

I note you say that logging in "grabs the simh console", so that is different. In my case, the simh console is directed to "screen" and I need to attach to that using pdp.sh or 'sceen -D -r". You may need to trace through and check out the code in your build.

Geoffrey

[Tim Geuy]

That's the same build I'm using. I do run my PiDP-11 headless using a serial terminal running off a USB serial adapter plugged into the Pi augmented by ssh when I need additional console sessions. As a result, "screen" attaches automatically at login, and jumps to the most recent login if I have multiple connections to the Pi.

[Ggrinton]

Thanks for confirming that.  And an apology - I remembered that I had deliberately chosen not to use pi as the default account, to avoid the automatic connection to the running screen instance. 

Once I reconfigured to set the default login to pi, of course it does come up connected to the running Simh.

However, I am still not seeing the symptoms you describe. I'll keep playing to see if I can trigger any of that.

[Tim Geuy]

So....I wiped my SD card, installed the latest Pi OS (64-bit), patched it up to date, and then installed the PiDP software using the process from the latest build instructions (option #2)...

sudo mkdir /opt/pidp11
cd /opt
sudo wget http://pidp.net/pidp11/2024/pidp11.tar.gz
sudo gzip -d pidp11.tar.gz
sudo tar -xvf pidp11.tar
sudo /opt/pidp11/install/install.sh

...and everything is back to working as intended. Now to start tweaking things again and see if I can identify what I broke.

[Larry Harris]

I'm seeing the exact same thing here with the flash card flashed with Option #1 downloaded 2025/2/8.  I followed Option #2 and have the desired outcome.  Thanks a ton to the OP for this thread - I had first assumed something must be wrong, but all my switches tested OK.