Emulation not auto-starting

[Louis Erickson]

I've built myself an RPI 5 using the directions from https://obsolescence.dev/pidp-11-building-instructions.html which included downloading from github and not a tarball.  I'm running the Raspberry image of Debian Bookworm 64-bit, as suggested in the manual, and ran the initial installation with an HDMI monitor and keyboard set up.  I normally run headless.

At boot, the PiDP11 console is blank.

When I ssh into the system, I get the Linux motd followed by "0", which is the pdp11.sh running when there are no screen sessions.

If I run a "pdp11control start", the PiDP console lights up and whatever OS is set on the switches runs, usually idled.  After that, sshing in (or running pdp11.sh) gets the valid screen session.

It looks to me like there's no init script or systemd script for the system so I'm having to start it manually.  That's not what I expected; I expected it to start simh under screen at boot so I could have blinkenlights on a shelf without having to log in and mess with it.

Is there a systemd script someplace that I can install, or should the install script have installed one?

Other than no autostart, it's been great, and I love it.  I don't have a real use for it, but the blinkenlights make me happy.

[terri-...@glaver.org]

On Thursday, January 15, 2026 at 10:36:52 PM UTC-5 loki...@gmail.com wrote:

I've built myself an RPI 5 using the directions from https://obsolescence.dev/pidp-11-building-instructions.html which included downloading from github and not a tarball.  I'm running the Raspberry image of Debian Bookworm 64-bit, as suggested in the manual, and ran the initial installation with an HDMI monitor and keyboard set up.  I normally run headless.

If you have the "full desktop" version of Raspberry Pi OS (Debian Bookworm 64-bit), enable the VNC server for remote access so the system sees a "desktop" (even if it is the virtual one from VNC) and choose the "Autostart via the GUI" option when you run the PiDP-11 install.sh script. That will put an entry in ~/.config/autostart/ to start the PiDP-11 software when the desktop loads. The other choice (headless) adds a pdp11 command to .profile to autostart on the first remote login.

Note that the install.sh script isn't very robust and if you didn't select "pi" as the default username during setup, various things will be broken. You can try my development branch: https://github.com/Terri-Kennedy/pidp11 which fixes a number of things, including supporting non-pi usernames. I'm in the process of developing a whole new installer which you can try out (on a running PiDP-11): http://www.glaver.org/PiDP-11/v2-install-test.sh It will not make any changes as long as you don't go past this part:

This is your last chance to exit before installation proceeds. Do you

want to proceed or exit (proceed/exit, no default)? 

[Johnny Billquist]

This isn't something that should be started at first login. This should
be started at boot.

I don't remember many details (I hate systemd), but I have my machine
setup to start at boot. Don't matter if you then use some desktop, or
login via ssh. That is unrelated to how and when the PiDP11 is started.

Johnny

On 16/01/2026 14.54, terri-...@glaver.org wrote:
> On Thursday, January 15, 2026 at 10:36:52 PM UTC-5 loki...@gmail.com wrote:
>
> I've built myself an RPI 5 using the directions from https://

> obsolescence.dev/pidp-11-building-instructions.html <https://
> obsolescence.dev/pidp-11-building-instructions.html> which included

> downloading from github and not a tarball.  I'm running the
> Raspberry image of Debian Bookworm 64-bit, as suggested in the
> manual, and ran the initial installation with an HDMI monitor and
> keyboard set up.  I normally run headless.
>
>
> If you have the "full desktop" version of Raspberry Pi OS (Debian
> Bookworm 64-bit), enable the VNC server for remote access so the system
> sees a "desktop" (even if it is the virtual one from VNC) and choose the
> "Autostart via the GUI" option when you run the PiDP-11 install.sh
> script. That will put an entry in ~/.config/autostart/ to start the
> PiDP-11 software when the desktop loads. The other choice (headless)
> adds a pdp11 command to .profile to autostart on the first remote login.
>
> Note that the install.sh script isn't very robust and if you didn't
> select "pi" as the default username during setup, various things will be
> broken. You can try my development branch: https://github.com/Terri-
> Kennedy/pidp11 which fixes a number of things, including supporting non-
> pi usernames. I'm in the process of developing a whole new installer
> which you can try out (on a running PiDP-11): http://www.glaver.org/
> PiDP-11/v2-install-test.sh It will not make any changes as long as you
> don't go past this part:
>
> This is your last chance to exit before installation proceeds. Do you
> want to proceed or exit (proceed/exit, no default)?
>

> --
> 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
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pidp-11/
> ecca7ab2-6f0b-4d71-8710-0c3d50bb2ac6n%40googlegroups.com <https://
> groups.google.com/d/msgid/pidp-11/
> ecca7ab2-6f0b-4d71-8710-0c3d50bb2ac6n%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

[terri-...@glaver.org]

On Friday, January 16, 2026 at 9:16:53 AM UTC-5 b...@softjar.se wrote:

This isn't something that should be started at first login. This should
be started at boot.

"Should" and reality don't necessarily coincide in Oscar's programming -

he'll freely admit that he is much better at designing magnificent replica

hardware than the programming to run them, which is why he asked me

to re-do the the PiDP-11 code and installation procedure.

If you run install.sh (from either Oscar's GitHub or mine) and select head-

less, it is started from the user's .profile at the first login. From the install.sh

script:

Autostart via .desktop file for GUI setup

autostart via .profile for headless use without GUI

I don't remember many details (I hate systemd), but I have my machine
setup to start at boot. Don't matter if you then use some desktop, or
login via ssh. That is unrelated to how and when the PiDP11 is started. 

I suspect we're both doing things well beyond what Oscar's standard in-

stall provides.

cd /opt/pidp11; find . -type f -exec grep -H systemctl {} \;
 

will (eventually) tell you that it only finds references to starting rpcbind

(for SIMH to talk to the front panel) and no other references. 

[Johnny Billquist]

On 16/01/2026 15.40, terri-...@glaver.org wrote:
> On Friday, January 16, 2026 at 9:16:53 AM UTC-5 b...@softjar.sewrote:
>
> This isn't something that should be started at first login. This should
> be started at boot.
>
>
> "Should" and reality don't necessarily coincide in Oscar's programming -
> he'll freely admit that he is much better at designing magnificent replica
> hardware than the programming to run them, which is why he asked me
> to re-do the the PiDP-11 code and installation procedure.

No question about that. But this isn't about what Oscar might have done
or not done. This is about how it should be. And just because Oscar
isn't a programmer that don't mean he can't get things to work in a
reasonable way sometimes. :-)

> If you run install.sh (from either Oscar's GitHub or mine) and select head-
> less, it is started from the user's .profile at the first login. From
> the install.sh
> script:
>
> Autostart via .desktop file for GUI setup
>
> autostart via .profile for headless use without GUI

And that I think is the complete wrong idea. This is something that
should be started at boot.
I'll come back on this with how the systemd setup needs to be for things
to work. (I don't have access to my PiDP-11 at the moment, it seems. My
home system sometimes is hard to reach because of WiFi issues...)

> I don't remember many details (I hate systemd), but I have my machine
> setup to start at boot. Don't matter if you then use some desktop, or
> login via ssh. That is unrelated to how and when the PiDP11 is started.
>
>
> I suspect we're both doing things well beyond what Oscar's standard in-
> stall provides.

No doubt about that. :-)

> cd /opt/pidp11; find . -type f -exec grep -H systemctl {} \;
> will (eventually) tell you that it only finds references to starting rpcbind
> (for SIMH to talk to the front panel) and no other references.

I don't even know which version of things you are looking at, so it's
hard to comment.
I'll post later tonight what my setup is, and it starts the PiDP-11 up
as soon as the system boots (and this was actually how I got it from
Oscar...)

Johnny

[Johnny Billquist]

On 16/01/2026 16.03, Johnny Billquist wrote:

> I don't even know which version of things you are looking at, so it's
> hard to comment.
> I'll post later tonight what my setup is, and it starts the PiDP-11 up
> as soon as the system boots (and this was actually how I got it from
> Oscar...)

Ok. Managed to access my system.
So, in systemd, I have:

raspberrypi:systemd/system# systemctl cat pidp11
# /run/systemd/generator.late/pidp11.service
# Automatically generated by systemd-sysv-generator

[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/init.d/pidp11
Description=LSB: PiDP-11 emulator
Before=multi-user.target
Before=multi-user.target
Before=graphical.target

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
SuccessExitStatus=5 6
ExecStart=/etc/init.d/pidp11 start
ExecStop=/etc/init.d/pidp11 stop
raspberrypi:systemd/system#


That causes systemd to start this thing at boot.

That in turn runs /etc/init.d/pidp11, which is a script which basically
just runs /opt/pidp11/bin/pidp11.sh, which in turn is just stopping and
starting portmapper, server11 and client11.


And please don't make any comments on issues you might see in these
files. I didn't create them, and take no responsibility for them. But I
do use them. And they work as intended.
No need to log in. Do not matter if you have a headless or a GUI
environment, since this is completely independent and unaware of any
such details.

If I were to actually want to trim things, I suspect there are
improvements that can be done (including removing that duplicate line in
the file), but I *really* don't want to touch anything around systemd
unless I have to. :-P

Johnny

[terri-...@glaver.org]

On Friday, January 16, 2026 at 10:03:50 AM UTC-5 b...@softjar.se wrote:

And that I think is the complete wrong idea. This is something that
should be started at boot.
I'll come back on this with how the systemd setup needs to be for things
to work. (I don't have access to my PiDP-11 at the moment, it seems. My
home system sometimes is hard to reach because of WiFi issues...)

 Oscar changed a great many things when he put (different) PiDP-11 code

on GitHub. Mostly, he changed things to use p[i]dp11control (the [] is due to

the desktop shortcut being called one thing and the actual executable some-

thing else. He slapped the stuff done for the PiDP-10 on the PiDP-11 without

checking how it worked (that's why the terminal emulators broke), among

other oddities.

 

> cd /opt/pidp11; find . -type f -exec grep -H systemctl {} \;
> will (eventually) tell you that it only finds references to starting rpcbind
> (for SIMH to talk to the front panel) and no other references.

I don't even know which version of things you are looking at, so it's
hard to comment.

https://github.com/obsolescence/pidp11

Which is very different from the pre-GitHub version.

 

Ok. Managed to access my system.
So, in systemd, I have:

raspberrypi:systemd/system# systemctl cat pidp11
# /run/systemd/generator.late/pidp11.service
# Automatically generated by systemd-sysv-generator

Yup - that's the original version, before it got PiDP-10ified

On an Oscar GitHub install:

terry@spcpi2-host:~ $ systemctl cat pidp11
No files found for pidp11.service.

[Johnny Billquist]

On 16/01/2026 16.35, terri-...@glaver.org wrote:

[...]

> Yup - that's the original version, before it got PiDP-10ified
>
> On an Oscar GitHub install:
>
> terry@spcpi2-host:~ $ systemctl cat pidp11
> No files found for pidp11.service.

So we should get that back in there. :-)

Johnny

[terri-...@glaver.org]

On Friday, January 16, 2026 at 10:38:13 AM UTC-5 b...@softjar.se wrote:

So we should get that back in there. :-)

Yup. On the plate for my v2 installer. It's only on my personal site, not

GitHub for now, because it isn't ready for use (all of the fancy DEC-

style dialog is done, which is the hard part) and actually does the com-

pilation and part of the installation, which is still unfinished, as are the

installations of the operating systems. When I get more time...

[John D. Bruner]

If you start simh at boot time (which I do), it is likely that it will start before the NTP service has updated the system time. (This is possible if it is started at login time too, but less likely.)

If the PiDP11 has been turned off for a while, this will result in a jump in the system time.

simh_idle_ms_sleep() doesn't handle the jump in CLOCK_REALTIME very well, causing the simulated machine to apparently freeze. I worked around this by changing it to use CLOCK_MONOTONIC.

--John

--

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/7de5fc7f-3c28-49ac-9135-666213645de3n%40googlegroups.com.

[Johnny Billquist]

On 2026-01-16 18:14, 'John D. Bruner' via [PiDP-11] wrote:
> If you start simh at boot time (which I do), it is likely that it will
> start before the NTP service has updated the system time. (This is
> possible if it is started at login time too, but less likely.)

True.

> If the PiDP11 has been turned off for a while, this will result in a
> jump in the system time.
>
> simh_idle_ms_sleep() doesn't handle the jump in CLOCK_REALTIME very
> well, causing the simulated machine to apparently freeze. I worked
> around this by changing it to use CLOCK_MONOTONIC.

That's sad to hear. I usually do not run with any sort of idle
injection, so I'm not sure I would even have noticed. But either way,
first of all interesting that a jump forward in time would cause such an
effect. I could expect that more if time jumped backwards. But changing
it to use a monotonic clock seems very wise either way. Something to
push upstream?

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[terri-...@glaver.org]

On Friday, January 16, 2026 at 7:36:22 PM UTC-5 b...@softjar.se wrote:

[...] I could expect that more if time jumped backwards. But changing

it to use a monotonic clock seems very wise either way. Something to
push upstream? 

Upstream isn't particularly interested in us REALCONS weirdos 8-(

However, there is a project to re-base the PiDP-11 SIMH on Open-SIMH 4.1.0-current

and also to (optionally) use the Pi's gpiolib library instead of talking to the GPIO hard-

ware directly. That might not be fast enough on a Pi 3B, which is why I'm saying it will

likely be optional. But moving to gpiolib means that we don't have to grant the code a

capability to directly twiddle the hardware, and also means that things should "just

work" if/when a new Pi comes out with a different GPIO interface (right now the code

has to do things differently depending on whether it is a Pi 3, 4, or 5). 

[John D. Bruner]

An advantage of REALCONS vs putting the GPIO access into simh (as the PiDP10 does) is that you can also use the Java panels, notably on a non-PiDP machine. (There is even a KI10 Java panel for the PDP10, but it is not compatible with PDP10/kx10_cpu.c)

In any case, I have REALCONS-PiDP11 forks of simh/simh and open-simh/simh that I keep current with the upstream and which implement server11 using libgpiod (either v1 or v2, i.e., bookworm or trixie). My approach, however, diverges in other ways that may not be desirable for everyone. FWIW, you can find these forks at https://github.com/jdbruner/simh and https://github.com/jdbruner/open-simh

libgpiod works OK for me on a Pi 4, but I agree the additional overhead compared to mmap'ing /dev/mem could be too much for a Pi-3B.

--John

--

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/970723e2-5a83-4759-a7ad-5385544794a4n%40googlegroups.com.

[Louis Erickson]

So what I'm gathering is that this is an oversight and should be corrected.  Terry is aware and will fix it later in his upcoming installer.  John Bruner notes that simh has to start after ntpd, which systemd can do.  I'll try and put together a systemd file that does the right thing and post it here.

[Louis Erickson]

This systemd unit script should work to start the simh simulator running.  It runs it as user "pi" so that user can control it with pdp11control normally.  It stops and starts the service as the system goes into multiuser mode, after NTP has set the time.  Mine is in /etc/systemd/system/pidp11.service.  Run systemctl reload-daemon; systemctl enable pidp11.service; systemctl start pidp11.service to see it running.

Reboot to show it works.

---- pidp11.service ----

[Unit]
Description=LSB: PiDP-11 emulator
After=time-set.target

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
SuccessExitStatus=5 6

User=pi
ExecStart=/opt/pidp11/bin/pdp11control.sh start 0
ExecStop=/opt/pidp11/bin/pdp11control.sh stop

[Install]
WantedBy=multi-user.target

On Friday, January 16, 2026 at 6:08:24 PM UTC-8 terri-...@glaver.org wrote: