Potential changes in PiDP-11 / simh / console interaction plus other features - your vote counts!

[terri-...@glaver.org]

As supplied in the current PiDP-11 install, the various operating systems have unfortunate interactions with with both simh and the 'screen' utility:

^E *(Control-E) normally means "Go to end of line" in DEC operating systems, while the emulation supplied with the PiDP-11 uses ^E to escape back to the sim> prompt. At best, this is unexpected by people with "muscle memory" for DEC keystrokes, and at worst it can lead to LAT and DECnet sessions dropping (or VMS CLUEXITs. but that isn't a concern for the PiDP-11 community).

^A (Control-A) is used in many DEC operating systems to toggle command line editing between overstrike and insert modes. The current PiDP-11 software uses the system default for the 'screen' utility, which makes ^A the screen attention character (so ^Ad disconnects your terminal from the currently running emulated OS, which continues running happily), and you can get back with either the 'pdp11' command or just 'screen -d -r'.

These affect the console, regardless of which terminal emulator you are running locally on your PiDP-11. If you interact with the emulated OS via virtual (for example, Telnet) or physical (serial port) connections, you may not have run into these issues. Of course, some operations (like PDP-11 OS startup dialogs) happen only in the local terminal emulator, so it can still be an issue.

I am proposing changing the behavior so that ^P (Control-P) replaces ^E as the simh escape character. This is consistent with the behavior of actual "soft console" PDP-11 systems, including the unloved PDP-11/70 KY11-RE "Serial Console" version.

I am also proposing changing the 'screen' attention character from ^A to ^\ (Control-backslash) which is still convenient, but less likely to trip up people used to DEC command line editing.

Neither of these changes will change the behavior of either simh or screen globally - the escape character will be set in the individual OS boot.ini files, and the screen attention character will be in the default user's .screenrc file.

For screen, I am also proposing enabling the screen scrollback buffer to enable scrollbars and increase the number of lines stored in the buffer. I am currently running with a value of 5000, but that's a bit large, potentially consuming nearly 400KB of Pi host memory. I am proposing a scrollback buffer of 1000 lines (which consumes under 80KB of host RAM) as a reasonable compromise, and which will be configurable via the user's .screenrc file if a different size is desired.

Lastly, I want to include my Raspberry Pi OS 'status' utility (fully described at https://github.com/Terri-Kennedy/RPi-status ) as part of the PiDP-11 installation. Since many PiDP-11 users are running with the back cover on, and often on older Raspberry Pi models which generate more heat for the same emulation speed, I find it useful to see the Pi's temperature, fan speed (if available) and if the Pi has experienced either a thermal or voltage throttling event. You can find a sample display at the link above.

I know we only have a small percentage of the 6500+ PiDP-11 systems represented here, but the people here are likely to be the "power users".

Please do a "reply to sender" (not "reply all", to avoid clogging up this list) and let me know one of "Agree to all", "Disagree with all", or which of these you want and which you don't, if you have mixed views. Voting will close in two weeks, on December 20th at 11:59 PM EST (GMT -5), so vote early (but please, not often!).

What we decide here will eventually make it to Oscar's official PiDP-11 GitHub repo, as he has looked over my changes so far and agreed to all of them. In the meantime, they will only be in my fork (which I hope to have ready for testing early in the new year). Some of you have already tried my new installation script test with favorable reviews. 

[Tony Nicholson]

Apologies for doing a Reply-All - but this change proposal may need some discussion, and I'd like to see what others think.

Changing the screen program escape meta key from ^A to anything else is problematic for me as I use screen for other things on different systems.

To send a ^A through to the program running under screen you use the two character sequence ^A a (i.e. hold down CTRL and press the A key, release the CTRL and type the letter A again).

Changing it to ^\ would clash with my finger muscle memory for C-Kermit's escape character (which I use as a terminal program under macOS to connect via a serial port USB dongle to a terminal server.).  To send ^\ throught I type it twice.

I also note that if I use ssh to connect to the PiDP-11 console session (which also has its own tilde ~ escape meta key) I need to double type the tilde to get it through to the terminal session.  This is all a bit of a PITA - but I'm used to it.

As to other proposed changes - I don't have an issue with changing ^E to ^P or with varying the size of the screen program's scroll buffer.

Tony

[terri-...@glaver.org]

On Sunday, December 7, 2025 at 12:16:34 AM UTC-5 agn...@gmail.com wrote:

Apologies for doing a Reply-All - but this change proposal may need some discussion, and I'd like to see what others think.

That's fine - it will let me explain things a  bit better in cases where that's needed.

 

Changing the screen program escape meta key from ^A to anything else is problematic for me as I use screen for other things on different systems.

This is just a 1-line change to ~/.screenrc. I can configure the installer so if you already have one, even if it's empty, the installer won't change it. So you can just do "touch .screenrc" before installing. If this is a specific proposal item that enough people vote "no" or 'maybe' on, I can make it an additional question in the new (V2) installer.

 

To send a ^A through to the program running under screen you use the two character sequence ^A a (i.e. hold down CTRL and press the A key, release the CTRL and type the letter A again).

Changing it to ^\ would clash with my finger muscle memory for C-Kermit's escape character (which I use as a terminal program under macOS to connect via a serial port USB dongle to a terminal server.).  To send ^\ throught I type it twice.

There's the muscle memory issue of everyone who used PDP-11 operating systems or editors that used the "standard" DEC control characters. I fine myself cursoring (or is that cursing?) to a particular position on a command line, typing ^A which my fingers know will put me into insert mode and then sending another character. Since this is GNU Screen, just about all characters after the screen escape key will do _something_ - I just don't know _what_, other than needing to look it up after-the-fact.

I also note that if I use ssh to connect to the PiDP-11 console session (which also has its own tilde ~ escape meta key) I need to double type the tilde to get it through to the terminal session.  This is all a bit of a PITA - but I'm used to it.

BSD-ish ssh (at a minimum) has the -e command line character to set the escape character to  anything you want, or 'none' if you don't want one at all. The manpage also says that the escape character is only recognized at the "beginning of a line", whatever that means. If it's looking for carriage returns or linefeeds, it makes the session un-escapable if you're in a full-screen editor that uses cursor control, for example.

As to other proposed changes - I don't have an issue with changing ^E to ^P or with varying the size of the screen program's scroll buffer.

Escape characters are one of those things where there are no universally acceptable choices, particularly if an Emacs user wanders into the room. 8-}

And yes, FDC, JD and I went round and round on what the default escape characters should be in C-Kermit, MS-DOS Kermit, and presumably Kermit 95 (although I wasn't involved with that one).

When I was involved in the development of Crosstalk for Windows [development code name Proteus] (that takes me back - 40-odd years) we had a feature where if you were in a character-cell editor, positioning the mouse cursor anywhere on the screen and typing the special sequence (I believe the default was control + right mouse button click) the program would move the emulator's cursor to that spot on the screen if you were in an editor window or a forms-based app like the DEC Online Store. This is a lot harder than it looks: 1) did the cursor keystroke the emulator sent do anything? 2) did it do something useful? 3) how much progress are we making toward where the user wants to go? (a forms-based app might use a single cursor input to move to another field on the form, even if it was more than one line away) 5) did we eventually get where we were trying to go? (some apps would scroll the page "behind your back"). Incredibly complex code that worked surprisingly well. Although I can see why no other terminal emulator attempted it.

Let's keep the private voting going, but feel free to discuss this issue further in the group if needed. 

[Johnny Billquist]

Just a small comment on just one bit in there...

On 2025-12-07 07:02, terri-...@glaver.org wrote:
>
> BSD-ish ssh (at a minimum) has the -e command line character to set the
> escape character to  anything you want, or 'none' if you don't want one
> at all. The manpage also says that the escape character is only
> recognized at the "beginning of a line", whatever that means. If it's
> looking for carriage returns or linefeeds, it makes the session un-
> escapable if you're in a full-screen editor that uses cursor control,
> for example.

The "beginning" of the line is meant in the way that you need to hit ~
right after hitting enter. If you type some other characters, and then
~, you will not break out of ssh. So it has nothing to do with where the
output is at, or where the cursor as such is at.

> Escape characters are one of those things where there are no universally
> acceptable choices, particularly if an Emacs user wanders into the room. 8-}

Waves my hand...

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

[Helium Phoenix]

Please keep in mind that some may be connecting via actual physical serial terminals, and many from that era did not have a backslash key.  I would recommend only using characters that were commonly available on the terminals of the time period.

[Johnny Billquist]

The fact that it's called "control backslash" shouldn't fool you. It's
named that for the simple reason that it's (in ASCII) just the backslash
character minus 64. However, how different terminals generate that
character is a different story, and might not involve a backslash key at
all. I would suspect *very* few terminals would not be able to generate
all control characters. You just need to find out how it's done.

With DEC terminals (atleast from the VT200 and onwards), no matter what
keyboard you have, you can always generate 033-037 via ^3, ^4, ^5, ^6
and ^7.

So the existence or not of a backslash key probably have much less
relevance and impact than you might think.

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/8e9743f7-ecdf-4190-a70d-b7cd0ffb69b3n%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/8e9743f7-ecdf-4190-a70d-
> b7cd0ffb69b3n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[terri-...@glaver.org]

On Tuesday, December 9, 2025 at 5:15:04 PM UTC-5 helium...@gmail.com wrote:

Please keep in mind that some may be connecting via actual physical serial terminals, and many from that era did not have a backslash key.  I would recommend only using characters that were commonly available on the terminals of the time period.

Control-backslash is just where many (but not all) modern terminals put that function.

They're part of ASCII and your terminal or emulator should have a way to generate them

(unless you're on an EBCDIC or Baudot keyboard, in which case you have bigger prob-

lems 8-}

It goes at least as far back as the Teletype Model 33, where they were FS, RS, US, and GS

(<blah> Separator) where they were Control+Shift+letter key.  

I can certainly add "Control-backslash is where this character is normally found, but

might be generated by a different keystroke on some terminals" or something to that

effect to the help description.

And I don't want to "influence the vote", but reception in the majority of replies has

been positive, although there have been some objections (some vociferous), so at

least the .screenrc addition will be an additional option in the V2 installation dialog-

if you want it the old way, just answer "no" to that question during installation. I am

not sure if the same will apply to the SIMH escape character - I still need to address

the comments of some people privately.

[terri-...@glaver.org]

On Tuesday, December 9, 2025 at 5:15:04 PM UTC-5 helium...@gmail.com wrote:

Please keep in mind that some may be connecting via actual physical serial terminals, and many from that era did not have a backslash key.  I would recommend only using characters that were commonly available on the terminals of the time period.

Something I forgot to mention in my reply is that if you are using real serial terminals that

are controlled by the emulated PDP-11 OS, this is a non-issue. Those are managed entire-

ly by the PDP-11 OS - all Raspberry Pi OS and the PiDP-11 do is map the actual serial ports

to emulated serial controllers in the simulated PDP-11. 

[Johnny Billquist]

That depends. You might want to have a serial port actually logging into
the Linux system, and then you use screen to get to the PiDP-11 console
line, at which point, even for your physical terminal, you are
interested in what the attention character for screen is.
And this is potentially something you might want ot set up, in case you
want to also use your terminal to manage the RPi, and you don't want the
whole GUI and desktop environment.
I personally like serial ports, even into the RPi. And if you don't have
a monitor on it, the serial port is the normal way you want to manage it.

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/9e7e59a0-8503-4cf6-800d-26173f8649aen%40googlegroups.com
> <https://groups.google.com/d/msgid/
> pidp-11/9e7e59a0-8503-4cf6-800d-26173f8649aen%40googlegroups.com?

[terri-...@glaver.org]

On Wednesday, December 10, 2025 at 12:27:39 AM UTC-5 b...@softjar.se wrote:

That depends. You might want to have a serial port actually logging into
the Linux system, and then you use screen to get to the PiDP-11 console
line, at which point, even for your physical terminal, you are
interested in what the attention character for screen is.

True. The .screenrc and the SIMH attention characters will both be questions

in the updated V2 installer. That way, hopefully everybody will be happy.

And I think that renders the major points of the voting moot, so thank you all 

for letting me know your opinions.

[Jonathan Harston]

What about Shift-Enter as with Ersatz-11? Ctrl-P would interfer with some of my code just as much as Ctrl-E does.

[Jonathan Harston]

Oh, and Ctrl-\ is SIGQUIT in Unix.

[Johnny Billquist]

Shift-enter is not a character. That's something you can get in some GUI
environments, but things like screen require an ASCII character.

Johnny

On 2025-12-10 16:03, Jonathan Harston wrote:
> What about Shift-Enter as with Ersatz-11? Ctrl-P would interfer with
> some of my code just as much as Ctrl-E does.
>

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

> ff41afc2-e91c-4914-b32d-207bf246260en%40googlegroups.com <https://
> groups.google.com/d/msgid/pidp-11/ff41afc2-e91c-4914-
> b32d-207bf246260en%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Johnny Billquist]

Unless changed, yes... All those characters can be remapped to whatever
in Unix.

Johnny

On 2025-12-10 16:15, Jonathan Harston wrote:
> Oh, and Ctrl-\ is SIGQUIT in Unix.
>

> --
> 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/36b8158a-b2f7-42b9-aeb1-21437e383aabn%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/36b8158a-b2f7-42b9-
> aeb1-21437e383aabn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Johnny Billquist]

Also - not sure how relevant that is...
The fact that various characters can generate signals when the terminal
is in cooked mode isn't something that means much when you're running
some terminal emulation or communications tool, which are basically
running in raw mode anyway, and just pass pretty much everything through
to the remote end. But you do want some way to break out, so at least
one character needs some special meaning, unless you're ok with not
being able to quit the session from within.
Similar to break out characters in ssh, telnet, kermit, and whatever
else you can think of...

Johnny

[John D. Bruner]

It's not about whether SIGQUIT is interpreted by screen, but by whatever is running within the screen session. screen passes the CTL-\ as a character that is interpreted by the target, which may (likely will) be running in cooked mode and will interpret it. The target might be a simh console session on an emulated PDP-11 running UNIX or (if screen is also used for other things) any pseudo terminal session on the Linux host. Certainly SIGQUIT could be mapped to a different escape character on the target (assuming UNIX v7 or later), but in my experience - unlike the interrupt character - the quit character is rarely remapped.

I don't know how widely SIGQUIT is used by others, but I use it quite often to terminate an errant program with a core dump - or sometimes to terminate a program that doesn't respond to SIGINT. It would be a major inconvenience to me for it to be the screen escape character. On the other hand, I don't often use CTL-A, so that escape sequence for screen is rarely an issue for me. The best choice may come down to whether the end user mostly uses DEC OSs or UNIX. Fortunately, as I understand the proposed change, it would be an option rather than an unconditional new default.

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/a2258f6b-8e6f-4881-a84b-ec709755109f%40softjar.se.

[Johnny Billquist]

Uh, well, no.
The target in this case is simh, which in turn is running some PDP-11
OS. So simh also is running in raw mode, and are passing all characters
to the PDP-11 system. Which, if running some Unix, might know what
SIGQUIT is, but if you're running RSX (for example), it have never heard
of the idea SIGQUIT in the first place.

And if you're using screen for something else than the PiDP-11, you can
certainly have a different config for that as well, and use whatever
character you want to grab the attention of screen itself. And what's
running on the other side of screen is in that case also something
completely different, which indeed might care about SIGQUIT. But now
we're far outside the scope of PiDP-11...

Johnny

[Johnny Billquist]

Also - it should be pointed out that in no way would such a remapping
prevent you from sending a ^\, it will just require some additional
keystroke.

Johnny

[Johnny Billquist]

(And dammit, I should think a bit more before I post, so I don't need to
comment myself...)

Another comment - this is of course also true for ^A. So in no sense is
a remapping for screen to get away from ^A a necessity. It's just a
question of convenience. Which might you be using more? ^A or ^\ ?
Personally, me being an Emacs user, I use ^A quite a lot. And as Terri
mentioned, it is also used by DEC OSes for the same purpose (in line
editing, move to the beginning of the line), so if you are used to that,
then ^A might be used quite a lot. There are not that often anyone uses
^\, even though it's in Unix by default generating SIGQUIT.

But like everything - it's a question of tradeoffs (and muscle memory).

Johnny

[John D. Bruner]

Exactly - the target is the console running within the simh simulation. Someone primarily running UNIX in simh will want CTL-\ to generate SIGQUIT and won't want the screen escape to be changed. On the other hand, someone primarily running a DEC OS would welcome the change. As long as it's configurable in a transparent way, both can be happy.

John

> To view this discussion visit https://groups.google.com/d/msgid/pidp-11/0840f2df-b822-4992-976f-26cc27ecce07%40softjar.se.

[Bert Driehuis]

I had the same concern when someone proposed ^\ for screen, but SIGQUIT is probably the signal that is least dangerous if given twice (unlike SIGKILL, which in many cases gets a different response when issued twice), and is also a signal where folks are quite used to giving it twice. And SIGQUIT is never used during regular typing.

Conversely, for folks used to ^A for start-of-line or ^E for end-of-line, hitting screen's or SIMH's escape inadvertently always screws up their typing, and they hit it a lot. Especially for EMACS users...

That said, a quick blurb in the docs about where to change the default would work for me. I have not yet worked out how to change SIMH's escape key.

Bert

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/yGPN3TFajDAq6CzkTXPaA-0ylCRVbP3J4xjdMp3jcccoCSPWY7fhWcuHCyxAuPA3izsXvFvoD4aHsecp8oARPylMyjFyYvWr9AkkgCoX0Ow%3D%40brunerhome.net.

[John D. Bruner]

If EMACS (or line editing in tcsh/ksh) is a consideration, then CTL-P as a simh escape is going to be painful. :-)

Bottom line for me is that there is no ideal solution. As long as these are transparently configurable, people can choose what is best for them.

John

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/CAN0x2A8sEP0g8HqzrfvSYCHHis6baS3L2oBp%3DvMKT2-MF17iuA%40mail.gmail.com.

[Terri Kennedy]

On 2025-12-10 14:39, Bert Driehuis wrote:

> I had the same concern when someone proposed ^\ for screen, but SIGQUIT
> is probably the signal that is least dangerous if given twice (unlike
> SIGKILL, which in many cases gets a different response when issued
> twice), and is also a signal where folks are quite used to giving it
> twice. And SIGQUIT is never used during regular typing.
>
> Conversely, for folks used to ^A for start-of-line or ^E for
> end-of-line, hitting screen's or SIMH's escape inadvertently always
> screws up their typing, and they hit it a lot. Especially for EMACS
> users...
>
> That said, a quick blurb in the docs about where to change the default
> would work for me. I have not yet worked out how to change SIMH's
> escape key.

Just being brief, as I had to poke a hole in the secure place
I'm working today.

As they say in court, "asked and answered". During install,
users will get separate questions for the SIMH escape character
and if they want screen to use ^A or ^\.

And users are free to customize however they want.

For the simh case - in the boot.ini file of the system(s)
you use, to change the default you simply add:

; Use ^P for SIMH escape (more traditional DEC, un-break line editing)
set console wru=20

For ecreen, edit ~/.screenrc (creating it if necessary)
and add:

escape ^\\

or whatever your favorite character is.

Both of the above show the "new characters", which as
I said will be completely optional. If you prefer the old
way, just say no to the two questions in the installer.

[Johnny Billquist]

On 2025-12-10 20:51, 'John D. Bruner' via [PiDP-11] wrote:
> If EMACS (or line editing in tcsh/ksh) is a consideration, then CTL-P as
> a simh escape is going to be painful. :-)

Oh yes. It certainly is. And it was a pain when I was sitting at the
actual console of a VAX-8650 as well. :-P

But since I don't use the console extensively, I can live with whatever.
But I also know how to change it to something else. My standard key to
break out into simh is ^_, and I'll continue to set that up wherever I
use any system. So in a sense, these discussions are irrelevant to me
personally. I know how to configure everything on my own, and I'll not
be relying on what any installation script does anyway.

> Bottom line for me is that there is no ideal solution. As long as these
> are transparently configurable, people can choose what is best for them.

Agreed.

Johnny

[Jonathan Harston]

softjar.se wrote:

Unless changed, yes... All those characters can be remapped to whatever
in Unix.

Not in Unix 7 and earlier, where they are hardwaired.

[Jonathan Harston]

As people have said: as long as it's configurtable.
I sat down and created a comprehensive configureation file
for Ersatz11* to get the keyboard working as I wanted it, it
would just be the same process for SHIM.

*tho' I still can't work out how to specify that key in the top left
corner, to the left of 1 and above TAB, in the DEFINE KEYPRESS
commands. :(

[Johnny Billquist]

True. But there were also fewer characters defined for signals back
then, and fewer signals as well, I believe. And if you go back a bit
further (not sure where V7 stands here), characters defined for various
things were also quite different. Like '#' used for delete...

Johnny