Using the keyswitch for shutdown

[Paulo Rebordão]

I'm in the process of doing some hardware changes to my PiDP-11 (adding 4 ADC channels).

I'm thinking of connecting the keyswitch wiring to the soft keyswitch pads already on the board. Doing this by itself will generate a SUDO SHUTDOWN when powering off or there's a need for some software intervention also ?

If so, what really happens while the key is in the off position, the Pi is still being powered ?

Sorry, the manual isn't very clear on this ?

Thanks

[Johnny Billquist]

First of all be aware that depending on the OS you're running on the
PDP-11, you might leave things in a less than ideal state by just
shutting down the Linux system.

The key does not usually cut the power to anything, as far as I can
remember. It's just another digital input you can read out.

Johnny

> --
> 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/764762ca-55a2-4f38-b2a6-9546f8e711c3n%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/764762ca-55a2-4f38-
> b2a6-9546f8e711c3n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Paulo Rebordão]

Yes I'm aware of that. It was just a way of simplifying the unix side. 

Paulo Rebordão

You received this message because you are subscribed to a topic in the Google Groups "[PiDP-11]" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pidp-11/AAm6ZUZRpTw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pidp-11+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/ae713f67-b1d2-4570-9809-c46ba3160ef6%40softjar.se.

[John D. Bruner]

IIRC, there are multiple options for wiring the power switch. One is to run the 5V supply through it, so it will directly control the power to the Pi. If you don't shut down the Pi first, you risk having unsaved disk content that will require salvaging (fsck) upon reboot.

A second option is to configure the Pi (4 or 5) to use a GPIO pin as a power signal. That's slightly less disruptive, because Linux does shut down before powering off. The Pi hardware should detect a change in the GPIO when the keyswitch is turned on again - and reboot.

I don't recall if it is possible to wire the keyswitch in parallel with the ADDR SELECT pushbutton so that turning it off would trigger the same behavior as pushing ADDR SELECT: based upon the position of the RUN/HALT switch, either quit simh (and start a new one after reading the console switches) or run "shutdown" to shut down the Pi.

If what you want is a way to shut down the Pi from the PiDP panel, you might just want to consider pressing HALT and then ADDR SELECT. 

If the guest (PDP-11 OS) isn't shut down first, then (depending upon the OS) you may leave its disk(s) in a corrupted state. Of course, the same is true when turning off the keyswitch on a real PDP-11. (The PDP-11 can trap upon loss and restoration of line power so that the O/S could save and restore volatile state. I've seen it work on 11/45s and 11/70s with magnetic core (non-volatile) memory - sometimes. Johnny, I'm curious - does your RSX-11M machine handle this successfully?)

--John

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/CA%2BgrvcpxEjSMvBysFaN_GN2M58cSdX1uGA%3D6_LnfAiZF0hEL%3DA%40mail.gmail.com.

[Johnny Billquist]

RSX in general do have the capability of dealing with power loss and
recovery, yes. But you need non-volatile memory for it, and then have
the system restart at the right address when power comes back.

Real hardware can deal with that. Not sure simh does it without some
hacking...

Johnny

>> <mailto:b...@softjar.se>> escreveu:

>> <mailto:pidp-11%2Bunsu...@googlegroups.com>
>> > <mailto:pidp-11+u...@googlegroups.com
>> <mailto:pidp-11%2Bunsu...@googlegroups.com>>.

>> > To view this discussion visit https://groups.google.com/d/msgid/

>> <https://groups.google.com/d/msgid/>
>> > pidp-11/764762ca-55a2-4f38-b2a6-9546f8e711c3n%40googlegroups.com
>> <http://40googlegroups.com>
>> > <https://groups.google.com/d/msgid/pidp-11/764762ca-55a2-4f38-
>> <https://groups.google.com/d/msgid/pidp-11/764762ca-55a2-4f38->
>> > b2a6-9546f8e711c3n%40googlegroups.com?
>> utm_medium=email&utm_source=footer <http://40googlegroups.com/>>.

>>
>> --
>> You received this message because you are subscribed to a topic in
>> the Google Groups "[PiDP-11]" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/

>> topic/pidp-11/AAm6ZUZRpTw/unsubscribe <https://groups.google.com/
>> d/topic/pidp-11/AAm6ZUZRpTw/unsubscribe>.

>> To unsubscribe from this group and all its topics, send an email
>> to pidp-11+u...@googlegroups.com

>> <mailto:pidp-11%2Bunsu...@googlegroups.com>.

>> To view this discussion visit https://groups.google.com/d/msgid/

>> pidp-11/ae713f67-b1d2-4570-9809-c46ba3160ef6%40softjar.se
>> <https://groups.google.com/d/msgid/pidp-11/ae713f67-
>> b1d2-4570-9809-c46ba3160ef6%40softjar.se>.
>>
>> --

>> 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/

>> CA%2BgrvcpxEjSMvBysFaN_GN2M58cSdX1uGA%3D6_LnfAiZF0hEL%3DA%40mail.gmail.com <https://groups.google.com/d/msgid/pidp-11/CA%2BgrvcpxEjSMvBysFaN_GN2M58cSdX1uGA%3D6_LnfAiZF0hEL%3DA%40mail.gmail.com>.
>

--
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

[Dwain Sims]

John:

I agree with you.  Most of my experience was with some various flavor of UNIX on the PDP-11.  The operator was required to put the OS into a shutdown state before you started messing with the key switch.  I will always remember typing "sync" three times to clear all the buffers.

I have not gotten to the point of messing with the key switch on my PiDP-11 yet.  Maybe later

Dwain

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/e63649b4-bb7b-4141-b03d-5634dd737e8c%40softjar.se.

--

Dwain M Sims

+1 919-480-1774

ds...@bayleafnc.org

[Mark Pizzolato - Info Comm]

On Thursday, March 26, 2026 at 3:04 PM, John D Bruner wrote:
> IIRC, there are multiple options for wiring the power switch. One is to run
> the 5V supply through it, so it will directly control the power to the Pi. If
> you don't shut down the Pi first, you risk having unsaved disk content
> that will require salvaging (fsck) upon reboot.
>
> A second option is to configure the Pi (4 or 5) to use a GPIO pin as a power
> signal. That's slightly less disruptive, because Linux does shut down before
> powering off. The Pi hardware should detect a change in the GPIO when
> the keyswitch is turned on again - and reboot.
>
> I don't recall if it is possible to wire the keyswitch in parallel with the ADDR
> SELECT pushbutton so that turning it off would trigger the same behavior
> as pushing ADDR SELECT: based upon the position of the RUN/HALT switch,
> either quit simh (and start a new one after reading the console switches)
> or run "shutdown" to shut down the Pi.
>
> If what you want is a way to shut down the Pi from the PiDP panel, you
> might just want to consider pressing HALT and then ADDR SELECT. 
>
> If the guest (PDP-11 OS) isn't shut down first, then (depending upon the OS)
> you may leave its disk(s) in a corrupted state. Of course, the same is true
> when turning off the keyswitch on a real PDP-11. (The PDP-11 can trap upon
> loss and restoration of line power so that the O/S could save and restore
> volatile state. I've seen it work on 11/45s and 11/70s with magnetic core
> (non-volatile) memory - sometimes. Johnny, I'm curious - does your
> RSX-11M machine handle this successfully?)

Simh can be leveraged to provide saving volatile state independent of the OS
running within the simulator.

Doing this may not fit well with the current Pi setup, but if someone is really
interested it may be possible.

Achieving this counts on the host system shutdown signaling the simh process
which if properly enabled causes the simulator to suspend simulation, the logic
in simh script driving things detects this signal, and it invokes a SAVE command
to save the whole simulator state to a file (i.e. the non-volatile concept). It then
exits.

Upon startup, the driving script detects the presence of the previously SAVEd
state and RESTOREs it and merely continues execution.

What is missed in this process are the clock ticks that would have occurred while
the simulator wasn't running. Some mechanism within the running OS would
need to probe the outside world for the current time of day. NTP mechanisms
might be appropriate for some operating systems.

This concept depends on ALL of the simulated state of EACH simulated device
being properly described in simh REGister structures since these are what is
stored (and subsequently RESTOREd) in the SAVEd file. I haven't tested the
PDP11 simulator to see how thorough that simulator describes all of it's state.

I've been running a VAX (MicroVAX 3900) simulator like this for more than 15
years.

- Mark

[Johnny Billquist]

What you describe is somewhat incompatible with how a real PDP-11 deals
with power loss and recovery.

Device registers and state is not saved. The only thing saved is memory
content (which would either be core memory or battery backed up memory).
At power loss, there should be a specific interrupt for that, which
should allow the CPU to perform for a few milliseconds more. The OS (the
ones that do have the capability to deal with this) will save whatever
additional state is desires into memory, and then stop.
When power returns, the system starts up at the normal vector, at which
point the OS restores things from memory, runs through initialization of
all devices, and resumes execution. There is no way to recover any clock
ticks that happened while power was off, but depending on the system, it
might resync the clock to some external source at that point.

Sounds like simh is not close to what is required here. simhs own
attempt to save, restore, and resume operation might sortof work in some
sense, but it will likely not be a smooth experience, and would probably
not at all be satisfactory from at least my point of view.

Johnny

[Johnny Billquist]

And to just add one more thing to this.

In RSX, any program can register a power recovery AST, which will then
be called if power was lost, and then restored. So any program who cares
can do whatever it might think is necessary in such a situation to
recover, resume or otherwise handle the event.

But all that relies on the machine acting like a real PDP-11 in the
situation. Which simh isn't.

Johnny

[Mark Pizzolato - Info Comm]

You are 100% correct!

What I described was absolutely NOT what the PDP11 did for power loss.
What I described was a way to avoid data/state loss in ANY running simulator when the host system is shutting down. This is completely WITHOUT ANYTHING inside the simulator noticing what happened.

Feel free to implement precisely what you described to that reflects how the hardware worked. When you do that, you will then have to figure out how to magically implement the non-volatile memory when this is happening.

> --
> 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/3ae7565a-b54d-4362-9b1e-1030378507a5%40softjar.se.

[Paulo Rebordão]

Thanks for all the input.

I'm gonna leave it as it is - the key switches power directly to board (and Pi).

Both shutdowns will be made via terminal.

Paulo Rebordão

You received this message because you are subscribed to a topic in the Google Groups "[PiDP-11]" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pidp-11/AAm6ZUZRpTw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pidp-11+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/fa903688b0a444ab883740b6b2c1d858%40infocomm.com.

[Johnny Billquist]

On 27/03/2026 12.41, Mark Pizzolato - Info Comm wrote:
> You are 100% correct!
>
> What I described was absolutely NOT what the PDP11 did for power loss.
> What I described was a way to avoid data/state loss in ANY running simulator when the host system is shutting down. This is completely WITHOUT ANYTHING inside the simulator noticing what happened.

That is not true. Anything interacting/interfacing with the outside
world can potentially be impacted by such an event. You are not
suspending the whole universe.

> Feel free to implement precisely what you described to that reflects how the hardware worked. When you do that, you will then have to figure out how to magically implement the non-volatile memory when this is happening.

In theory, this would be simple. Generate the power fail interrupt.
Allow the simulation to continue for a small while, or until halt. Then
dump memory to a file. At startup, have a way to simulate power on with
retained memory, using such a memory snapshot.
Nothing magic about it at all. Not really that much more complexity than
what you described simh doing now.
But yes, it would still rely in simh getting a signal (such as SIGHUP)
when the system is going down, and simh being allowed to complete some
more processing. But that is fairly standard.

Johnny

[Mark Pizzolato - Info Comm]

On Friday, March 27, 2026 at 5:09 AM, Johnny Billquist wrote:
> On 27/03/2026 12.41, Mark Pizzolato - Info Comm wrote:
> > You are 100% correct!
> >
> > What I described was absolutely NOT what the PDP11 did for power loss.
> > What I described was a way to avoid data/state loss in ANY running
> > simulator when the host system is shutting down. This is completely
> > WITHOUT ANYTHING inside the simulator noticing what happened.
>
> That is not true. Anything interacting/interfacing with the outside world can
> potentially be impacted by such an event. You are not suspending the whole
> universe.

You are certainly correct. Please describe how the original PDP11's power fail
logic would preserve what is happening in the rest of the universe and how that
would be fundamentally different from what would happen to the reset of the
universe with what I described.

> > Feel free to implement precisely what you described to that reflects how
> > the hardware worked. When you do that, you will then have to figure out
> > how to magically implement the non-volatile memory when this is
> > happening.
>
> In theory, this would be simple. Generate the power fail interrupt.
> Allow the simulation to continue for a small while, or until halt. Then dump
> memory to a file. At startup, have a way to simulate power on with retained
> memory, using such a memory snapshot.
> Nothing magic about it at all. Not really that much more complexity than what
> you described simh doing now.
>
> But yes, it would still rely in simh getting a signal (such as SIGHUP) when the
> system is going down, and simh being allowed to complete some more
> processing. But that is fairly standard.

Go ahead and implement what you've described which will certainly require
changes to both the PDP11 simulator code and additional simh capabilities to
get there.

Meanwhile , what I described can be implemented with a simh configuration
script which will work for essentially all existing simulators.

[Johnny Billquist]

On 27/03/2026 14.22, Mark Pizzolato - Info Comm wrote:
> On Friday, March 27, 2026 at 5:09 AM, Johnny Billquist wrote:
>> On 27/03/2026 12.41, Mark Pizzolato - Info Comm wrote:
>>> You are 100% correct!
>>>
>>> What I described was absolutely NOT what the PDP11 did for power loss.
>>> What I described was a way to avoid data/state loss in ANY running
>>> simulator when the host system is shutting down. This is completely
>>> WITHOUT ANYTHING inside the simulator noticing what happened.
>>
>> That is not true. Anything interacting/interfacing with the outside world can
>> potentially be impacted by such an event. You are not suspending the whole
>> universe.
>
> You are certainly correct. Please describe how the original PDP11's power fail
> logic would preserve what is happening in the rest of the universe and how that
> would be fundamentally different from what would happen to the reset of the
> universe with what I described.

Like I said, with RSX, any program can register a power fail AST that
will be called when power is restored (SPRA$ - Specify Power Recovery
AST). Thus all software that requires are explicitly notified about what
have happened, and can take appropriate action, such as closing and
reestablishing external connections, read back possible state from
external sources, resync time, or do whatever else might be the more
appropriate thing to do.

There is no way the OS could know exactly what needs to be done for
individual applications or systems, so it provides functionality that
enables applications to explicitly be aware of, and take action at the
reasonable moment in time.

The same is also true for all device drivers, who have a special entry
point for power fail recovery. Which then obviously should reset,
reconfigure and restart the device, check the queue of requests, and
restart the one that was ongoing at the time of the power fail if any,
and that will allow everything to resume operation.

But all of this requires that the machine acts in the way that a PDP-11
would act on power failure.

>>> Feel free to implement precisely what you described to that reflects how
>>> the hardware worked. When you do that, you will then have to figure out
>>> how to magically implement the non-volatile memory when this is
>>> happening.
>>
>> In theory, this would be simple. Generate the power fail interrupt.
>> Allow the simulation to continue for a small while, or until halt. Then dump
>> memory to a file. At startup, have a way to simulate power on with retained
>> memory, using such a memory snapshot.
>> Nothing magic about it at all. Not really that much more complexity than what
>> you described simh doing now.
>>
>> But yes, it would still rely in simh getting a signal (such as SIGHUP) when the
>> system is going down, and simh being allowed to complete some more
>> processing. But that is fairly standard.
>
> Go ahead and implement what you've described which will certainly require
> changes to both the PDP11 simulator code and additional simh capabilities to
> get there.
>
> Meanwhile , what I described can be implemented with a simh configuration
> script which will work for essentially all existing simulators.

Well. What you described, and what is currently implemented is close to
useless for any actual PDP-11 software.
So what we have today is pretty much nothing.
I could certainly argue that it would make a lot more sense to implement
something in simh that actually behaves the same way as a real machine
(that is, after all, the aim and purpose of simh), but me personally
have enough other projects, and not really a big need for this
functionality, so I will not spend the time on it.

Sometimes I do feel that something have gone pretty far astray, when the
actual behavior of the real machine is no longer considered the absolute
truth on how the emulation should behave. It's sad, but I try to stay
far away from simh development for that reason (among others).

Johnny

[Anton Lavrentiev]

> What you described, and what is currently implemented is close to useless

I'd argue it's useless; it resembles a hibernate state of a
simulation, so it is not even aware that its host OS was shut down and
then restarted.
IDK what would happen to the clocks in the guest OS, though, as I
would guess they would lag behind the wall clock for the duration of
the hibernation.
But the simulation would survive the unexpected power loss, for sure.
Meaning, no file system corruption or any other data loss (such as in
otherwise
unfinished tasks).

> --
> 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/96ad0dbf-8c87-4796-8c3e-c50031f149bd%40softjar.se.

[Johnny Billquist]

I'm also a bit curious about how well simh manage to save and restore
I/O in progress, as simh do delay on I/O, and are pacing operations that
have been requested by the PDP-11.
Is all of that handled, and correctly resumed/completed upon resuming
simh operation? Otherwise there could be more fallout. And it's
certainly not trivial to handle this.

But anyway, that would still leave any PDP-11 software completely
unaware that things might have been suspended for an unknown amount of time.

Johnny

>> To unsubscribe from this group and stop receiving emails from it, sendan email to pidp-11+u...@googlegroups.com.