Attaching a VT-320 to RSX-11

[Daan Muller]

Hi,

I have hardware VT-100 emulator (Geoff's) that I have attached to a usb to TTL adapter to RX-TX and that works fine using getty on the pi.

Now I also have real VT-320 attached using a USB to RS232 null modem cable. I use this terminal in RSX-11 not via the pi with getty.

This works when I add this line to the boot.ini for RSX:

attach dz -V line=0,connect=/dev/ttyUSB1

But it very very slow, not like 9600 baud should be. Reading here I found that this has to do with the order of attaching or initializing (I don't really understand any of this but with the help of chatgpt I get where I want to be).

So now I removed that line again from the boot.ini.

When I have RSX-11 booted I can drop back to the SIMH prompt in an SSH terminal window on my Mac or in the VT-100 clone window. If I then enter the attach line at the SIMH prompt I can login at the VT-320 and the speed is like it should be.

Now I am wondering if there is a way to have RSX start-up and have the speed right from the get-go without having to go through SIMH? Something with a delay somewhere before the attach?

Cheers, Daan

[Anton Lavrentiev]

That's a known bug in simh that is in the PiPD1 distro, unfortunately.
A workaround is simple, though: from console (your Pi that has simh
running), use the following commands (MCR):
> SET /SPEED=TTn:(300,300)
> SET /SPEED=TTn:(9600,9600)
Substitute "n" for the actual terminal number that your VT320 appears
in RSX. That resets the delay logic (that's responsible for
rate-limiting of
the serial connections) in the DZ implementation in simh.
HTH
P.S. You'll have to do it every time you start your RSX, though.
P.P.S. It works for me, but your mileage may vary...

> --
> 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/5073ea2a-a2bd-4c58-bca5-5f097a6f9ce3n%40googlegroups.com.

[Daan Muller]

Ah, thanks! That's better dan dropping back to SIMH.

It was a post from you btw that got me as far as I did, so thanks again!

Cheer, Daan

Op dinsdag 2 juni 2026 om 20:24:46 UTC+2 schreef Anton L.:

[Daan Muller]

Would it be an option to add these two lines to the startup.cmd file for RSX-11?

Op dinsdag 2 juni 2026 om 20:28:07 UTC+2 schreef Daan Muller:

[Anton Lavrentiev]

You can do that, I suppose. But make sure your terminal lines do not change numbers, because sometimes they do (the change comes from pi itself).  There's a way to make them stable, though, in Pi, as well.

I can provide more details later if needed.

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/d7e6d858-0ebe-4587-ab58-7dddf40b0e1fn%40googlegroups.com.

[Daan Muller]

Yes, that would be great, thanks!

Op dinsdag 2 juni 2026 om 20:46:36 UTC+2 schreef Anton L.:

[Johnny Billquist]

It would be very hard for the unit number in RSX to change based on what
the ini-file is.

But yes, this is one of those annoying things in simh. It tries to
simulate the serial line speed artificially, which you really do not
want to have in there when you are on an actual, physical serial line.

Especially as simh start of with an initial assumption of what the speed
is. Which is why the command Anton gives sortof solves the problem.
Since after those, simh knows what the speed of the line is supposed to be.

Johnny

> bca5-5f097a6f9ce3n%40googlegroups.com <https://
> groups.google.com/d/msgid/pidp-11/5073ea2a-a2bd-4c58-
> bca5-5f097a6f9ce3n%40googlegroups.com>.

>
> --
> 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/d7e6d858-0ebe-4587-ab58-7dddf40b0e1fn%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/d7e6d858-0ebe-4587-
> ab58-7dddf40b0e1fn%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

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

> CAAo%3Dyr3FZVtBZZnJAQRBAeBzC%3DtGe3ePAu9omCAakPKv8d4rcg%40mail.gmail.com
> <https://groups.google.com/d/msgid/pidp-11/
> CAAo%3Dyr3FZVtBZZnJAQRBAeBzC%3DtGe3ePAu9omCAakPKv8d4rcg%40mail.gmail.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

[Anton Lavrentiev]

It's not RSX, which changes the line numbers but Pi!

When you have multiple USB UARTs plugged in (which then go out via
MAX232 to the actual serial lines and your terminals), Pi enumerates
them randomly (in random order!). So, for example I have two physical
terminals connected this way, and one bootup the first one is
/dev/ttyUSB0 and the second one is /dev/ttyUSB1 (and in RSX they are
TT3 and TT4, respectively), but once you reboot that can
switch and /dev/ttyUSB0 gets assigned to the second line, and
/dev/ttyUSB1 to the first, so the terminals in RSX also trade places
(since your attach command does not change from boot to boot). But
you can enforce Pi to use a stricter order, only not with the
/dev/ttyUSBx devices, but with creating links at bootup, and using
those in your attach command (instead of /dev/ttyUSBx).

1. Look through "dmesg" output on your Pi and locate lines which look
something like "usb 1-1.2.2" and "usb 1-1.3", these are your
device enumeration progress. In my case, I see the end UART devices like so:
usb 1-1.3: Product: CP2102 USB to UART Bridge Controller
usb 1-1.1.2: Product: CP2102 USB to UART Bridge Controller
Take a note of the 1-1.x.x prefixes (also note that they can have
different nesting depth, that's normal).

2. In /etc/udev/rules.d create a file named "10-usb-serial.rules" with
contents like so:
--CUT HERE--
KERNEL=="ttyUSB*", SUBSYSTEMS=="usb", KERNELS=="1-1.3", SYMLINK="ttyS1"
KERNEL=="ttyUSB*", SUBSYSTEMS=="usb", KERNELS=="1-1.1.2", SYMLINK="ttyS2"
--CUT HERE--
That will create the /dev/ttyS1 and /dev/ttyS2 links in the /dev
directory to _always_ follow the USB enumerator as found on the bus
(Pi is free to choose /dev/ttyUSBn randomly, meanwhile). Note that I
already have /dev/ttyS0 for the Pi native console, so I chose
to use 1 and 2 for these additional serial lines. You can use other
(e.g. higher) numbers -- that's not critical.
$ ls -l /dev/ttyS*
crw--w---- 1 root tty 4, 64 Jun 2 20:21 /dev/ttyS0
lrwxrwxrwx 1 root root 7 Jun 2 20:21 /dev/ttyS1 -> ttyUSB0
lrwxrwxrwx 1 root root 7 Jun 2 20:21 /dev/ttyS2 -> ttyUSB1
(note that targets for the symlinks can swap next time you reboot, but
the actual devices, S1 and S2, will always be in order and to
correspond to your 1st and 2nd terminal, respectively).

3. Edit your RSX11's (or whatever system you're using) boot.ini to
refer to the /dev/ttySx devices instead of /dev/ttyUSBx, like so:
attach -AV dz 10001,line=0,nomodem,connect=/dev/ttyS1,line=1,nomodem,connect=/dev/ttyS2
This makes RSX to always have TT3 for my first terminal and TT4 for
the second (like they are connected to the Pi).

Now, simh actually _knows_ which speed to use for your DZ lines (it's
9600 by default) but the version of simh packed for
PiDP11 has a bug that computes the rate delay twice (it's a delayed
delay, which is why it's closer to 1200 rather than 9600
when it starts)! When you reset the terminal speeds, it resets it
back to order.

I messed up the speed reset RSX(MCR) commands while typing my response
earlier (from the top of my head). They should have been:
> SET /SPEED=TT3:300:300
> SET /SPEED=TT3:9600:9600
(and the same for TT4, if necessary, and so on).

The above works for me and my old terminals and terminal servers
connected to Pi (in RSX).

Also, I might be behind the curve with the RaspiOS upgrades, and the
procedure for the current OS might be different (for "udev") -- that I
wouldn't know,
unfortunately. Way back in my university days, my CS professor used
to say, don't try to fix something if that ain't broken ;-) The words
of wisdom.
So, I keep using whatever I installed when I built my PiDP11 ;-)

Hope this helps.

> To view this discussion visit https://groups.google.com/d/msgid/pidp-11/93f3fee7-b01e-48c1-96ac-95e59ef363e8%40softjar.se.

[Daan Muller]

I can attach the serial by it's name in bookworm, so I use: attach dz -V line=1,connect=/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_BG00PM8S-if00-port0,nomodem

And when I login on the VT-320 I get this in the console: 07:25:00  Login  user USER           [200,1] TT4:

So it's TT4 for me, and with the SET /SPEED commands in the console it works like it should now. :-)

Thanks!

Op woensdag 3 juni 2026 om 03:09:36 UTC+2 schreef Anton L.:

[Johnny Billquist]

On 2026-06-03 03:08, Anton Lavrentiev wrote:
> It's not RSX, which changes the line numbers but Pi!

Yes. However, it is unlikely that it will do it differently every time
you reboot, as long as your hardware is stable. It is not truly random.

But also, if the ini-file for simh only have that thing in there, the
end result would not be that his terminal got another unit number in
RSX, but that it either works, or it don't, if that line would end up on
another actual physical serial port.

But these are small details. But I also do agree that if you can make
sure the enumeration stays the same, even if you change hardware around,
that's a good thing. So I'm not arguing against your suggestions to
improve the config.

> Now, simh actually _knows_ which speed to use for your DZ lines (it's
> 9600 by default) but the version of simh packed for
> PiDP11 has a bug that computes the rate delay twice (it's a delayed
> delay, which is why it's closer to 1200 rather than 9600
> when it starts)! When you reset the terminal speeds, it resets it
> back to order.

Oh. That one I had missed. Thanks for the information. But either way, I
honestly consider simh to be broken around this. With an actual serial
port, it should not try to simulate the speed of a serial port.

Johnny

[Anton Lavrentiev]

> However, it is unlikely that it will do it differently every time
> you reboot, as long as your hardware is stable. It is not truly random.

Are you implying that I "imagined" things? Without any changes, just
rebooting the Pi
can get your USB devices listed (numbered) in a different order. Just
try it and observe!
That was a well-documented "feature" of Raspbian (at least at the time
when I installed it)
and was numerously discussed, respectively. That was also biting my
setup in an unexpected
way, because I wanted my "terminal lines" to be truly hardwired to the
simulated PDP-11.
Which was also why there were instructions widely provided how to work around it
(which I just followed then and shared to this list now).
Feel free to search the web to see that for yourself!

> connect=/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_BG00PM8S-if00-port0,nomodem
Yes, that'd work. Also, if you have only one USB UART, you don't have to worry
about anything. (For some reason, I though you'd be connecting both
the real VT320
and the Joeff's terminal simultaneously, to two different UARTs (obviously)).

However, there's also a built-in "feature" of simh that, too,
enumerates serial ports on its own,
and that can be seen by the "show serial" command. But it only
"knows" about the
classic Unix serial port names (such as /dev/ttySn) and USB UARTs
(such as /dev/ttyUSBm),
and it won't look into /dev/serial/... to find anything in there. The
enumeration is stable
so instead of using Unix device files (in the attach command), you can
always use "ser0",
"ser1" etc, which are going to be "linked" to the corresponding Linux
serial devices (and
once those are stable, so are the "serN" designations). IIRC, simh
does not distinguish
between the actual character files and symbolic links, so out of every
"symlinked" device,
it'll show two: serN for /dev/ttyUSBx and serM for /dev/ttySz (which
is symlinked to /dev/ttyUSBx)...

HTH

[Johnny Billquist]

Hi.

On 6/3/26 17:27, Anton Lavrentiev wrote:
>> However, it is unlikely that it will do it differently every time
>> you reboot, as long as your hardware is stable. It is not truly random.
>
> Are you implying that I "imagined" things? Without any changes, just
> rebooting the Pi
> can get your USB devices listed (numbered) in a different order. Just
> try it and observe!

Sorry. I wasn't trying to imply anything. All the USB enumerations I've
ever seen on any system have been systematic and resulted in devices
appearing in the same order every time. It sounds very magic that it
would be truly random, but I haven't checked how it works on the RPi.

> That was a well-documented "feature" of Raspbian (at least at the time
> when I installed it)
> and was numerously discussed, respectively. That was also biting my
> setup in an unexpected
> way, because I wanted my "terminal lines" to be truly hardwired to the
> simulated PDP-11.
> Which was also why there were instructions widely provided how to work around it
> (which I just followed then and shared to this list now).
> Feel free to search the web to see that for yourself!

No. I believe you. I just can't believe that someone did such an
implementation. That just seems so broken, and I would expect actually
take an extra effort.

Johnny

[Daan Muller]

Yes, I am connecting both hardware terminals simultaneously. Chatgpt came up with the using the name of the device after I fed it your post and asked it to explain it to me like I am 5. ;-)

Op woensdag 3 juni 2026 om 17:28:21 UTC+2 schreef Anton L.:

[Bert Driehuis]

On Wed, 3 Jun 2026 at 17:46, Daan Muller <wonde...@gmail.com> wrote:

Yes, I am connecting both hardware terminals simultaneously. Chatgpt came up with the using the name of the device after I fed it your post and asked it to explain it to me like I am 5. ;-)

Please note that, depending on the chipset of your USB serial port, it may or may not receive a unique name in /dev/serial/by-id. If it doesn't, it may or may not be possible to reprogram the device to get a unique serial number or name. For example, most CH340 based interfaces have absolutely no way to tell them apart.

I've had good results with CP210x based USB serial ports, and of course original FTDI parts.

often, the cheapest as well as the most expensive devices have no unique name :-)

-- Bert