Tektronix on the standard PiDP11 2.11BSD distribution

[Andrew Barron]

Hi, here is another dumb question. I'm stuck again! I am obviously missing a vital and easy stage.

1. My PiDP11 has a Tektronix icon on the GUI, but it refuses to start. It just flashes up and disappears. I usually run the operator's console screen via SSH. I understand that will not display the Tek images, but I cant get the Tek display to stand up.

2. I found a logon called tektronix and from there I found many plt files and some compiled C files  in the /home/tektronix subfolders. Now I know that they are there I can also get to them via root. 

3. I have checked out the excellent docs listed below, but they seem to be mostly about installing the software on Linus, Mac or Windows, systems directly or via Telnet etc. As far as I know everything is already installed on my PiDP11 system, but it does not accept tek4010 as a command and the Tek screen will not open.

https://github.com/rricharz/pidp11-2.11bsd/blob/master/Tek.pdf

https://github.com/rricharz/pidp11-2.11bsd/blob/master/Tek.odt

 Tek4010 terminal emulator for Linux/X: https://github.com/rricharz/Tek4010

 Other useful tools and guides for 2.11BSD: https://github.com/rricharz/pidp11-2.11bsd

[Johnny Billquist]

On 2026-01-08 09:02, Andrew Barron wrote:
> Hi, here is another dumb question. I'm stuck again! I am obviously
> missing a vital and easy stage.
>
> 1. My PiDP11 has a Tektronix icon on the GUI, but it refuses to start.
> It just flashes up and disappears. I usually run the operator's console
> screen via SSH. I understand that will not display the Tek images, but I
> cant get the Tek display to stand up.

You might very well be able to display graphics using the operators
console. It all depends on what terminal emulator you are using.
With Xterm, it contains both a VT100 and a Tek4014 emulator, and you
actually have two windows. So you can do Tek stuff just fine.
With other terminal emulators you'll have to investigate if they can.
But you have to remember that all graphics on a Tek are just done
through a serial line in the end. There is no other fancy hardware involved.

As for why your Tektronix program/icon behaves they way it does - I have
no idea. Never used any of the RPi GUI stuff.

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]

The terminal emulators were not re-coded to deal with the change from invoking the PiDP-11 startup directly vs. attaching to an existing session via 'screen'. In particular, the Tek emulator does not act as a controlling terminal by default.

If you open another (Raspberry Pi) terminal window and enter the following horrible hack exactly as shown, you'll get something that kinda sorta works:

/opt/pidp11/bin/tek4010 -fast script > /dev/null

and then (in the Tek window) type:

screen -d -r

Your console will now be on the Tek (which will rapidly turn into a collection of illuminated pixels which you can't make sense of). You can do:

/opt/pidp11/bin/tek4010 -autoClear -fast script > /dev/null

and then repeat (in the Tek window):

screen -d -r

which will at least clear the Tek screen when you try to scroll off the page.

 I will be looking at these at some future point after the new installer and new options are finished and working.

[Andrew Barron]

Thanks Terri & Johnny. 

The horrible hack does start a 4010 window, but it wont display vector graphics. I just get blocks of text so I guess it is not going into graphics mode. I tried running the C files, cat on the plt files and running demo.sh

I had no luck with xterm, it comes up with font errors if I start it with xterm- t.  I guess it needs changes to the config.

I will wait until the issues have been sorted out and try again then.

cheers'

AndrewB

[terri-...@glaver.org]

On Friday, January 9, 2026 at 5:21:11 PM UTC-5 zl...@outlook.co.nz wrote:

Thanks Terri & Johnny. 

The horrible hack does start a 4010 window, but it wont display vector graphics. I just get blocks of text so I guess it is not going into graphics mode. I tried running the C files, cat on the plt files and running demo.sh

I didn't think the Unix console was 8-bit-clean, which may well be a requirement.

Grab some of the .plt files, do the hack to gt the Tek to come up. but instead of

using screen to attach it to the PiDP-11, just cat the files from the Raspberry Pi

OS and see if they display.

[Johnny Billquist]

On 2026-01-10 02:20, terri-...@glaver.org wrote:
> On Friday, January 9, 2026 at 5:21:11 PM UTC-5 zl...@outlook.co.nz wrote:
>
> Thanks Terri & Johnny.
> The horrible hack does start a 4010 window, but it wont display
> vector graphics. I just get blocks of text so I guess it is not
> going into graphics mode. I tried running the C files, cat on the
> plt files and running demo.sh
>
>
> I didn't think the Unix console was 8-bit-clean, which may well be a
> requirement.

If they are on a reasonably updated 2.11BSD, the console can be 8-bit
clean. But you do need to do "stty pass8".

[Andrew Barron]

Maybe I am getting closer? I copied some plt files into the Raspberry Pi and I can use a Linux CAT command to display those successfully in the Tektronix emulator window. If I issue screen -d -r command I can login to 211BSD, but then the emulator refuses to show graphics. It just displays chunks of text characters.

cheers

AndrewB

[Johnny Billquist]

One thing sometimes forgotten is that simh by default strips the console
to 7 bits as well. You need to tell simh to not do that.

Check the help...

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/32c69000-c125-4a03-9537-c79c0254e80an%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/32c69000-c125-4a03-9537-
> c79c0254e80an%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Charles Ess]

After following updating my installation to run on Bookworm, I needed to go back to some suggestions from the venerable Flavio from last year in order to get the Tektronix terminal to open up properly. It now does so - but  only by way of leading to a different problem, at least as running on a Pi4b.

First, the boot.ini file needs to include:

; DZ11 8-line mux

set dz enabled

set dz lines=8

set dz 8b

; create telnet-accessible ports 4000..4007 for DZ lines 0..7

attach dz 4000

(I had mixed up some of this in previous efforts - finally successful - to get 211BSD to play nicely with a serial port emulator, using Flavio's: ATTACH dz 4003,LINE=0,CONNECT=SER1;9600-8N1   )

Second: to get the tek terminal to communicate successfully, I added this line as suggested by Flavio to the tek.desktop file that opens the window:

Exec=-/opt/pidp11/bin/tek4010 -autoClear -b9600 telnet 127.0.0.1 4003

Yes, the tek window opens up and (eventually) shows a login prompt that works - but only _very_ slowly.  Trying to get some of the demonstration programs in /home/tektronix/tek to run (e.g., ./mathdemo2) also goes much slower - and kicks up the CPU usage to close to 100%, which starts to choke down everything.

Following some of ChatGPT SWAGs, I've check on, e.g., hardware acceleration on? check. But I've now reached the point where I suspect human wisdom and experience will be far more helpful.

Many thanks in advance - c.

[Johnny Billquist]

First of all, I wonder why everyone is so insistent on going through
emulated serial ports. It is slower, cause more load, and in addition
you have a thing in simh where it actually tries to make the emulated
serial ports actually behave like they were running at the speed they
supposedly emulate. If you want things to fun "fast", this is not the
way to go (although if you're playing locally, it might be needed, so
I'm not saying it might not be right here).

Second, on the comment about telnet-accessible ports. You would normally
not try to setup a different tcp port for each serial port. While
doable, the syntax for that is more convoluted. But the normal is that
there is just the port you specified, and it's actually use for all the
serial ports.


But, to try and make some guess on the actual question here - I don't
know what your problem is. But cpu hitting 100% when you're running the
Tek emulation would suggest that it's the Tek emulator that have some
problem, and I don't know a single thing about that bit. And this (I
guess) also implies you are running with some GUI on your RPi, so this
could also be related to anything and everything around that bit.

But I also do notice that the Tek emulator then takes a program to run,
which is done inside/under the Tek emulator. I was told by others that
this isn't how the Tek emulator works, so now I'm a bit confused about
the whole thing...

Could someone point me to some documentation for this Tek emulator?

Johnny

> <https://groups.google.com/d/msgid/>
> > pidp-11/32c69000-c125-4a03-9537-c79c0254e80an%40googlegroups.com
> <http://40googlegroups.com>
> > <https://groups.google.com/d/msgid/pidp-11/32c69000-
> c125-4a03-9537- <https://groups.google.com/d/msgid/pidp-11/32c69000-
> c125-4a03-9537->
> > c79c0254e80an%40googlegroups.com?
> utm_medium=email&utm_source=footer <http://40googlegroups.com?

> utm_medium=email&utm_source=footer>>.
>
> --
> 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
>

> --
> 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/3a23021f-3e23-405e-ad34-3a24cb1b2352n%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/3a23021f-3e23-405e-
> ad34-3a24cb1b2352n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[terri-...@glaver.org]

On Saturday, February 14, 2026 at 8:03:39 AM UTC-5 charl...@gmail.com wrote:

Following some of ChatGPT SWAGs, I've check on, e.g., hardware acceleration on? check. But I've now reached the point where I suspect human wisdom and experience will be far more helpful.

Many thanks in advance - c.

First, please realize that the terminal emulators as they are are horribly broken. They might have worked

before the new-style pdpcontrol management was added (or not) or their developers might have changed

them in ways that broke their use with the PiDP-11.

In your case, the speed issue is because you need to specify -fast on the tek4010 command line. You

will also be limited by simh's attempts to limit virtual serial port speed, and graphics will not work if the

whole daisy-chain of strung-together bits is not 8-bit clean. But at least you won't be chewing through 100%

CPU (in the display manager*, which slows everything to a crawl).

* The tek4010 emulator is continually polling for events - essentially asking the display manager "Are we

there yet?" as fast as it can - thousands of times a second.

[terri-...@glaver.org]

On Saturday, February 14, 2026 at 8:50:09 AM UTC-5 b...@softjar.se wrote:

Second, on the comment about telnet-accessible ports. You would normally
not try to setup a different tcp port for each serial port. While
doable, the syntax for that is more convoluted. But the normal is that
there is just the port you specified, and it's actually use for all the
serial ports.

I have a sort-of-related question. I allocate the first four DHU ports to

physical serial devices:

; Set up the USB-to-serial ports on the RPi
set vh lines=16
set vh dhu
set vh nomodem
set vh enable
;
; Note that these are "shuffled" so the cabling matches the panel
attach vh line=0,connect=/dev/ttyUSB0
attach vh line=1,connect=/dev/ttyUSB1
attach vh line=2,connect=/dev/ttyUSB3
attach vh line=3,connect=/dev/ttyUSB2

Is there then a way to have the remaining 12 ports accessible via

Telnet (this doesn't have to be on the frozen version of simh that the

PiDP-11 uses - current simh or Open-simh answers are fine, too)? 

Could someone point me to some documentation for this Tek emulator? 

Sure:  https://github.com/rricharz/Tek4010

Note that the current maintainer is looking for someone to take over

ownership / maintainership of the project. We all lowered our hands

and yelled "Not me!".

This points to another issue which will be addressed in my fork - credit

to and links to the original GitHub repos for the Tek and VT52 emulatora.

The 'Teletype' (KSR33) emulator (sty) came from either Oscar or one of

his contributors, but the build script is missing from the PiDP-11 kit.

If anyone really wants to build sty, I'll post the needed bits, but beware

that it is ugly. 

I also have someone working on a VT420 emulator (I know, too new)

but this one runs the actual VT420 firmware under an emulator. It's too

soon to announce anything for testing, though.

[Mark Pizzolato - Info Comm]

> > ; Set up the USB-to-serial ports on the RPi
> > set vh lines=16
> > set vh dhu
> > set vh nomodem
> > set vh enable
> > ;
> > ; Note that these are "shuffled" so the cabling matches the panel
> > attach vh line=0,connect=/dev/ttyUSB0
> > attach vh line=1,connect=/dev/ttyUSB1
> > attach vh line=2,connect=/dev/ttyUSB3
> > attach vh line=3,connect=/dev/ttyUSB2>

> Is there then a way to have the remaining 12 ports accessible via

> Telnet (this doesn't have to be on the frozen version of simh that the

> PiDP-11 uses - current simh or Open-simh answers are fine, too)? 

 

If you enter SHOW VH, you should see an attach string which mentions ALL of the above attach commands.

If you start your attach commands with

 

   attach vh 7676

 

(7676 or whatever tcp port you want telnet sessions to use) followed by the above additional attach commands you should get what you’re asking for.  SHOW VH should confirm what is in effect.

 

 

• Mark

 

[Johnny Billquist]

On 2026-02-14 19:07, terri-...@glaver.org wrote:
> On Saturday, February 14, 2026 at 8:50:09 AM UTC-5 b...@softjar.se wrote:
>
> Second, on the comment about telnet-accessible ports. You would
> normally
> not try to setup a different tcp port for each serial port. While
> doable, the syntax for that is more convoluted. But the normal is that
> there is just the port you specified, and it's actually use for allthe
> serial ports.
>
>
> I have a sort-of-related question. I allocate the first four DHU ports to
> physical serial devices:
>
> ; Set up the USB-to-serial ports on the RPi
> set vh lines=16
> set vh dhu
> set vh nomodem
> set vh enable
> ;
> ; Note that these are "shuffled" so the cabling matches the panel
> attach vh line=0,connect=/dev/ttyUSB0
> attach vh line=1,connect=/dev/ttyUSB1
> attach vh line=2,connect=/dev/ttyUSB3
> attach vh line=3,connect=/dev/ttyUSB2
>
> Is there then a way to have the remaining 12 ports accessible via
> Telnet (this doesn't have to be on the frozen version of simh that the
> PiDP-11 uses - current simh or Open-simh answers are fine, too)?

Mark answered this one already. Basically, start with the generic setup,
and then change it on those ports you want something else.

> Could someone point me to some documentation for this Tek emulator?
>
>
> Sure:  https://github.com/rricharz/Tek4010

Thanks. That was helpful. Now I see why it's consuming so much CPU, and
the idea behind the -fast switch.

But it also means this is easy to hook up to the PiDP-11, or any other
system, or anywhere else. Just run "screen" as the command, or start
your shell, or telnet somewhere, or even use ssh (the README.md file
really suggest some confusion on the part of the author). Running ssh is
no different than running telnet, except of course, whatever machine you
connect to also need to have an ssh server, which probably almost no old
system have...

Although in general I wouldn't recommend using a Tektronix terminal for
text processing. It's not very nice...

So it's no different in this sense than any other terminal emulator. The
big thing is just how accurately it tries to emulate storage screens,
which takes a lot of processing power.

[terri-...@glaver.org]

If you enter SHOW VH, you should see an attach string which mentions ALL of the above attach commands.

If you start your attach commands with

   attach vh 7676 

(7676 or whatever tcp port you want telnet sessions to use) followed by the above additional attach commands you should get what you’re asking for.  SHOW VH should confirm what is in effect.

That works, but I'm still confused about the interaction of 

set vh [no]modem

and the operating system's terminal settings of /[no]dialup (or whatever the particular PDP-11 OS uses

to tell it whether a port has a modem attached or not).

What I would like is to have the host operating system (RSTS/E V10.1 in my case) consider the four attached

physical serial ports as local (pins 2, 3, and 7) devices and the remaining 12 ports as dialup.

My expectation would be that with set vh modem and the telnet ports set to dialup, that when I

logged out of the emulated OS terminal, the telnet connection would drop. Instead, it just sits

there, unresponsive to any input, until I manually do a ^] to get back to the telnet prompt and say 

quit.

Can you tell me what I'm missing?

Relevant pieces of config files and command output:

simh config:

;

; Set up the USB-to-serial ports on the RPi
set vh lines=16
set vh dhu

set vh modem
set vh enable
; Use Telnet port 4000 for non-physical ports
attach vh 4000

;
; Note that these are "shuffled" so the cabling matches the panel
attach vh line=0,connect=/dev/ttyUSB0
attach vh line=1,connect=/dev/ttyUSB1
attach vh line=2,connect=/dev/ttyUSB3
attach vh line=3,connect=/dev/ttyUSB2

sim> sh vh
VH      address=17760440-17760457*, vector=300-304*, BR4, lines=16
        attached to 4000,Line=0,Connect=/dev/ttyUSB0,Line=1,Connect=/dev/ttyUSB1,Line=2,Connect=/dev/ttyUSB3,Line=3,Connect=/dev/ttyUSB2, DHU mode, Modem
        4 current connections

RSTS/E START.COM:

set terminal kbh0:/permanent/noautobaud/nodialup/speed=9600/device_type=VT320
set terminal kbh1:/permanent/noautobaud/nodialup/speed=9600/device_type=VT320
set terminal kbh2:/permanent/noautobaud/nodialup/speed=9600/device_type=VT320
set terminal kbh3:/permanent/noautobaud/nodialup/speed=9600/device_type=VT320
set terminal kbh4:/permanent/noautobaud/dialup/speed=19200
set terminal kbh5:/permanent/noautobaud/dialup/speed=19200
set terminal kbh6:/permanent/noautobaud/dialup/speed=19200
set terminal kbh7:/permanent/noautobaud/dialup/speed=19200
set terminal kbh8:/permanent/noautobaud/dialup/speed=19200
set terminal kbh9:/permanent/noautobaud/dialup/speed=19200
set terminal kbh10:/permanent/noautobaud/dialup/speed=19200
set terminal kbh11:/permanent/noautobaud/dialup/speed=19200
set terminal kbh12:/permanent/noautobaud/dialup/speed=19200
set terminal kbh13:/permanent/noautobaud/dialup/speed=19200
set terminal kbh14:/permanent/noautobaud/dialup/speed=19200
set terminal kbh15:/permanent/noautobaud/dialup/speed=19200

RSTS/E 'finger' output:

Job Username       PPN   Progrm Term   Login  CPU  ST Location         TTType  
 7  TERRY         20,254 DCL    KB21:  15:07 00:02 ^C PiDP-11 Telnet   VT320  
 8  TERRY         20,254 FINGER KB0:   15:09 00:05 RN Virtual PiDP-11  VT100  
 9  TERRY         20,254 DCL    KB17:  15:13 00:02 ^C PiDP-11 Back #0  VT420   

KB0: is the system console (in the PiDP-11 'screen' window). The vh/DHU lines are KBH0: through KBH15:

or (when used without the device specifier letter) KB17: through KB32:. The above 'finger' output shows

me logged in on KB0: (PiDP-11 console), KB17: (first of four physical vh/DHU serial ports) and KB21: (the

first telnet 'serial port').

Thanks!

[Johnny Billquist]

On 2026-02-14 21:28, terri-...@glaver.org wrote:
>
> If you enter SHOW VH, you should see an attach string which mentions

> ALL of the above attach commands.____

>
> If you start your attach commands with
>
>    attach vh 7676
>
> (7676 or whatever tcp port you want telnet sessions to use) followed
> by the above additional attach commands you should get what you’re
> asking for.  SHOW VH should confirm what is in effect.
>
>
> That works, but I'm still confused about the interaction of
>
> set vh [no]modem
>
> and the operating system's terminal settings of /[no]dialup (or whatever
> the particular PDP-11 OS uses
> to tell it whether a port has a modem attached or not).

Terri, try adding "-am" as a switch to the attach for the terminals in
the simh ini file.

Basically:

attach -am vh 4000

[terri-...@glaver.org]

On Saturday, February 14, 2026 at 2:41:23 PM UTC-5 b...@softjar.se wrote:

Thanks. That was helpful. Now I see why it's consuming so much CPU, and
the idea behind the -fast switch.

The human eye can't really notice things changing at 24 frames per second or

more (as movies have proven). Higher refresh rates are useful in gaming and

other limited situations, but 120fps is an extreme upper limit.

The Tek emulator is doing thousands of calls per second (without -fast) to the

display server. If it limited itself to 120, it would be impossible to see a differ-

ence. Instead it assumes it is running on a high-end x86 system and just runs

flat-out.

We've discussed this previously in the context (no pun intended) of the behav-

ior of simh's throttling. If it just throttled on every emulated clock tick (50 or

60Hz for the LTC) the output would be a lot less bursty than "run flat-out for a

bit, then stop everything, then repeat" that I'm seeing now (running a program

that does some needless compute, displays a line of text, and repeats forever

displays a sequence of fast text output, then a delay, then more fast text out-

put, and so on).

But it also means this is easy to hook up to the PiDP-11, or any other
system, or anywhere else. Just run "screen" as the command, or start
your shell, or telnet somewhere, or even use ssh (the README.md file
really suggest some confusion on the part of the author). Running ssh is
no different than running telnet, except of course, whatever machine you
connect to also need to have an ssh server, which probably almost no old
system have...

I'd love to see a working desktop shortcut entry that doesn't involve immense-

ly convoluted (and just plain sick 8-) logic. It is likely easier to do for a non-

system-console session (but then you're going over an unnecessary Telnet

connection when a named pipe would be much cleaner).

Right now the default desktop entry for the Tek is:

/opt/pidp11/bin/tek4010 bash pdp11

Which flat-out doesn't work. You get a window that briefly appears and auto-

closes before you can read what it is saying, which is:

tek4010 version 1.9
Screen dimensions: 1920 x 1080
Window dimensions: 922 x 702
Scaling: 0.225
Process has been terminated

It also has the issue that it creates a non-interactive session by default, so

there's no shell to process the 'screen' command to attach it to the PiDP-11

console session.

Remember what I said about sick logic? Try this, which will get you a shell 

session through the magic of 'script', which creates a subordinate interactive

session:

./tek4010 -fast -autoClear script -q /dev/null > /dev/null

In there, you can then say:

screen -d -r

to 'grab' the console session.

Although in general I wouldn't recommend using a Tektronix terminal for
text processing. It's not very nice...

But as you point out, you don't want a Tek as the console.

So for the moment you're forced to go through a telnet session and deal

with potential non-8-bit-clean paths,  when a named pipe to an emulated

serial port would be much better, and then it could be operated as the

peripheral it is intended to be used as. But 'if wishes were horses'...

The VT52 emulator is broken in a completely different way - you don't

even see a window form, since it thinks there are no displays on the sys-

tem:

terry@spcpi2-host:~ $ /opt/pidp11/bin/vt52 bash pdp11
SDL_CreateWindowAndRenderer() failed: No available displays

When indeed there are many displays (including the one we're trying to

use):

terry@spcpi2-host:~ $ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
HDMI-1 disconnected primary (normal left inverted right x axis y axis)
HDMI-2 disconnected (normal left inverted right x axis y axis)

This happens under both X11 and Wayland.

sty has its own 'burn 100% of the CPU's cycles' bug, but at least it "works".
 

Since there hasn't been a lot of complaining here about the terminal emulators being

broken, my development plans / version milestones are:

V2: New installer, new/updated  guest operating systems, new documentation. Add

       an expert mode that bypasses all of the configuration checks and prints a "You

       break it, you bought it" for people who want to try to install this on WSL and other

      strange places.

V3: Use a current build of Open-SIMH + modified REALCONs from John Bruner

       (this may require a Pi faster than a Pi 3 due to using the official Pi GPIO library

       rather than twiddling the bits directly - it is unfortunate that memory price in-

       creases have caused the prices on newer Pis to skyrocket). Also include a no-

       PiDP-11 installation option for people who just want Open-SIMH and the collec-

       tion of operating systems and documentation from the V2 kit.

V4: Fix / replace / add terminal emulators.

 

[terri-...@glaver.org]

On Saturday, February 14, 2026 at 3:57:31 PM UTC-5 b...@softjar.se wrote:

Terri, try adding "-am" as a switch to the attach for the terminals in
the simh ini file.

Basically:

attach -am vh 4000

That was accepted, but doesn't seem to make any difference - the telnet session

is dead after logout until you ^] and quit.

boot.ini-81> attach -am vh 4000

Is it possible that this is in a newer simh version (although in that case I would

expect it to throw an error message on the attach)?

[Johnny Billquist]

Not sure how new -am is. But I can tell you that without it, sessions
don't get disconnected when the PDP-11 side drops the virtual DTR.

Actually, we're talking about two switches. And to quote the simh help
on the dz:


"The terminal lines perform input and output through Telnet sessions
connected
to a user-specified port. The ATTACH command specifies the port to be used:

sim> ATTACH {-am} DZ {interface:}port set up listening port

where port is a decimal number between 1 and 65535 that is not being
used for
other TCP/IP activities. The optional switch -m turns on the DZV11's modem
controls; the optional switch -a turns on active disconnects (disconnect
session if computer clears Data Terminal Ready). "


You probably do want both for lines that are supposed to be remote.

And I just read through docs again. Apparently -am is only used the dz.
For DH, you instead have:

"Modem and auto-disconnect support may be set on an individual controller
basis. The SET MODEM command directs the controller to report modem status
changes to the computer. The SET HANGUP command turns on active disconnects
(disconnect session if computer clears Data Terminal Ready).

sim> SET VHn [NO]MODEM disable/enable modem control
sim> SET VHn [NO]HANGUP disable/enable disconnect on DTR drop
"

Why on earth the commands/flags differ between dz and dh is beyond me.
But see if that helps?

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/
> b761a4d5-d892-42d0-a8b2-c78b0913fdf1n%40googlegroups.com <https://
> groups.google.com/d/msgid/pidp-11/b761a4d5-d892-42d0-a8b2-
> c78b0913fdf1n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Johnny Billquist]

On 2026-02-14 22:03, terri-...@glaver.org wrote:
> On Saturday, February 14, 2026 at 2:41:23 PM UTC-5 b...@softjar.se wrote:
>
> Thanks. That was helpful. Now I see why it's consuming so much CPU,and
> the idea behind the -fast switch.
>
>
> The human eye can't really notice things changing at 24 frames per second or
> more (as movies have proven). Higher refresh rates are useful in gamingand
> other limited situations, but 120fps is an extreme upper limit.
>
> The Tek emulator is doing thousands of calls per second (without -fast)
> to the
> display server. If it limited itself to 120, it would be impossible to
> see a differ-
> ence. Instead it assumes it is running on a high-end x86 system and just
> runs
> flat-out.

Oh. Totally agree. This is just silly.

And I also downloaded and built tek4010 on my local machine just now, to
see a bit more what it is doing. And first of all, of all wonders, it
also tries to emulate the speed of serial ports. Which will work wonders
in combination with simh also trying to play that game.

But I also see what the main problem is. The code does the whole thing
wrong about how to create a subprocess and run commands. Instead of just
opening a pty and act like any normal program does, it creates pipes to
play/pretend it's a terminal. And shells, and some other programs, do
not want to play nicely with this. They expect there to be a controlling
terminal. This wouldn't be so hard to fix, but yecch!
ssh also don't like that there isn't a proper controlling terminal,
while telnet and rsh actually are stupid enough that it don't matter.
For any other program, it's the same problem/story.

So now I see what the actual problem is with this program.
For anyone who would want to fix this, it's two bits to it. One is to
just make the updating of the screen at a reasonable speed/interval, and
the other is to just open a pty instead of the crazy pipes the program
plays with.

> But it also means this is easy to hook up to the PiDP-11, or any other
> system, or anywhere else. Just run "screen" as the command, or start
> your shell, or telnet somewhere, or even use ssh (the README.md file
> really suggest some confusion on the part of the author). Running
> ssh is
> no different than running telnet, except of course, whatever machine
> you
> connect to also need to have an ssh server, which probably almost no
> old
> system have...
>
>
> I'd love to see a working desktop shortcut entry that doesn't involve
> immense-
> ly convoluted (and just plain sick 8-) logic. It is likely easier to do
> for a non-
> system-console session (but then you're going over an unnecessary Telnet
> connection when a named pipe would be much cleaner).

No pipes should be involved. The problem is exactly that a named pipe
(or two actually) are involved. The program should really just have
created a pty/tty pair, and used that for all interactions, and things
would just have worked.
Possibly also the lack of setting up stderr is a part of the problem. I
get the feeling whoever wrote that bit of code had no actual idea of how
it should be done, and just grabbed the first thing he could
find/invent/google, using all the wrong terms.

And yeah, unless that is fixed, this thing is just broken.

screen just gives a very predictable error: "Must be connected to a
terminal". Which is exactly what one could expect here.

> Right now the default desktop entry for the Tek is:
>
> /opt/pidp11/bin/tek4010 bash pdp11
>
> Which flat-out doesn't work. You get a window that briefly appears and auto-
> closes before you can read what it is saying, which is:

Yeah... You could add -noexit, and you'll have time to read what it
says. But no matter. It is broken. Not in a way I could ever have
dreamed of. :-(

> Although in general I wouldn't recommend using a Tektronix terminalfor
> text processing. It's not very nice...
>
>
> But as you point out, you don't want a Tek as the console.

Definitely not. :-)

> The VT52 emulator is broken in a completely different way - you don't
> even see a window form, since it thinks there are no displays on the sys-
> tem:
>
> terry@spcpi2-host:~ $ /opt/pidp11/bin/vt52 bash pdp11
> SDL_CreateWindowAndRenderer() failed: No available displays

Do I even want to look at that one and see which way that one managed to
not do things right after I've seen tek4010?

[Anton Lavrentiev]

> The tek4010 emulator is continually polling for events - essentially asking the display manager "Are we there yet?" as fast as it can - thousands of times a second.

That's a very questionable design, if you ask me... Why would anybody do that?

> --
> 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/0119288e-fc67-463b-bb60-b5e9589b66a6n%40googlegroups.com.

[terri-...@glaver.org]

On Saturday, February 14, 2026 at 4:34:04 PM UTC-5 b...@softjar.se wrote:

And I just read through docs again. Apparently -am is only used the dz. 
 

Why on earth the commands/flags differ between dz and dh is beyond me.

But see if that helps? 

And why does it accept a flag on an interface that doesn't use them?

But this appears to have the desired result. I say "appears" because I'm not

in the same room as the PIDP-11 with the hardwired VT420.

However, this reveals some new and exciting borkage in Open-SIMH which 

apparently isn't in the old version of SIMH+REALCONS that the PiDP-11 uses.

On the PiDP-11:

Telnet sessIon:
$ bye
Saved all disk files on SY: 3728 blocks in use
Job 8 User 20,254 logged off KB17: at 14-Feb-26 06:06 PM
1 other user still logged in under this account
System RSTS V10.1-L RSTS/E V10.1
Run time was 1 second
Elapsed time was 0 minutes
Good evening

Line hangup
Connection closed by foreign host.
(1:111) gate:~terry# 

Console output:

>>>>>>>>>>>>>>>  OMS V10.1-A  14-Feb-26 06:06 PM  <<<<<<<<<<<<<<<
Message 8 from LOGOUT, user [0,0] on _KB17:, job 8
        LOGOUT terminating [20,254] on dial-up line KB17:

On a Pi with Open-SIMH:

$ bye
Saved all disk files on SY: 3808 blocks in use
Job 7 User 20,254 logged off KB17: at 14-Feb-26 06:13 PM
System RSTS V10.1-L SPC11D - 11/70
Run time was 0 seconds
Elapsed time was 1 minute
Good evening

Line hangup

Disconnected from the PDPConnection closed by foreign host.

Console output:

>>>>>>>>>>>>>>>  OMS V10.1-A  14-Feb-26 06:13 PM  <<<<<<<<<<<<<<<
Message 12 from LOGOUT, user [0,0] on _KB17:, job 7
    LOGOUT terminating [20,254] on dial-up line KB17:
Sockets: read error 9 - Bad file descriptor

The Open-SIMH version adds a nice "Disconnected from the PDP" after

the "Line hangup" message, but appears to forget the CR/LF so the Telnet

session closed message comes out on the same line.

It is also generating a spurious:

Sockets: read error 9 - Bad file descriptor

error message (which is coming from Open-SIMH and not the emulated

PDP-11 operating system).

I don't know if these defects are present in recent SIMH or new in Open-

SIMH and frankly don't want to investigate it. If someone on better terms

with the current [Open-]SIMH projects wants to run with it, that'd be great.

[terri-...@glaver.org]

On Saturday, February 14, 2026 at 5:07:32 PM UTC-5 b...@softjar.se wrote:

And I also downloaded and built tek4010 on my local machine just now, to
see a bit more what it is doing. And first of all, of all wonders, it
also tries to emulate the speed of serial ports. Which will work wonders
in combination with simh also trying to play that game.

The Tek emulator at least has an excuse - it wants to mimic the drawing speed

of a real Tek terminal. This may not be the best way to implement it, but at 

least it is understandable.

 

But I also see what the main problem is. The code does the whole thing
wrong about how to create a subprocess and run commands. Instead of just
opening a pty and act like any normal program does, it creates pipes to
play/pretend it's a terminal. And shells, and some other programs, do
not want to play nicely with this. They expect there to be a controlling
terminal. This wouldn't be so hard to fix, but yecch!
ssh also don't like that there isn't a proper controlling terminal,
while telnet and rsh actually are stupid enough that it don't matter.
For any other program, it's the same problem/story.

So now I see what the actual problem is with this program.
For anyone who would want to fix this, it's two bits to it. One is to
just make the updating of the screen at a reasonable speed/interval, and
the other is to just open a pty instead of the crazy pipes the program
plays with.

The current maintainer wants to give up the repo to someone else who

can continue development. Feel free to volunteer. 8-}

 

> But it also means this is easy to hook up to the PiDP-11, or any other
> system, or anywhere else. Just run "screen" as the command, or start
> your shell, or telnet somewhere, or even use ssh (the README.md file
> really suggest some confusion on the part of the author). Running
> ssh is
> no different than running telnet, except of course, whatever machine
> you
> connect to also need to have an ssh server, which probably almost no
> old
> system have...

Nope (unless I misunderstand you):

terry@spcpi2-host:~ $ ./tek4010 -fast -autoClear screen -d -r
tek4010 version 1.9
Fast refresh without fading

Screen dimensions: 1920 x 1080
Window dimensions: 922 x 702
Scaling: 0.225
Process has been terminated

Now, if you try to do it manually:

terry@spcpi2-host:~ $ ./tek4010 -fast -autoClear bash        
tek4010 version 1.9
Fast refresh without fading

Screen dimensions: 1920 x 1080
Window dimensions: 922 x 702
Scaling: 0.225

You get a Tek window that stays up, but is unresponsive. You have to ^C

your command line to get it to close.

The same if you try 'sh'. If you give 'ls' as the command, it displays and then

the window vanishes. 'ssh' is even more fun. In the window you invoked Tek

from, you get a mishmash of tek diagnostic messages and the ssh unknown

key message stuff:

terry@spcpi2-host:~ $ ./tek4010 -fast -autoClear ssh localhost
tek4010 version 1.9
Fast refresh without fading

Screen dimensions: 1920 x 1080

The authenticity of host 'localhost (::1)' can't be established.
ED25519 key fingerprint is SHA256:blahblahblahblahblah.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? Window dimensions: 922 x 702
Scaling: 0.225

While the Tek window just displays "Pseudo-terminal will not be allocated 

because stdin is not a terminal". Barf...

No pipes should be involved. The problem is exactly that a named pipe
(or two actually) are involved. The program should really just have
created a pty/tty pair, and used that for all interactions, and things
would just have worked.
Possibly also the lack of setting up stderr is a part of the problem. I
get the feeling whoever wrote that bit of code had no actual idea of how
it should be done, and just grabbed the first thing he could
find/invent/google, using all the wrong terms.

I'm not explaining myself clearly here (this should not be a surprise to you

at this point 8-).

All of these silly contortions above are just to get the Tek to be the emulated

PDP-11's console port, which is not where we want it to be (either the Tek

screen turns into a mass of lit pixels, or it auto-clears when the screen tries

to scroll).

The only methods SIMH appears to have to connect 'things' to multiplexors

or a plain old DL11 are:

A) Use a physical port like /dev/ttyUSB0

B) Use a telnet server listening on a port

The Tek emulator can't work with A (well, maybe it could if we took two

/dev/ttyUSBn devices and connected the TTL sides in a crossover, but

that is a really new level of insanity).

So we are left with B. Which gets us into "everybody wants to do pretend

baud rate limiting", plus potential problems with 8-bit-clean data paths.

So I was suggesting a third alternative, where SIMH connected a 'port'

to a named pipe, and the Tek emulator could then be told to connect to

the other end of the named pipe. No baud rate or 8-bit-clean issues and

no wonky plumbing.

But no, I'm not volunteering to write that, either.

BTW, back in the day I actually used a rather similar configuration - a

PDP-11/23 with RT11-XM. There was a normal console as the system

console, and a Tek 4115B was connected to the other DL11 port. The app

ran on the system console, opened the other DL11 port and read from 

the Tek keyboard and wrote to the Tek display.  

 

> The VT52 emulator is broken in a completely different way - you don't
> even see a window form, since it thinks there are no displays on the sys-
> tem:
>
> terry@spcpi2-host:~ $ /opt/pidp11/bin/vt52 bash pdp11
> SDL_CreateWindowAndRenderer() failed: No available displays

Do I even want to look at that one and see which way that one managed to
not do things right after I've seen tek4010?

Well, it may be a much simpler fix. It seems to do a "What display am I running

on?" and decide the answer is "none" and bails out.

What I'm wondering about is how all of this got rolled into Oscar's tarball (and

later .git) without anyone looking and going "Does any of this stuff actually

work at all?" Maybe almost nobody is trying to use them.

But the same thing should be going on over on the PiDP-10 with all of its even

more obscure display devices. Maybe things are better over there? 

[Johnny Billquist]

On 2026-02-15 00:58, terri-...@glaver.org wrote:
> On Saturday, February 14, 2026 at 5:07:32 PM UTC-5 b...@softjar.se wrote:
>
> And I also downloaded and built tek4010 on my local machine just
> now, to
> see a bit more what it is doing. And first of all, of all wonders, it
> also tries to emulate the speed of serial ports. Which will work
> wonders
> in combination with simh also trying to play that game.
>
>
> The Tek emulator at least has an excuse - it wants to mimic the drawing
> speed
> of a real Tek terminal. This may not be the best way to implement it,
> but at
> least it is understandable.

In a sense, I guess. I just reflected on that you now face two pieces of
software that both are trying to accomplish the same thing, and I
wouldn't be surprised if that gives less than an ideal result.

> But I also see what the main problem is. The code does the whole thing
> wrong about how to create a subprocess and run commands. Instead of
> just
> opening a pty and act like any normal program does, it creates pipes to
> play/pretend it's a terminal. And shells, and some other programs, do
> not want to play nicely with this. They expect there to be a
> controlling
> terminal. This wouldn't be so hard to fix, but yecch!
> ssh also don't like that there isn't a proper controlling terminal,
> while telnet and rsh actually are stupid enough that it don't matter.
> For any other program, it's the same problem/story.
>
> So now I see what the actual problem is with this program.
> For anyone who would want to fix this, it's two bits to it. One is to
> just make the updating of the screen at a reasonable speed/interval,
> and
> the other is to just open a pty instead of the crazy pipes the program
> plays with.
>
>
> The current maintainer wants to give up the repo to someone else who
> can continue development. Feel free to volunteer. 8-}

No thanks. I have way too many other things I'm working on as it is...
Happy to provide a couple of pointers to anyone who would be willing,
but that's about it.

> > But it also means this is easy to hook up to the PiDP-11, or any
> other
> > system, or anywhere else. Just run "screen" as the command, or start
> > your shell, or telnet somewhere, or even use ssh (the README.md file
> > really suggest some confusion on the part of the author). Running
> > ssh is
> > no different than running telnet, except of course, whatever machine
> > you
> > connect to also need to have an ssh server, which probably almost no
> > old
> > system have...
>
>
> Nope (unless I misunderstand you):

Yeah, it didn't work, for the simple reason that the thing is using
named pipes.

> terry@spcpi2-host:~ $ ./tek4010 -fast -autoClear screen -d -r
> tek4010 version 1.9
> Fast refresh without fading
> Screen dimensions: 1920 x 1080
> Window dimensions: 922 x 702
> Scaling: 0.225
> Process has been terminated
>
> Now, if you try to do it manually:
>
> terry@spcpi2-host:~ $ ./tek4010 -fast -autoClear bash
> tek4010 version 1.9
> Fast refresh without fading
> Screen dimensions: 1920 x 1080
> Window dimensions: 922 x 702
> Scaling: 0.225
>
> You get a Tek window that stays up, but is unresponsive. You have to ^C
> your command line to get it to close.
>
> The same if you try 'sh'. If you give 'ls' as the command, it displays
> and then
> the window vanishes.

Add -noexit and the window stays, and you can see the result.

> 'ssh' is even more fun. In the window you invoked Tek
> from, you get a mishmash of tek diagnostic messages and the ssh unknown
> key message stuff:

Interesting. Different system might be the reason.
When I do this, I get (in the tek window):

"
Warning: no access to tty (Undefined error: 0)
Thus no job control in this shell
"

In the window where I start tek4010, I get:

Gromit:tek/Tek4010> ./tek4010 ssh localhost
tek4010 version 1.9

Pseudo-terminal will not be allocated because stdin is not a terminal.

Screen dimensions: 1728 x 1117
Window dimensions: 1024 x 780


And then nothing more happens. Obviously ssh (and shell, and others) not
impressed by the pipes...

> terry@spcpi2-host:~ $ ./tek4010 -fast -autoClear ssh localhost
> tek4010 version 1.9
> Fast refresh without fading
> Screen dimensions: 1920 x 1080
> The authenticity of host 'localhost (::1)' can't be established.
> ED25519 key fingerprint is SHA256:blahblahblahblahblah.
> This key is not known by any other names.
> Are you sure you want to continue connecting (yes/no/[fingerprint])?
> Window dimensions: 922 x 702
> Scaling: 0.225
>
> While the Tek window just displays "Pseudo-terminal will not be allocated
> because stdin is not a terminal". Barf...

Yeah. All of the problems in the end because this is using pipes instead
of a pty.

> No pipes should be involved. The problem is exactly that a named pipe
> (or two actually) are involved. The program should really just have
> created a pty/tty pair, and used that for all interactions, and things
> would just have worked.
> Possibly also the lack of setting up stderr is a part of the problem. I
> get the feeling whoever wrote that bit of code had no actual idea of
> how
> it should be done, and just grabbed the first thing he could
> find/invent/google, using all the wrong terms.
>
>
> I'm not explaining myself clearly here (this should not be a surprise to you
> at this point 8-).

:-)

> All of these silly contortions above are just to get the Tek to be the
> emulated
> PDP-11's console port, which is not where we want it to be (either the Tek
> screen turns into a mass of lit pixels, or it auto-clears when the
> screen tries
> to scroll).

Agreed. We are not interested in it being a console. And for anything
else, you'd want either a serial port or telnet, or ssh, or rsh, or
something. But you might also want to use it to play with tektronix on
the local machine and don't care about simh at all...

> The only methods SIMH appears to have to connect 'things' to multiplexors
> or a plain old DL11 are:
>
> A) Use a physical port like /dev/ttyUSB0
> B) Use a telnet server listening on a port

Agreed. But there are also the options of telnet to an actual telnet
server running on your PDP-11, or an rsh server, or (as of yet unlikely)
ssh, or some other thingy.

> The Tek emulator can't work with A (well, maybe it could if we took two
> /dev/ttyUSBn devices and connected the TTL sides in a crossover, but
> that is a really new level of insanity).

A seems to have been one of the usecases, but instead of something sane,
tek4010 comes with an extra program that just connects you to a serial
port. There are plenty of programs under Unix that already does just
that, but because of the poor code in tek4010, they did their own
solution. Oh well.
But I suspect it does work. But if you want to connect to simh this way,
that means two serial ports, and a null modem cable. Which, as you say,
is another level of insanity.

> So we are left with B. Which gets us into "everybody wants to do pretend
> baud rate limiting", plus potential problems with 8-bit-clean data paths.

Definitely. With the added bonus of tek4010 done in such a bad way that
only a limited subset of programs will actually play with it.

> So I was suggesting a third alternative, where SIMH connected a 'port'
> to a named pipe, and the Tek emulator could then be told to connect to
> the other end of the named pipe. No baud rate or 8-bit-clean issues and
> no wonky plumbing.

Ah! Now I follow what you were thinking. Sure. Doable. But I would
really say tek4010 should be corrected to actually use a pty instead,
and then you can run whatever program you want to connect to simh.
I really do not look forward to adding named pipes as another way of
emulating serial ports. But I will of course not stop anyone from doing
just that, if they want to...

> But no, I'm not volunteering to write that, either.

:-D

> BTW, back in the day I actually used a rather similar configuration - a
> PDP-11/23 with RT11-XM. There was a normal console as the system
> console, and a Tek 4115B was connected to the other DL11 port. The app
> ran on the system console, opened the other DL11 port and read from
> the Tek keyboard and wrote to the Tek display.

I think that was not completely uncommon to do.

> > The VT52 emulator is broken in a completely different way - you
> don't
> > even see a window form, since it thinks there are no displays on
> the sys-
> > tem:
> >
> > terry@spcpi2-host:~ $ /opt/pidp11/bin/vt52 bash pdp11
> > SDL_CreateWindowAndRenderer() failed: No available displays
>
> Do I even want to look at that one and see which way that one
> managed to
> not do things right after I've seen tek4010?
>
>
> Well, it may be a much simpler fix. It seems to do a "What display am I
> running
> on?" and decide the answer is "none" and bails out.
>
> What I'm wondering about is how all of this got rolled into Oscar's
> tarball (and
> later .git) without anyone looking and going "Does any of this stuff
> actually
> work at all?" Maybe almost nobody is trying to use them.

I think the answer is mostly "too many cooks". Which is sortof a side
effect of Oscar not being a software person himself, lots of people want
to help, and the level of knowledge between people vary...

[terri-...@glaver.org]

On Saturday, February 14, 2026 at 5:36:37 PM UTC-5 Anton L. wrote:

> The tek4010 emulator is continually polling for events - essentially asking the display manager "Are we there yet?" as fast as it can - thousands of times a second.

That's a very questionable design, if you ask me... Why would anybody do that?

That is a VERY good question to which I have no answer.

If I had to guess, I'd say that it was developed on a vastly faster system, compiled 

without errors on a Pi, and that was that.

Back in the day (a time Johnny remembers, at least at a point where real systems

were around and usable, even if not actively being the "fast boxes" of the day), this

sort of stuff would never have been accepted. It simply couldn't be - As an example

at one point at the computer center I ran, we had an IBM 370/138 with 512KB of

RAM (in a cabinet with just the CPU and memory that weighed well over a ton), a

VAX 8650 with 128MB of RAM, a few PDP-11/44s with 4MB of RAM, and a pair

of 11/70s with 3.5MB each. The PDP-11's let you have a whopping 64KB of RAM

to yourself (128KB with I&D space), more if you used overlays. But those systems

still supported dozens of users (at a minimum) each, with a wide variety of DEC

and 3rd-party operating systems. The 370 had a 4KB segment size (for all of you

x86 haters with your ginormous 64KB segments), ran an operating system, spool-

ers, 4 single-job partitions and a partition with CICS running 60-plus terminals. All

in 512KB of RAM. The VAX was the nicest of the bunch with a faux-infinite linear

address space and an instruction set that had everything an assembly language 

programmer might ever need.

The point being, every byte/word of memory and every CPU cycle was precious

and we counted them. How many instructions in this loop? Can we make it fast-

er, smaller, or both? Will unrolling the loop give us enough speed improvement

that we can take the memory use penalty?

A single Raspberry Pi can emulate all of those systems (and their disks) at the 

same time, be faster than the original hardware, and have CPU cycles, memory

and storage left over. All on something a little larger than a credit card and that

starts at $35. It is an amazing leap in performance. But somewhere along the

way, we stopped optimizing our own code and trusted compilers to do it for us.

It also means that just about anyone could learn to program (at various skill

levels) and the Internet means that that code could be widely shared without

the need to physically mail magnetic tapes or disk packs to other people.

But a lot of the wonder and awe us old-timers felt when we were thought to

have enough experience that we could actually run our own programs on what

would today be multimillion-dollar machines got lost along the way.

We end up with things like "GNU anything requires GNU everything", tool builds

that spend more time running near-identical autoconfigure scripts over and

over, and so on.

I'm not going to take pot shots (well, maybe I am 8-) at anyone who spent the

time to create a program, make it freely available to others, and accept the

praise (or insults) that come along with that.

This isn't solely an issue with free software. Windows 3.11 (AKA Windows for

Workgroups) with the Win32S add-on came on ten 3.5" floppies (15MB, give

or take). Windows 11 is 5.5GB or 360 times bigger. Is it 360 times better? I

don't think so, even though I do think that Windows 7 (at 2.5GB) was the best 

Windows version.

I'll get off my soapbox now...

[terri-...@glaver.org]

On Saturday, February 14, 2026 at 7:18:54 PM UTC-5 b...@softjar.se wrote:

I think the answer is mostly "too many cooks". Which is sortof a side
effect of Oscar not being a software person himself, lots of people want
to help, and the level of knowledge between people vary... 

Oscar does truly amazing hardware replicas, but freely admits that soft-

ware is not his thing.

At least I got him to move it to GitHub and had him turn over development

to me (with an eventual merge back). But once I collected the various code

fixes from people, I took a look at the installer and said "This needs to be a

complete do-over".

But I would have hoped that the terminal emulators worked at one point.

Unfortunately, if they did, that was before pdpcontrol and screen came

along...

[Charles Ess]

Thanks, all - most enlightening on so many levels, as usual. 

A minor footnote. I was reminded that back in the good old days - November 2023 for me - the manual directed accessing the tek4010 terminal by way of xterm or uxterm.  

As ChatGPT informed me (in one of its better moments), "xterm has a long-standing Tektronix 4014/4010 emulation mode that is often lighter and better-behaved than standalone tek4010 clones." Rather than following the manual's incantation, I had much better results by starting with: xterm -t -e nc 127.0.0.1 4003

The terminal login was much more responsive, followed by moving around in the directories, etc. With the tek monitor running idle, CPU% was no longer in the high 90s - but rather varied between 19-28%. To be sure, when rendering a graphic - e.g., ./mathdemo2 - it shot up, but this time to "only" 95% or so. Certainly a better workaround at this point in time for my purposes.

As per usual, Johnny asked the pertinent question: why bother in the first place? In my case, FWIW: a lifelong interest in the view / hope / belief, going back to the Pythagoreans and then running through a range of folk, including Kepler and then an occasional contemporary physicist or mathematician, that number and numerical relationships articulate "the underlying reality" of the universe. Should we wish to better understand that reality (motivations and reasons vary, from "contemplative" to exploitative), by further developing automated techniques to calculate and, when relevant, visualize, faster - we can  thus more quickly and more fully get a grasp of these mathematical relationships. 

So for me, watching the tek terminal draw  sin (r) / r is a thing of beauty on several levels, including a growing understanding of how the hardware and software computing technologies underneath accomplish all of this - thanks to discussions, tips and tricks as exemplified in this thread.  So a thousand thanks again. - c.

[Johnny Billquist]

You have misunderstood me. I never asked "why bother". I'm constantly
asking why people are doing things in what I consider ways that don't
make sense to me.
Not that they are doing something at all. Heck, I'm constantly working
on these machines and systems, for no good reason except I enjoy it.

Johnny

On 2026-02-15 11:01, Charles Ess wrote:
> Thanks, all - most enlightening on so many levels, as usual.
> A minor footnote. I was reminded that back in the good old days -
> November 2023 for me - the manual directed accessing the tek4010
> terminal by way of xterm or uxterm.
> As ChatGPT informed me (in one of its better moments), "xterm has a
> long-standing Tektronix 4014/4010 emulation mode that is often lighter
> and better-behaved than standalone tek4010 clones." Rather than
> following the manual's incantation, I had much better results by
> starting with: xterm -t -e nc 127.0.0.1 4003
> The terminal login was much more responsive, followed by moving around
> in the directories, etc. With the tek monitor running idle, CPU% was no
> longer in the high 90s - but rather varied between 19-28%. To be sure,
> when rendering a graphic - e.g., ./mathdemo2 - it shot up, but this time
> to "only" 95% or so. Certainly a better workaround at this point in time
> for my purposes.

> --
> 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/5f553a61-0168-4e7b-ac6b-ab39b74d0a14n%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/5f553a61-0168-4e7b-ac6b-
> ab39b74d0a14n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Charles Ess]

Apologies for the misunderstanding - my bad.

I was not fully / accurately remembering (surprise) your original comment:

"First of all, I wonder why everyone is so insistent on going through emulated serial ports. It is slower, cause more load, and in addition you have a thing in simh where it actually tries to make the emulated serial ports actually behave like they were running at the speed they supposedly emulate. If you want things to fun "fast", this is not the way to go (although if you're playing locally, it might be needed, so I'm not saying it might not be right here)."

-- i.e.,  the last sentence fell out of my memory stack.

And fully agree, of course, that there are many intrinsic pleasures in working / playing with these devices.

Let me also reiterate my thanks for this discussion thread, as it has helped add a layer to my understanding of what's going on underneath the hood of the nice graphic display - i.e., code for the emulator that, shall we say, is not up to snuff. I've also learned more along the way about the relevant networking approaches, both within Raspian linux and 211BSD, and other possible sources of speed bottlenecks and performance problems. 

One slow step at a time ... but it does feel like I'm gradually moving from kindergarten into somewhere in the early first grade. Again, many thanks! - c.

[terri-...@glaver.org]

On Monday, February 16, 2026 at 4:40:50 AM UTC-5 charl...@gmail.com wrote:

And fully agree, of course, that there are many intrinsic pleasures in working / playing with these devices.

Let me also reiterate my thanks for this discussion thread, as it has helped add a layer to my understanding of what's going on underneath the hood of the nice graphic display - i.e., code for the emulator that, shall we say, is not up to snuff. I've also learned more along the way about the relevant networking approaches, both within Raspian linux and 211BSD, and other possible sources of speed bottlenecks and performance problems. 

I should also apologize - I was not having a particularly good week/weekend (as people who received direct email from me can certainly attest to).

It was not my intent (despite what I wrote in several of my posts) to be dismissive of the many other people who write software, documentation, etc. just for the love of doing it. It's fair for me to flame commercial software for its many failings (Windows 11, I'm looking at you here 8-), but without people writing free software, we wouldn't have any of the stuff we love to play with here.

Most of the time (to paraphrase a BASF advertisement many here are likely too young to remember) ""I don't make a lot of the things you use, I make a lot of the things you use better" - I see much of my work as improving software that already exists. Sometimes to the point it is no longer recognizable as the original. I do write a fair amount of from-scratch software, both for fun and professionally.

I have so many projects going on that I refer to it as "juggling cats" - or in computer terms, most of my CPU cycles are spent in the scheduler and not running the actual programs. A lot of PDP-11ish things that I am either contributing to or leading are happening in the background and will hopefully be released later this year. Which will also be a fitting anniversary for me - my first programming job started in July, 1976.

Anyway, we now return to your regularly scheduled programming (pun intended) - also a phrase many here may also be too young to remember.

[Warner Losh]

On Mon, Feb 16, 2026 at 1:01 PM terri-...@glaver.org <terri-...@glaver.org> wrote:

I should also apologize - I was not having a particularly good week/weekend (as people who received direct email from me can certainly attest to)

...

Then it's clearly time to inject a little humor to give a tiny bright spot for you and others that might be in a similar situation. :) If it's too soon, my apologies.

 

I have so many projects going on that I refer to it as "juggling cats" 

Clearly we need to have the regular which is harder "juggling cats" or "herding cats"? And what would a cat shepard be called anyway? And should we worry about what we call it? Or are the individuals juggling cats, while the project managers are herding people that are juggling cats? And why isn't the ASPCA involved and up in arms with all this questionable cat treatment occurring?

Warner

[terri-...@glaver.org]

On Monday, February 16, 2026 at 4:21:42 PM UTC-5 wl...@bsdimp.com wrote:

Then it's clearly time to inject a little humor to give a tiny bright spot for you and others that might be in a similar situation. :) If it's too soon, my apologies.

All good.

 

Clearly we need to have the regular which is harder "juggling cats" or "herding cats"? And what would a cat shepard be called anyway?

Clowderizer. Really.

  

And should we worry about what we call it? Or are the individuals juggling cats, while the project managers are herding people that are juggling cats?

Probably not. Project managers are there to impede progress and eat all the (questionably) good cafeteria food.

And why isn't the ASPCA involved and up in arms with all this questionable cat treatment occurring?

The cats are all virtual. Just like Albert (the VMS SIG''s Cheshire Cat mascot).

Over in RSTS/E SIG land, Brett Bump's wife drew a picture of Spike the bulldog (the RSTS/E SIG's mascot) with 

Albert's tail sticking out of his mouth. This upset the Powers That Be, as one of the unwritten rules is "Thou shalt 

not make fun of other SIGs", and the RSTS/E SIG mascot eating the VAX SIG mascot definitely qualified as making 

fun. Spike was later re-drawn without the cat's tail.

[Steph Spirat]

Ha ha ha ha ! I found this very funny. 

Thanks Warner for shifting our perspective, even just a little. 

Even through emails, our communications can be, at time, mis-quoted or mis-understood or mis-read, please take a breath and think, "Is what I am reading, really what the author meant to say, or could I have read that wrong?" Let's keep the dialogue open and honest. I am still learning from contributors to this forum.

Kind regards,

Steph

---

From: pid...@googlegroups.com <pid...@googlegroups.com> on behalf of Warner Losh <i...@bsdimp.com>
Sent: Tuesday, 17 February 2026 7:51 AM
To: terri-...@glaver.org <terri-...@glaver.org>
Cc: [PiDP-11] <pid...@googlegroups.com>
Subject: Re: [PiDP-11] Re: Tektronix on the standard PiDP11 2.11BSD distribution

 

--

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/CANCZdfrriwXoUnJOkG6CKw87WJ93m1yZHS0zSxRksnfOuYtTyw%40mail.gmail.com.

[Glenn Babecki]

And lest we forget Schrödinger's cat: Wanted Dead or Alive. 🤭

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/SE1P216MB1447F2DC6C45C8EEB3D39FDAB16CA%40SE1P216MB1447.KORP216.PROD.OUTLOOK.COM.

[Lawrence Fisher (RealTimeCat)]

It was unfortunate that Albert had to be culled from the VMS Sig due to a Cease and Desist request from the Mouse.