PiDP-11 software install seems to be badly broken (again)

[terry-...@glaver.org]

I followed the instructions on https://obsolescence.dev/pidp-11-building-instructions.html (Option #1) to add the PiDP-11 code to an existing, working Pi 5 with the official Pi 5 power supply. It's just a Pi 5 with an active cooler, not in a PiDP-11 case yet (I've been burned by this before).

I did the install via VNC on the latest 64-bit Raspberry Pi OS, running X11/VNC (not Wayland).

The only non-default choices I took were to compile from sources and to download the updated 2BSD and RSX-11M+ images.

Afterwards, I applied the new files from "Fixing the LED panel freeze issue" (this is why I've been abandoning the PiDP-11 for the last 5 years or so), and rebuilt the client and server, hoping that this would finally resolve the problem once and for all.

Then I did a 'sudo shutdown -r now' in my VNC session, and waited... nothing happened, and the Pi wasn't responding to pings (it is on a wired Ethernet).

I went downstairs and found the Pi sitting at a solid red light, fished out a mini HDMI to HDMI adapter and got a "No signal" on my monitor.

Power cycling the Pi generates the flurry of green LED activity as it boots from the SD card, and I get a brief flash of the customized Pi desktop (with the PDP-11/70 rendering and terminal icons on the desktop), the Pi responds to pings for about  5 seconds at the same time, then the monitor goes back to "No signal", the Pi stops responding to pings, and the Pi LED turns solid red again.

Has anyone else run into this? I doubt it was the addition of the newer PDP-11 operating systems during install, and nothing in client11/server11 should be able to completely kill the system to an "It's dead, Jim" solid red light, regardless of how badly things are messed up there - after all, it is user-mode code.

Before I go through the hassle of pulling the SD card out and trying to find what went wrong and/or getting frustrated and just wiping the card and starting over, has anyone else encountered this or a similar problem previously, and if so, what did you do to fix it?

Is it possible that the latest GitHub code is mis-reading the GPIO and interpreting the lack of a front panel knob as a pushed knob for the "shut down now"command?

This is very frustrating because I have 2 assembled PiDP-11's that have been around long enough that pictures of them are on the original Obsolescence Guaranteed web page, yet I always end up getting frustrated and packing them up, simply because the front panel gives up and dies*, even after various rounds of fixes. I was hoping that this time would be the charm, and was going to put a Pi 5, active cooler, NVMe bottom-mount board and other goodies in them and run them, but here I go again...

* This is very much a "your mileage may vary" problem - some people never have it, and some people seem to run into it a lot. I've been unlucky enough that the original beta code back from the days of my first kit was solid, giving many months before the front panel died, to shorter and shorter periods as each new software release happened, down to lasting only a few days at the start of the GitHub migration.

[Brent Rector]

I've run into exactly this problem - three times now. I have the PiDP-11 and see the eventual light freeze issue. I installed the patch and rebuilt. The system reboots and never comes up. Looking at the monitor during the reboot, it appears as if it boots and immediate does a shutdown.

I reinstalled everything from scratch from GitHub, rebuilding the SD Card. PiPD-11 works fine. I installed the patch, recompile, reboot and boom. Dead system.

I did it a third time with the same result. It appears the patch is the problem as the system works fine until I install it.

[terry-...@glaver.org]

Update: I mounted the SD card on another Pi 5 (that one boots from NVMe, so its SD slot is available for things like this).

I renamed /opt/pidp11 to /opt-pidp11-bad and the system came up, stays up, and I can VNC into it.

Armed with that info, I did another install as above, but skipping the compile from sources part. The Pi rebooted fine. pidpcontrol says the PiDP11 is running, the Tek emulator flashes briefly on the screen and auto-closes, the teletype gives me a yellow paper window wit no text, and neither of the VT52 window icons seem to start anything. This is probably because the Pi is doing the LED demo loop and otherwise not doing anything.

I then stopped the pidp11 with pidpcontrol, deleted the pidp11 subdirectory from /opt and did another install, except selecting "compile from sources" (the vanilla sources, without the recent patches posted here). That also worked.

I stopped the pidp11 and deleted the directory again, did another install but between the "git pull" and the "install.sh", I downloaded the files from the  "Fixing the LED panel freeze issue"  and installed them in the correct places. I then the "install.sh", but this time doing the compile from sources with the updated files. The system again went to a solid red LED on reboot. So at this point I think the problem is with the "Fixing the LED panel freeze issue" files.

I'm still not sure how user-mode code can halt the whole Pi 5, but I'll take it up with the author of that post. Perhaps his patches are model-specific and do something different on the Pi 5.

[terry-...@glaver.org]

I reported it over in the  "Fixing the LED panel freeze issue"  thread.

Two (hopefully relevant questions):

1) What model of Raspberry Pi are you using?

2) Are you using the pi in an actual PiDP-11 chassis or just a "naked" pi?

The reason I'm asking the question is that if it is a naked Pi, there are no switches / lights and the patch might be interpreting that as the command to shut down the system (which is built into the PiDP-11 code, but normally requires a toggle and a knob press).

[John Bruner]

If you can modify the SD card on another machine, try removing (or editing) the script that it uses to shut down the system: /opt/pidp11/bin/down.sh

It normally invokes that if you press the address select knob while the HALT switch is depressed.

I rewrote a lot of the logic for my own installation, and that's one of the things I got rid of. [I'm planning to wire the power switch (key) to a GPIO to shut down the Pi that way, but I haven't gotten around to it yet.]

--John

---

From: pid...@googlegroups.com <pid...@googlegroups.com> on behalf of terry-...@glaver.org <terry-...@glaver.org>
Sent: Saturday, July 5, 2025 13:53
To: [PiDP-11] <pid...@googlegroups.com>
Subject: [PiDP-11] Re: PiDP-11 software install seems to be badly broken (again)

 

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/9029b5e3-47b3-4121-b989-35fc418ecf9fn%40googlegroups.com.

[terry-...@glaver.org]

On Saturday, July 5, 2025 at 6:01:30 PM UTC-4 John Bruner wrote:

If you can modify the SD card on another machine, try removing (or editing) the script that it uses to shut down the system: /opt/pidp11/bin/down.sh

It is more broken than that. The files in the "Fixing the LED panel freeze issue" are based on much older versions of Oscar's sources (gpio.c from 2019 instead of 2023) and are lacking any sort of Pi 5 support. Since they're complete replacement files and not diffs, there's nothing to fail during the build, just a total failure when the system restarts and tries to use that code.

I've asked the poster of that fix if they could generate diffs between Oscar's files that they started with and their modified versions, so I can try to re-base them on Oscar's most recent code.

[terry-...@glaver.org]

BTW, I need to make a public apology to Oscar - this one is definitely not his fault.

Mea culpa.