Configuring simulation serial ports?

[Chuck Hutchins]

I have a few questions about attaching a physical serial port to the PDP-11 simulation.
I have read through the PiDP-11 manual and a few other manuals but I'm missing some things, I think because I don't know the real hardware well enough.

In the manual it says I can attached a "dz or vh device, depending on the situation"
I found the section in the pdp11_doc about simulating a DZ11 or DHQ11 and I can edit the necessary boot.ini files but I don't know which type of multiplexer is appropriate for each system.

Which type should I use for which systems?  I imagine it depends on when it was released and what hardware the software is designed to work with.(?)

Another question that came to mind is, are there other serial ports besides the multiplexer that might be more appropriate? For example, is there a dedicated console serial port that might provide an advantage over going through the multiplexer?
Since I only have one real serial terminal, I only really need one dedicated physical serial connection, so maybe a multiplexer just isn't necessary?

My goal is one serial port for the Pi/Linux console and another dedicated to the simulated machine so that port connects direct to the PDP-11 while it's running.
I already have the console serial working on the Pi via the gpio uart (ttyS0) so now I just need to assign ttyUSB0 to the sim.

Thanks

[Chuck Hutchins]

I figured out how to set the console to a serial port, but I guess there isn't much point to having the console there if it's already on the Pi console.

I see the 211bsd system has a dz attached already. I tried attaching ttyUSB0 and going into multi user mode but didn't get anything on the terminal.
Not sure I have the syntax right and I'm not sure how to set the baud rate or other serial parameters.

[Nathan Vander Wilt]

Have you made any more progress on this? I am in a similar situation: I have some /dev/ttyUSBx devices working on the linux side, and have been able to ± configure them on the simh side, but have not had any success after that.

My personal preference at this point would be what I think is the simplest console, which I tried to configure as follows:

SET DLI LINES=3

SET DLI ENABLED

SET DLO ENABLED

ATTACH DLI Line=1,Connect=ser2

That did not seem to do anything, however. Specifically I tried examining 17776500 after pressing a key on the connected terminal and it remained zero. Did not seem to be working from Unix V6 either although it should be supported.

Based on another posting here, I also tried:

set dz enabled 

set dz lines=8 

attach dz -V line=1,connect=/dev/ttyUSB0

and based on the PiDP-11 document, I tried:

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

attach vh line=1,connect=/dev/ttyUSB1

attach vh line=2,connect=/dev/ttyUSB0

attach vh line=3,connect=/dev/ttyUSB2

 

At no point did any of the operating systems seem to recognize the attached terminals. When I try e.g.

echo "test" > /dev/tty00

it hangs in any operating system I've tried (unix6, unix7, 211bsd) and I haven't even figured out how to terminate the process which certainly slows down testing.

So I'm in a similar situation. Not sure what's the best device to use, or if any are "plug and play" with any of the Unixes. My own preferred target is Unix V6 but any would be helpful/interesting.

thanks,

-natevw

[Tom Lake]

I have the following in my config file and all eight terminals work in RSTS/E 10.1

;

; Add extra DZ11 terminal lines

;

attach dz -V line=0,connect=ser0

attach dz -V line=1,connect=ser1

attach dz -V line=2,connect=ser2

attach dz -V line=3,connect=ser3

attach dz -V line=4,connect=ser4

attach dz -V line=5,connect=ser5

attach dz -V line=6,connect=ser6

attach dz -V line=7,connect=ser7

[Nathan Vander Wilt]

Thanks!

And I figured out Unix V6, thanks to finally just diving straight to its boot.ini. (I'd been trying things in "interactive" mode first.) Anyway, I noticed that it was already enabling the DCI device so I took that as a good starting point.

1. Boot up to idled

2. Ctrl-E (or toggle Halt switch) 

3. In simh console: `attach dci -V line=0,connect=ser2` (I got the ser2 from `show serial`, I think /dev/ttyUSB0 would have worked as well)

4. cd ../unix6; do boot.ini

5. Voila! Got a "login:" prompt on my "main"/simh console **and** my USB serial one — we are multitasking, huzzah!!!

hope this helps,

-natevw

[Chuck Hutchins]

Ah, Ok. It might be be making more sense to me now.

The command 'show serial' at the simh prompt will show all available serial ports.
Ports are listed (for me) as ...

Serial devices:

 ser0   /dev/ttyAMA0

 ser1   /dev/ttyS0

 ser2   /dev/ttyUSB0

So using those serial port numbers as in the example from Tom Lake above,
I added 'attach dz -V line=0,connect=ser2' to connect my USB serial port and booted 211bsd into multi user mode.

aaand, I still got no response on that port, but I suspect I need to configure something in  the BSD operating system.

I tried 'echo "test" > /dev/tty00' as Nathan mentioned above and it just hangs. It works if I echo to /dev/tty instead.
Must be something else I'm missing in the OS.

Edit:  Got a response on the terminal. It printed "Connected to the PDP-11 simulator DZ device, line 0" , but still no login prompt on that port and unable to echo to tty00

[Anton Lavrentiev]

I use TX/RX from the PiDP11's P5 header (via the UART/USB converter) as a serial Linux console (attached to PC's USB port and running either TeraTerm or PuTTY @ 115200 8N1);

though for this to work, you have to enable both the UART and the serial console in Pi to get a login prompt (at /dev/ttyS0).  It is disabled by default, at least in my Pi 3B+ (but raspberry configuration lets you change that).  This way I can control either Pi or PDP11 (via "screen") right from my PC.  (I also enabled Pi's sshd so can login / copy files over via the network,

but in TeraTerm/PuTTY I can use the VT220 glass font in the amber color, so it's much cooler that just plain ssh :-)

Two of the Pi's USB ports are wired outside as RS232 ports (via the MAX232 onboard circuitry) and connect one real VT320 and another TeraTerm/PuTTY

(to the very same PC, via a COM/USB serial cable) both @ 9600 8N1 as the guest OS terminals.  On the SimH side in PiDP11, these are configured as:

att -v dz line=1,connect=/dev/ttyUSB0,nomodem

att -v dz line=2,connect=/dev/ttyUSB1,nomodem

Unfortunately, if these two statements are placed into boot.ini and executed _prior_ to RSX11M+ boots, both terminals end up with extremely slow output: I am pretty sure the delay is improperly introduced by SimH because it wouldn't work _at all_ if that was somehow related to the serial h/w baud rate -- it must remain at 9600;  but SimH has some delay logic to insert between the characters, and it is exactly what kicks in here, although incorrectly.  I had already reported this nuisance to the list but it wasn't confirmed by anybody else :-/

(BTW, SimH built from the git repo -- but obviously lacking the realcons addition -- does not exhibit this slowdown weirdness.)

So I issue the above two statements after the OS boot is complete, by stopping the emulator with <Ctrl/E> in that first serial console connection (/dev/ttyS0).  Done this way, the two serial terminals appear to work as fast as 9600 should feel like.

The remaining two Pi USB ports I wired to the back panel "as is":  one is to connect keyboard/mouse USB peg transceiver for the X desktop (the display is cabled via HDMI from the PiDP11 back panel -- I just switch my display outputs to see the picture), and the other one I "reserved" as a storage attachment in case I'd need to copy an SD using Linux, etc...

BTW, for those using /dev/ttyS0 and are being annoyed by the absence of terminal window size negotiation (NAWS, which works completely transparently in telnet / ssh sessions but not serial connections, and thus changing the terminal window size can badly distort any future output), here's the remedy:

In your ~/.profile on Pi, add the following:

res() {
  test $(tty) = /dev/ttyS0  ||  return 0
  eval `resize`
  stty rows $LINES cols $COLUMNS
}
test $(tty) = /dev/ttyS0  &&  trap res DEBUG

The "resize" command is part of the Pi's xterm package ("sudo apt-get install xterm" if you don't have it), but it _does not_ use any of the X windows calls, so is perfectly fine to be invoked from the console.  (The double check for ttyS0 is necessary not to mess up with shell piping.)  The above triggers terminal size reconfiguration prior to every command executed by the shell, but unfortunately not while the command is running (so no SIGWINCH).  It's still better than nothing, IMO.

HTH,

Anton

On Mon, Dec 16, 2019 at 11:09 PM Chuck Hutchins <ch...@hutchins1.net> wrote:

Ah, Ok. It might be be making more sense to me now.

The command 'show serial' at the simh prompt will show all available serial ports.
Ports are listed (for me) as ...

Serial devices:

 ser0   /dev/ttyAMA0

 ser1   /dev/ttyS0

 ser2   /dev/ttyUSB0

So using those serial port numbers as in the example from Tom Lake above,
I added 'attach dz -V line=0,connect=ser2' to connect my USB serial port and booted 211bsd into multi user mode.

aaand, I still got no response on that port, but I suspect I need to configure something in  the BSD operating system.

I tried 'echo "test" > /dev/tty00' as Nathan mentioned above and it just hangs. It works if I echo to /dev/tty instead.
Must be something else I'm missing in the OS.

--
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 on the web visit https://groups.google.com/d/msgid/pidp-11/bf6c31c9-1950-4189-ba3d-48e9109d115b%40googlegroups.com.

[Chuck Hutchins]

@Anton

I have the serial console on the Pi working fine. I get the simh console there and the console of the simulated device, but ...

I can't seem to get a second user on ttyUSB0.

I can get the serial port connected and I get the message on the terminal connected to that port  "Connected to the PDP-11 simulator DZ device, line 0"

but I don't get a login prompt on the port, nor am I able to echo anything to the port.

I'm trying to use 211bsd, so there may be something in the OS that I need to configure.
I haven't tried this with any of the other systems yet.

[Anton Lavrentiev]

I can try booting BSD later on tonight to see how it works for me.  I'm using RSX11M on PiDP11 -- I have so much Unix at work, I don't miss it :-)

--

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 on the web visit https://groups.google.com/d/msgid/pidp-11/55a41a18-0594-44e1-93c3-7d9b44b18c0a%40googlegroups.com.

[Anton Lavrentiev]

Well, I guess I failed...  I was able to boot BSD 2.11 from the systems PiDP11 package.  getty only start in multi-user mode.  I noticed SimH was showing DZ serial lines configured with 9600 7E1, so I changed that to match in my terminals but was unable to get the prompt.  It was working, though, in telnet connections at port 4000.  What I know for sure is that you have to attach serial lines prior to attaching listening port, because the other way around (attaching the telnet port last) cuts off the serial connections, for some reason.  I reported that to Mark (SimH) but he kinda dismissed that saying "it is sorta by design".  IDK what's the deal there.

[Anton Lavrentiev]

OK, I must have been tired yday, but today I got it working.  First off, last night I checked that everything on the BSD side was properly configured (/etc/ttys was in place and getty was configured properly).

In all honesty, I think there are some things in the SimH terminal multiplexer code, which are inherently broken.

So this is the setup (cut from my boot.ini) that works with BSD2.11 (note the order IS important):

set dz enabled
set dz lines=8

set dz 7b
att dz 4000
att -v dz line=1,connect=/dev/ttyUSB1,modem

Also note that you have to configure your terminal (be it a software window or a real hardware) to match the above:  use 7 bit/even parity AND hardware flow control.

Esp. the latter, as leaving that out (i.e. using "nomodem" or just nothing in the "attach" command above) will not bring the login prompt up.  Trust me, I tried!

(Also remember, getty is only started in multi-user mode, so remember to press <Ctrl/D> once the OS boots to single-user, and wait until you see

the prompt in the console -- it should then appear in your serial terminal as well.)

HTH,

Anton

P.S.  I already expect a note of disagreement from Johnny Buillquist, who keeps repeating to this list not to use H/W flow control for terminals, but in this particular case, I tried everything and only the "modem" magic made it work.  IDK, whose fault it is, though, OS's or SimH's (I wouldn't be surprised if OS has nothing to do with this LOL)

[Chuck Hutchins]

Thanks Anton,

Can you point me to some more detail on setting up /etc/ttys and getty ?
I've done it on Raspbian but I'm sure the procedure is more complex on BSD 211

[Anton Lavrentiev]

BSD2.11 included in PiDP11 systems is already configured correctly:

/etc/ttys lists all ttys where getty would be spawned for, and the terminals types used there match the terminal descriptions found in /etc/gettytab.

BTW, the terminal story is getting (getty?) weirder :-)  If I add second serial line, so that boot.ini looks like this:

set dz enabled
set dz lines=8
set dz 7b
att dz 4000
att -v dz line=1,connect=/dev/ttyUSB1,modem

att -v dz line=2,connect=/dev/ttyUSB0,modem

then line=1 (used in previous setup alone) stops working!  But line=2 works.  Interestingly enough, SimH reports the setup as following:

sim> show serial

Serial devices:
 ser0   /dev/ttyAMA0
 ser1   /dev/ttyS0
 ser2   /dev/ttyUSB0

 ser3   /dev/ttyUSB1
Open Serial Devices:
 DZ     Ln-1 /dev/ttyUSB1 {)    Config: 9600-7E1
 DZ     Ln-2 /dev/ttyUSB0 {)    Config: 9600-8N1
sim> show dz conn
line 1: Connected to serial port /dev/ttyUSB1
 Connected 00:06:44
line 2: Connected to serial port /dev/ttyUSB0
 Connected 00:06:43
 Modem Bits: DCD RNG DSR
sim> show dz
DZ      address=17760100-17760107*, vector=310-314*, BR5, lines=8
        attached to 4000,Line=1,Connect=/dev/ttyUSB1;9600-7E1,Line=2,Modem,Connect=/dev/ttyUSB0, 7b, 2 current connections

And line=2 is a VT320 that I did not yet had a chance to reconfigure, so it's 8N1 and no hardware flow control (Johnny must be happy!) and everything works!

I'm sure it's another SimH bug here, unfortunately.  I'll report it in my open ticket with them (or another one).  OTOH, maybe I don't understand the whole picture here, so comments are welcome.

--
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 on the web visit https://groups.google.com/d/msgid/pidp-11/082e7643-6a67-45fe-af2f-dfe121cbba09%40googlegroups.com.

[Anton Lavrentiev]

Having walked my dog and thought about it more, I'm refining my setup for 1 serial line (I couldn't get more than one working, per the above, as configuring second line causes previous line to lose the modem status, which then makes it dysfunctional):

set dz enabled
set dz lines=8
set dz 7b
att dz 4000
att -v dz line=1,connect=/dev/ttyUSB1,modem

The terminal itself can be configured with either 7 bits with parity (even) or 8 bits no parity -- makes no difference.  Flow control can be left as none (i.e. only TX/RX data lines), nothing "hardware" is actually required; or can be set to XON/XOFF -- more DEC-approriate.  Looks like getty wants to see the DCD/DSR bits set, which the "modem" settings must be providing.  Other than that, I can't really tell what could be wrong: after all, the telnet sessions work just "as is".

[Johnny Billquist]

There is a difference between enabling modem control, and trying to use
modem control as a way of managing flow control. :-)

DEC used modem control lines for modem control. That is, if you
configure a line as remote in a DEC OS, you will not get any reaction on
it until it signals on DCD that there is a remote terminal connected.
That is what DCD means.
In addition, it also cares about CTS. If no CTS, transmitter will not
transmit.
And of course, the computer side will have RTS and DTR active, so that
the terminal sees that there is a computer, and it is ready to receive.

It's just that trying to use these for flow control is not what they
were meant for, and it can lead to unexpected results.

But I'd say for local terminals, it's easier to just set things up as
local, and skip all the modem signalling.

Apart from that, you seem to have some weird problems. :-)

Johnny

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

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pidp-11/082e7643-6a67-45fe-af2f-dfe121cbba09%40googlegroups.com

> <https://groups.google.com/d/msgid/pidp-11/082e7643-6a67-45fe-af2f-dfe121cbba09%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 on the web visit

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

> Apart from that, you seem to have some weird problems. :-)

Well, have you tried a serial line or two in simh with bsd2.11 from the "systems" tarball? 'Cause if you do, there's gonna be the three of us having those weird problems LOL

[Anton Lavrentiev]

My final post on this subject:

This is the DZ device setup that makes 2 serial ports work with BSD2.11 (so login prompt gets output everywhere):

set dz enabled
set dz lines=8
set dz 7b

att dz -m 4000
att -v dz line=1,connect=/dev/ttyUSB1
att -v dz line=2,connect=/dev/ttyUSB0

Note the -m for the first attach -- that makes the entire DZ device use the modem signaling.

Also note that both serial ports must be configured 9600 7 bits with even parity to work correctly (garbage on screen if e.g. 8N1) without any hardware flow control.

(Compared to much simpler and more straightforward setup for RSX, IMO, it's quite different.)

sim> show ser

Serial devices:
 ser0   /dev/ttyAMA0
 ser1   /dev/ttyS0
 ser2   /dev/ttyUSB0
 ser3   /dev/ttyUSB1
Open Serial Devices:
 DZ     Ln-1 /dev/ttyUSB1 {)    Config: 9600-7E1

 DZ     Ln-2 /dev/ttyUSB0 {)    Config: 9600-7E1

sim> show dz
DZ      address=17760100-17760107*, vector=310-314*, BR5, lines=8

        attached to 4000,Line=1,Connect=/dev/ttyUSB1;9600-7E1,Line=2,Connect=/dev/ttyUSB0;9600-7E1, 7b, 4 current connections

sim> show dz conn
line 0: Connection from IP address ::1
Connection [::1]:4000->[::1]:36288
 Connected 00:05:05
 Modem Bits: DTR RTS DCD CTS DSR
 Telnet protocol

line 1: Connected to serial port /dev/ttyUSB1

 Connected 00:15:26
 Modem Bits: DTR RTS DCD RNG CTS DSR

line 2: Connected to serial port /dev/ttyUSB0

 Connected 00:15:26
 Modem Bits: DTR RTS DCD RNG CTS DSR
line 3: Connection from IP address 192.168.1.2
Connection [192.168.1.11]:4000->[192.168.1.2]:60777
 Connected 00:03:41
 Modem Bits: DTR RTS DCD CTS DSR
 Telnet protocol
line 4:  Line disconnected
 Modem Bits: DTR RTS DSR
line 5:  Line disconnected
 Modem Bits: DTR RTS DSR
line 6:  Line disconnected
 Modem Bits: DTR RTS DSR
line 7:  Line disconnected
 Modem Bits: DTR RTS DSR

sim> show mux
Multiplexer device: DZ, lines=8, ModemControl=enabled, Output Unit: DZ-XMT,
    Input Polling Unit: DZ-RCV-CON,
    attached to 4000,Line=1,Connect=/dev/ttyUSB1;9600-7E1,Line=2,Connect=/dev/ttyUSB0;9600-7E1, 4 current connections, sessions=2
Line: 0, Speed=9600 bps
Connection from IP address ::1
Connection [::1]:4000->[::1]:36288
 Connected 00:05:20
 Modem Bits: DTR RTS DCD CTS DSR
 Telnet protocol
  input (on) queued/total = 0/21
  output (on) queued/total = 0/127
  speed = 9600 bps
  bytes in buffer = 127
Line: 1 - notelnet, Speed=9600 bps

Connected to serial port /dev/ttyUSB1

 Connected 00:15:41
 Modem Bits: DTR RTS DCD RNG CTS DSR
  input (on) queued/total = 0/66
  output (on) queued/total = 0/1967
  speed = 9600 bps
  bytes in buffer = 256
Line: 2 - notelnet, Speed=9600 bps

Connected to serial port /dev/ttyUSB0

 Connected 00:15:40
 Modem Bits: DTR RTS DCD RNG CTS DSR
  input (on) queued/total = 0/40
  output (on) queued/total = 0/1849
  speed = 9600 bps
  bytes in buffer = 256
Line: 3, Speed=9600 bps
Connection from IP address 192.168.1.2
Connection [192.168.1.11]:4000->[192.168.1.2]:60777
 Connected 00:03:56
 Modem Bits: DTR RTS DCD CTS DSR
 Telnet protocol
  input (on) queued/total = 0/25
  output (on) queued/total = 0/238
  speed = 9600 bps
  bytes in buffer = 238
Line: 4, Speed=9600 bps
 Line disconnected
 Modem Bits: DTR RTS DSR
Line: 5, Speed=9600 bps
 Line disconnected
 Modem Bits: DTR RTS DSR
Line: 6, Speed=9600 bps
 Line disconnected
 Modem Bits: DTR RTS DSR
Line: 7, Speed=9600 bps
 Line disconnected
 Modem Bits: DTR RTS DSR

# who
root            tty00   Mar 19 04:55
root            tty01   Mar 19 04:48
root            tty02   Mar 19 04:48
root            tty03   Mar 19 04:56

HTH,

Anton

[Johnny Billquist]

On 2019-12-19 03:54, Anton Lavrentiev wrote:
> Having walked my dog and thought about it more, I'm refining my setup
> for 1 serial line (I couldn't get more than one working, per the above,
> as configuring second line causes previous line to lose the modem
> status, which then makes it dysfunctional):
>
> set dz enabled
> set dz lines=8
> set dz 7b
> att dz 4000
> att -v dz line=1,connect=/dev/ttyUSB1,modem
>
> The terminal itself can be configured with either 7 bits with parity
> (even) or 8 bits no parity -- makes no difference.  Flow control can be
> left as none (i.e. only TX/RX data lines), nothing "hardware" is
> actually required; or can be set to XON/XOFF -- more DEC-approriate.
> Looks like getty wants to see the DCD/DSR bits set, which the "modem"
> settings must be providing.  Other than that, I can't really tell what
> could be wrong: after all, the telnet sessions work just "as is".

With "telnet session", do you mean a session to port 4000, where simh is
serving, or a telnet session into the 2.11BSD system itself? (As 2.11BSD
do have a telnet daemon of its own, and I would say is actually the
preferred option, really).

Anyway, looking at your various reports, it looks like line 1 would have
lost its modem attribute in simh when you attached line 2.
That would sound like a bug in simh.

Also, needing, or not needing modem control lines in 2.11BSD depends on
what "terminal" you pick in /etc/ttys for the line.
So what does /etc/ttys actually say in your case?

Johnny

[Anton Lavrentiev]

> With "telnet session", do you mean a session to port 4000

Yes, throughout -- "telnet connections to the DZ device"

> /etc/ttys

All 8 lines have std.9600, it's the stock config as it came in the systems tarball, and that I did not touch.

> That would sound like a bug in simh

I followed up to this thread about what setup actually works.  But I think that simh config is inconsistent at best -- tried to convey that to them, as well.

[Johnny Billquist]

On 2019-12-20 02:04, Anton Lavrentiev wrote:
> > With "telnet session", do you mean a session to port 4000
>
> Yes, throughout -- "telnet connections to the DZ device"

Now... Why would you want to do that? :-)

The DZ suck, not to mention the delays that simh tries to force on you...

> > /etc/ttys
>
> All 8 lines have std.9600, it's the stock config as it came in the
> systems tarball, and that I did not touch.

Hmm. And that one should work fine without any modem control. Maybe
something funny going on on the simh side then... You do know that the
std.9600 in turn is defined in /etc/gettytab.

> > That would sound like a bug in simh
>
> I followed up to this thread about what setup actually works.  But I
> think that simh config is inconsistent at best -- tried to convey that
> to them, as well.

I probably agree. But really, if it drops an attribute on a line that
you explicitly set, because you assign a second line, I would probably
call that a bug.

[Anton Lavrentiev]

> Now... Why would you want to do that? :-)

Because I needed to understand what wasn't working in DZ with serial connections.

I checked if telnetting to it works, and it did!  Always, and regardless or any modem signalling attributes.

> You do know that the std.9600 in turn is defined in /etc/gettytab.

Yes sir, and I wrote that to this thread when asked how getty's should be configured.

> I would probably call that a bug

My point exactly

[Johnny Billquist]

On 2019-12-20 02:44, Anton Lavrentiev wrote:
> > Now... Why would you want to do that? :-)
>
> Because I needed to understand what wasn't working in DZ with serial
> connections.

Fair enough.

> I checked if telnetting to it works, and it did!  Always, and regardless
> or any modem signalling attributes.

Kindof odd maybe, but then again, with telnet faking a serial port,
you'll have to totally fake the modem signals as well, while with a real
serial port, there actually are real modem signals. So that could be a
difference that is important here...

Most terminals will ignore whats showing on the serial port, if the
modem signals are not correctly asserted, and the terminal is set to
work with the modem signals. You might have more luck if you still set
the terminal to ignore modem signalling. However, if you are unlucky,
then you will not get any data from terminal to system. But you might be
able to get something showing on the terminal by writing to the device.

> > You do know that the std.9600 in turn is defined in /etc/gettytab.
>
> Yes sir, and I wrote that to this thread when asked how getty's should
> be configured.

Sorry. Too many mails. I missed that.

> > I would probably call that a bug
>
> My point exactly

So we agree. :-)

[Johnny Billquist]

By the way...

On 2019-12-19 03:54, Anton Lavrentiev wrote:

> Having walked my dog and thought about it more, I'm refining my setup
> for 1 serial line (I couldn't get more than one working, per the above,
> as configuring second line causes previous line to lose the modem
> status, which then makes it dysfunctional):
>
> set dz enabled
> set dz lines=8
> set dz 7b
> att dz 4000
> att -v dz line=1,connect=/dev/ttyUSB1,modem
>
> The terminal itself can be configured with either 7 bits with parity
> (even) or 8 bits no parity -- makes no difference.  Flow control can be
> left as none (i.e. only TX/RX data lines), nothing "hardware" is
> actually required; or can be set to XON/XOFF -- more DEC-approriate.
> Looks like getty wants to see the DCD/DSR bits set, which the "modem"
> settings must be providing.  Other than that, I can't really tell what
> could be wrong: after all, the telnet sessions work just "as is".

I should maybe point out that terminal lines on a DZ by default only
works when modem signalling is in place.
In order to not have that, you need to create the devices under /dev
with a minor number that have bit 7 set.
See "man dz" for details.

I'm sure a telnet connection will always fake the modem signalling to
make it appear correct. A real line, on the other had, I would expect to
actually reflect the real modem signals.

[Brian Makin]

I still can't seem to get this to work.

From simh.

sim> show serial

Serial devices:

 ser0   /dev/ttyAMA0

 ser1   /dev/ttyS0  

 ser2   /dev/ttyUSB0

ttyUSB0 is a USB device I've plugged in.
How are the other two wired up?  which is connected to the ttl "console"?

Using /dev/ttyUSB0 I was able to get some communication.
login: displayed correctly but once I logged in I now get garbage.

[Johnny Billquist]

Hi.

On 2020-06-09 19:30, Brian Makin wrote:
> I still can't seem to get this to work.
>
> From simh.
> sim> show serial
> Serial devices:
>  ser0   /dev/ttyAMA0
>  ser1   /dev/ttyS0
>  ser2   /dev/ttyUSB0
>
> ttyUSB0 is a USB device I've plugged in.
> How are the other two wired up?  which is connected to the ttl "console"?

Those are all serial devices on the Linux side. How have you associated
them with devices on the PDP-11 side?

> Using /dev/ttyUSB0 I was able to get some communication.
> login: displayed correctly but once I logged in I now get garbage.

I can't tell what you are doing, based on this. More information is
needed. Also, what kind of system are you running on the PDP-11 side?

Johnny

> email: b...@softjar.se <javascript:>             ||  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 on the web visit

> https://groups.google.com/d/msgid/pidp-11/b0dbd451-1af8-49e4-9527-d870566cd19bo%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/b0dbd451-1af8-49e4-9527-d870566cd19bo%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Brian Makin]

Raspi 3 running raspbian 10
2.11 bsd on the pi.

First off trying to use the USB dongle

My terminal says, 9600 7-E-1

simh

DZ      address=17760100-17760107*, vector=300-304*, BR5, lines=8

        attached to Line=1,Modem,Connect=/dev/ttyUSB0, 7b, 1 current connection

Sitting at 

70Boot from ra(0,0,0) at 0172150

: 

On the terminal I see Cnnd  h 11 smua  dv, n, 1

# which looks like it's getting every other character?

boot and start multiuser, and I get nothing recognizable on the terminal.

sim> show serial

Serial devices:

 ser0   /dev/ttyAMA0

 ser1   /dev/ttyS0  

 ser2   /dev/ttyUSB0

Open Serial Devices:

 DZ     Ln-1 /dev/ttyUSB0 {)    Config: 9600-7E1

boot.ini

set dz enabled

set dz lines=8

set dz 7b

;attach dz 4000

attach -v dz line=1,connect=/dev/ttyUSB0,modem

;

sho dz

> an email to pid...@googlegroups.com
> <mailto:pid...@googlegroups.com>.

[Johnny Billquist]

Hi.

On 2020-06-09 20:01, Brian Makin wrote:
> Raspi 3 running raspbian 10
> 2.11 bsd on the pi.

Ok...

> First off trying to use the USB dongle
> My terminal says, 9600 7-E-1

Terminal as the physical terminal, I assume... That's an interesting
setting...

> simh
> DZ      address=17760100-17760107*, vector=300-304*, BR5, lines=8
>         attached to Line=1,Modem,Connect=/dev/ttyUSB0, 7b, 1 current
> connection
>
> Sitting at
> 70Boot from ra(0,0,0) at 0172150
> :
>
> On the terminal I see Cnnd  h 11 smua  dv, n, 1

The full line would be:
Connected to the PDP-11 simulator DZ device, line 1

> # which looks like it's getting every other character?

As you can see, it's not really every other character, but on average, I
suspect it is. However, looking a bit more, you'll realize that it is
just some characters getting through.
Which is in itself a good hint. You are essentially having your terminal
at 7E, while the 2.11BSD system is probably using 8 bits and no parity.
So, you are essentially just seeing the characters where the parity
happens to be correct by "accident". And with one parity bit, the chance
of it being correct is 50%. So on average you're loosing half the
characters.

Change your terminal to 7N maybe? Or if you actually have the BSD system
sending 8 bit data, use 8N. Or else it might be some other combination
of bobs and bits. Either way, you appear to be dropping characters
because of parity errors.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip

email: b...@softjar.se || Reading murder books

[Brian Makin]

Set everything to 8N,
Connected to the PDP-11 simulator DZ device, line 1 comes out correctly.
then get
2.11 BSD UNIX <blah blah>

login:

Once I login I get a bunch of garbage.
When I type it looks like a parity error (about half the characters appear.


and everything goes to crap.  But its closer!

This is what I'm attempting to use, which is a pretty neat device.
https://github.com/petrohi/terminal

Here's an interesting tidbit.
Open Serial Devices:
 DZ Ln-1 /dev/ttyUSB0 {) Config: 9600-8N1

Once I login on the terminal that switches to

Open Serial Devices:
 DZ Ln-1 /dev/ttyUSB0 {) Config: 9600-7E1

Why the heck would that happen?

--
You received this message because you are subscribed to a topic in the Google Groups "[PiDP-11]" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pidp-11/mOqKQ8tchG4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/94790f55-782c-9dd1-8dcb-1216e90903bf%40softjar.se.

[Johnny Billquist]

It's complicated... :-)

When getty is run, which is the thing that controls terminal lines, it
defaults to setting them to even parity.

So if you want to "fix" this, you need to read up on getty, gettytab,
and the whole process of terminal handling.

Or change the terminal. Going with 7N2 would be an easy way... :-)

Johnny

> email: b...@softjar.se <mailto:b...@softjar.se>             ||

> Reading murder books
> pdp is alive!                     ||  tryin' to stay hip" - B. Idol
>
> --
> You received this message because you are subscribed to a topic in
> the Google Groups "[PiDP-11]" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/pidp-11/mOqKQ8tchG4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> pidp-11+u...@googlegroups.com

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

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pidp-11/94790f55-782c-9dd1-8dcb-1216e90903bf%40softjar.se.
>

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.

> To unsubscribe from this group and stop receiving emails from it, send

> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/CA%2B1bPC0zf0hmKQYXBd2QsbfH5KXsLege2s4uND-o65FhWD3oPA%40mail.gmail.com
> <https://groups.google.com/d/msgid/pidp-11/CA%2B1bPC0zf0hmKQYXBd2QsbfH5KXsLege2s4uND-o65FhWD3oPA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Brian Makin]

After logging in I've tried every combination of 8 and 7 bit with even and odd parity with 1 or 2 stop bits and none work.

I also tried adding a new gettytab entry for no parity 9600 baud and changed /etc/ttys but it still resets the parity.
Sometimes it seems like a parity error, other times It's as if I'm getting a lot of strange terminal control codes.

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

>     To view this discussion on the web visit
>     https://groups.google.com/d/msgid/pidp-11/94790f55-782c-9dd1-8dcb-1216e90903bf%40softjar.se.
>
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to pid...@googlegroups.com
> <mailto:pid...@googlegroups.com>.

[Johnny Billquist]

Well, I guess you're a bit on your own at that point. This is very hard
to troubleshoot remotely. And even harder to troubleshoot via mail.

I think we've concluded that it is parity issues. How you progress from
here is beyond me.

Sorry.

Johnny

> <javascript:>

> >     email: b...@softjar.se <javascript:> <mailto:b...@softjar.se
> <javascript:>>             ||

> >     Reading murder books
> >     pdp is alive!                     ||  tryin' to stay hip" -
> B. Idol
> >
> >     --
> >     You received this message because you are subscribed to a
> topic in
> >     the Google Groups "[PiDP-11]" group.
> >     To unsubscribe from this topic, visit
> > https://groups.google.com/d/topic/pidp-11/mOqKQ8tchG4/unsubscribe

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

> >     To unsubscribe from this group and all its topics, send an
> email to

> > pid...@googlegroups.com <javascript:>
> >     <mailto:pidp-11%2B...@googlegroups.com <javascript:>>.

> >     To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/pidp-11/94790f55-782c-9dd1-8dcb-1216e90903bf%40softjar.se

> <https://groups.google.com/d/msgid/pidp-11/94790f55-782c-9dd1-8dcb-1216e90903bf%40softjar.se>.

>
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "[PiDP-11]" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send

> > an email to pid...@googlegroups.com <javascript:>
> > <mailto:pid...@googlegroups.com <javascript:>>.

> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/pidp-11/CA%2B1bPC0zf0hmKQYXBd2QsbfH5KXsLege2s4uND-o65FhWD3oPA%40mail.gmail.com
> <https://groups.google.com/d/msgid/pidp-11/CA%2B1bPC0zf0hmKQYXBd2QsbfH5KXsLege2s4uND-o65FhWD3oPA%40mail.gmail.com>
>
> >

> <https://groups.google.com/d/msgid/pidp-11/CA%2B1bPC0zf0hmKQYXBd2QsbfH5KXsLege2s4uND-o65FhWD3oPA%40mail.gmail.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/d/msgid/pidp-11/CA%2B1bPC0zf0hmKQYXBd2QsbfH5KXsLege2s4uND-o65FhWD3oPA%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
>
>
>
> --
> Johnny Billquist                  || "I'm on a bus
>                                    ||  on a psychedelic trip

> email: b...@softjar.se <javascript:>             ||  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 on the web visit

> https://groups.google.com/d/msgid/pidp-11/53f9004e-b9e0-4053-8c31-59f020ccfe76o%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/53f9004e-b9e0-4053-8c31-59f020ccfe76o%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Clem Cole]

As an old UNIX guy, I'm going to make a few suggestions.  You have too many variables so cut this way back...

1.) try to keep the pieces of SW to as many knows as possible

2.) change one thing at a time.

Using that thinking try this strategy

First, since the console on the PDP-11 uses a KL11/DL-11 - you know that works for now, so keep the DZ out of it (remember, DZ are funky and did bad things, UNIX preferred DH-11s - most of us ran Able DH/DMs which was the DH equiv on real HW), although for a long time simh did not support them as well as the DZ so its a trade off, Mark has likely updated that I have not tried the DH is a long time).

Second, since getty/login mess with UNIX configuration, keep them out of it as you debug the endpoints.

Third, remember for each character in the UART, there are a few things that can be configured, the size of the character, the number of bits, if parity is being turned or not, and if so how.  getty is making stty/ioctl calls is trying to configure them for you and I suspect you have some issues with getting that exactly right so that by the time login/sh is running it's leaving the serial port configured as you need it.   The trick is figure out exactly what the ends are expecting and getting that path debugged without using having something changing it on you under the covers. 

For old style terminals as Johnny suggested, 8 bits, without any added parity, 1 stop bit, is the traditional way things will work best.   7 bits, with Even parity over an 8 bit character, with 1 stop bit was used for many years with simple terminals like the ASR 33 and ASR 37 and was the default way UNIX was set up since those terminals used the original 7-bit ASCII printing set.  But the ASR33 only has upper case athought it is ASCII, the upper/lower case ASR37 was native UNIX terminal from the old days - what nroff expected etc.   DEC Vt-100 come later to UNIX.  In fact the native UNIX 'glass tty' (i.e what vi expects for the its arrow keys) is the Lear ADM3A.  Also remember that VT-100 are only partially ANSI - they use the ANSI sequences -- I don't think that is your issue yet.   So later UNIX versions like BSD really want things like an Ann Arbor Ambassador, (aaa), a Heath H19 (h19, or a Wyse 60 (wy60) which are true ANSI terminals.  Even the xterm emulation of the ANSI terminal has some 'interesting' issue.  That said, I think you are fighting basic UNIX/terminal set up not yet terminal emulation ones - although you may not yet have your emulator configured properly.

The trick is you have a number of real UARTS and emulated ones, but the different terminal programs, but the OS all that have to agree before this is going to work.  So try to get as many of them out of the loop and try to make things as static as you can to start, as you debug this.

So... for simh, set up a second DL11 (KL11) as the second port and configure it to use the network to start - that means the simulation is only using one style of UART emulation to begin.  Also begin with a network connection to the simulation, so you can get one end stable,

1.) Then on a PC or another window, connect to that network port.

2.) Start up the simulated UNIX and  login into the console.

3.) On the UNIX console run the cu(1) program and connect between the console and the second port.

You be able to type between the window, you set up before and the console, try a tilde command and try dumping something like the password file or /usr/dict/words.   The trick is using cu(1), you should be able to configure the second KL11's stty parameters.  But using cu(1) the console and terminal will allow you to get rid of the OS playing with the UART reconfiguration -- you should have finer grain control.

4.) After you know that works, try reconfiguring the second KL11 to a USB serial ports on the RPI.

5.) The fire up a terminal emulator on a PC or Mac -- the simplier the better for my PiDP's.  I have a number of them on my Mac, ZTERM connecting my Mac to USB to RS-232C on a modern Mac.  This is a simple VT-100 emulator.   I have used things looks cool-retro-term and emulated other terminals.

But I would suggest keeping it simple.  Maybe something like c-kermit (which on a Mac can be installed with brew).    Maybe, even not trying a VT-100

terminal emulator, if you want a DOS emulator like, some of the other older ones can emulate an ASR37 (not 33). 

6.) Now try your emulated VT-100 again with cu to the KL-11

7.) If you thing you understand how to the end, points configured and you can sent data using cu between the end points, now configure getty/login

8.) If you want to great brave, try reconfiguring simh to use the DZ-11, but again you can use cu(1) between the console the remote end point and keep getty/login out of the way.

If you follow this strategy I think you can figure out what is changing and get each portion set up in a known manner.

Best wishes,

Clem

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/53f9004e-b9e0-4053-8c31-59f020ccfe76o%40googlegroups.com.

[Brian Makin]

Will do,
My next step was going to be strace and gdb, so this might be easier ;)

[Mark Pizzolato]

Clem’s suggestions are good and 100% appropriate if you’re working with real hardware.

 

Meanwhile, I’m pretty sure that only the DZ and VH devices will, in general, be well behaved when connected to physical serial ports.

 

Meanwhile both the DZ and VH simh DEVICEs pre-existed the richer MUX behaviors that are available now and they only use all of the rich behaviors if the ATTACH command for these devices specifies a –M switch.  Various published recipes for PDP11 (and VAX) setup exist from days before the new functionality was added, so the prior behavior exists for switches –A and –M is preserved.

 

Bottom line, try your DZ attach commands specifying –M (and –A).

 

-          Mark

 

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/CAC20D2NqvWcnpCTC-aB2qHQoijP7JoQ6HPPRnTSfax%2BCeHpNqQ%40mail.gmail.com.

[justme1968]

if your terminal supports this (my vt420 does) one possible workaround is to use 7 bit mark parity or 7 bit space parity. both work and where the only setting where i could get a working login prompt, a working shell and working top and vi. in every other combination i had problems with one or more of these.

it seems to ba a kludgy workaround as it is definitely not was is really send and it looks like my vt is ignoring parity errors but it works for now until i get all settings for simh, the login and getty right and consistent.

the only problem is that vi will insert some random characters if cursor movement is too fast. but maybe this is a vi problem as tcsh handles cursor movement as fast as i can type.

[justme1968]

i tried to switch to the raspberry build in serial port and have started to look a little more into this but i think there is something strange. maybe even a bug in simh.

- the switch from 8n1 for login to 7e1 for getty as already observed above is there and can be seen with simh show serial and with stty -F on the linux side
- getty/gettytab has no option to set the number of bits
- the gettytab manual and the getty source give the impression that setting ap (for any parity) should disable this switching to 7e1. this is what is set for the default gettytab entry. but as has seen above it has no effect for a dz serial port.
- this happens only if /dev/ttyS0 is connected as a dz serial port device. it does not happen if it is connected to the simh console. there getty stays at 8n1
- the 7b/8b option for dz seems not to have any influence or make a difference
- i could not find a better solution as the mark/zero workaround from above. but it works considerably less reliable for raspberry build in serial port as it does for a usb serial port.

as far as i have seen the 2.11 bsd and kernel and getty configuration for the console and for the dz serial ports should be identical and should behave the same. but they do not.

some questions:
- would al real live dz port be used as 7 or 8 bit in the days?
- what exactly ist the simh 8b option for dz supposed to do?
- do the 2.11 drivers for the newer serial port hardware work? is the simh emulation better?

- is anyone using a real vt terminal successfully with 2.11 bsd and has login, shell, top and vi working without changing the com seittings in between? if so: how is the simh side configured? raspberry build in serial or usb serial?

thanks
andre

[Mark Pizzolato]

On Monday, August 3, 2020 at 12:33:45 PM UTC-7, justme1968 wrote:

i tried to switch to the raspberry build in serial port and have started to look a little more into this but i think there is something strange. maybe even a bug in simh.

You are on to a real problem.  

- the switch from 8n1 for login to 7e1 for getty as already observed above is there and can be seen with simh show serial and with stty -F on the linux side
- getty/gettytab has no option to set the number of bits
- the gettytab manual and the getty source give the impression that setting ap (for any parity) should disable this switching to 7e1. this is what is set for the default gettytab entry. but as has seen above it has no effect for a dz serial port.
- this happens only if /dev/ttyS0 is connected as a dz serial port device. it does not happen if it is connected to the simh console. there getty stays at 8n1
- the 7b/8b option for dz seems not to have any influence or make a difference
- i could not find a better solution as the mark/zero workaround from above. but it works considerably less reliable for raspberry build in serial port as it does for a usb serial port.

as far as i have seen the 2.11 bsd and kernel and getty configuration for the console and for the dz serial ports should be identical and should behave the same. but they do not.

some questions:
- would al real live dz port be used as 7 or 8 bit in the days?
- what exactly ist the simh 8b option for dz supposed to do?

This is the problem.  The 7b, 8b and 7p options were relevant in early simh before physical serial port support existed and the DZ programmed line setup parameters (speed, character size, parity) were added to the DZ and VH devices simulators.  Now that these things are programmed in the OS, the programmed parameters should effect both input and output traffic for all lines with potentially individual settings per line.  Currently this sort of works for physical serial port traffic, but it interacts with these legacy settings.

I will fix this soon.

Meanwhile, since the console port on the PDP11 (and essentially all other simulators) does not have OS programmatic speed and character attributes, the various legacy 7B, 8B, 7P, UC and ASR settings should be manually configured.

[Johnny Billquist]

On 2020-08-03 21:33, justme1968 wrote:
> i tried to switch to the raspberry build in serial port and have started to look a little more into this but i think there is something strange. maybe even a bug in simh.

I don't think I fully follow what you are seeing/doing...

> - the switch from 8n1 for login to 7e1 for getty as already observed above is there and can be seen with simh show serial and with stty -F on the linux side

This does not make sense. getty is the first thing that is running, and
which is talking to the terminal.
getty then starts login. Not the other way around.

And getty defaults to 7e1 if nothing else is specified.
I would not expect login to change anything, so that should just
continue in whatever mode getty have set.

> - getty/gettytab has no option to set the number of bits

Not explicitly, but implicitly.
To quote the man-page:

np bool false terminal uses no parity (i.e. 8-bit
characters)


Any other option (ap, ep, op) means you'll have 7-bit characters. There
is no way to get 8 bits plus parity in getty, or 7 bit with no parity.

It might be a mistake to use "stty -F" on the Linux side and think that
tells you anything. If done properly, parity processing should be done
inside simh, and the actual serial line should probably be set to 8n1
under all circumstances by simh, no matter what parity the software
inside simh uses.

> - the gettytab manual and the getty source give the impression that setting ap (for any parity) should disable this switching to 7e1. this is what is set for the default gettytab entry. but as has seen above it has no effect for a dz serial port.

That is incorrect. ap does not mean you get 8n1. It means it will use 7
bits for data. For output, the parity bit might be anything. For input,
it is ignored, and stripped.

So, 7e1 is a perfectly acceptable setup for "ap", as long as it just
strips and ignores the parity on input. Essentially, you cannot get
parity errors with "ap".

> - this happens only if /dev/ttyS0 is connected as a dz serial port device. it does not happen if it is connected to the simh console. there getty stays at 8n1

Some simh strangeness going on here...

> - the 7b/8b option for dz seems not to have any influence or make a difference

Not sure what 7b/8b option you are talking about now, nor how you are
making the assertion.

> - i could not find a better solution as the mark/zero workaround from above. but it works considerably less reliable for raspberry build in serial port as it does for a usb serial port.
>
> as far as i have seen the 2.11 bsd and kernel and getty configuration for the console and for the dz serial ports should be identical and should behave the same. but they do not.

Agreed. Console and dz serial ports should be the same.

> some questions:
> - would al real live dz port be used as 7 or 8 bit in the days?

I saw both. It sortof depended on the terminal, and the era.
If we just talk about DEC OSes, they commonly used 7 bits in the early
days with old terminals, but by the time of the VT200, you migrated to
mostly having things be 8-bit clean, using DEC MCS. The DZ was still
extremely common, and you of course then had them running with 8 bit data.

> - what exactly ist the simh 8b option for dz supposed to do?

Mark?

> - do the 2.11 drivers for the newer serial port hardware work? is the simh emulation better?

The 2.11BSD drivers generally work. simh only supports the DZ and the
DHU/DHV if I remember right. Is that working better in simh? No idea.

> - is anyone using a real vt terminal successfully with 2.11 bsd and has login, shell, top and vi working without changing the com seittings in between? if so: how is the simh side configured? raspberry build in serial or usb serial?

I have a real VT terminal with 2.11BSD, but that is on a real machine.
Sorry, can't help with the simh side here.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip

email: b...@softjar.se || Reading murder books

[Brian Makin]

I had put this away to work on other projects... now you are going to make me break it out again :D 

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

To unsubscribe from this group and all its topics, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/545020de-e93d-9752-e675-0b8846703ce5%40softjar.se.

[Anton Lavrentiev]

I was able to get all terminals working in bsd2.11 with the following
simh setup:

https://groups.google.com/d/msg/pidp-11/mOqKQ8tchG4/YT-K8jDXAgAJ

HTH,
Anton

> --

> 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 on the web visit https://groups.google.com/d/msgid/pidp-11/a09f25da-1426-457a-9e70-66472ac5acbdo%40googlegroups.com.

[justme1968]

On Tuesday, August 4, 2020 at 12:15:30 AM UTC+2, Johnny Billquist wrote:

On 2020-08-03 21:33, justme1968 wrote:
> i tried to switch to the raspberry build in serial port and have started to look a little more into this but i think there is something strange. maybe even a bug in simh.

I don't think I fully follow what you are seeing/doing...

 

> - the switch from 8n1 for login to 7e1 for getty as already observed above is there and can be seen with simh show serial and with stty -F on the linux side

This does not make sense. getty is the first thing that is running, and
which is talking to the terminal.
getty then starts login. Not the other way around.

yes.of corse. that is what you get for editing posts on an iphone. i see that this makes the rest of my post quite confusing. 

it should read 8n1 with getty and 7e1 after that.

 

And getty defaults to 7e1 if nothing else is specified.
I would not expect login to change anything, so that should just
continue in whatever mode getty have set. 

the default entry in gettytab sets ap. this is definitely 8n1 for me. verified in my terminal settings and with stty on the linux side. only after the login it gets 7e1.

  

> - getty/gettytab has no option to set the number of bits

Not explicitly, but implicitly.
To quote the man-page:

      np      bool    false             terminal uses no parity (i.e. 8-bit
                                        characters)

this is not in the manage for getty one my system. there is only  ep, op and ap and the comment in the code for ap says

/*

 * If "any" parity do nothing otherwise set even parity unless OP is

 * set.  Since 'ap' is set in the "default" entry of /etc/gettytab this

 * has the effect of disabling parity on output without having to change

 * the kernel.

*/

where is your manpage excerpt from?

i'm currently still using the 2.11 bsd image from chase covello

 

but the main reason for trouble is not the getty settings but the change from login with getty to after login if dz ist used.

 

Any other option (ap, ep, op) means you'll have 7-bit characters. There
is no way to get 8 bits plus parity in getty, or 7 bit with no parity.

It might be a mistake to use "stty -F" on the Linux side and think that
tells you anything. If done properly, parity processing should be done
inside simh, and the actual serial line should probably be set to 8n1
under all circumstances by simh, no matter what parity the software
inside simh uses.

yes maybe. but clearly simh is changing the settings for the linux serial port if dz is used. this might just be a symptom of the difference in handling the console and the dz emulation that mark referenced above and seems to be part of the trouble. also simh is repeatedly changing it back to 7e1 for some programme started from the shell. maybe they use termcap to reset the terminal. i try to check this.

 

> - the gettytab manual and the getty source give the impression that setting ap (for any parity) should disable this switching to 7e1. this is what is set for the default gettytab entry. but as has seen above it has no effect for a dz serial port.

That is incorrect. ap does not mean you get 8n1. It means it will use 7
bits for data. For output, the parity bit might be anything. For input,
it is ignored, and stripped.

i beg to differ. see above. at least i definelty see 8n1 for the login prompt itself. 

 

So, 7e1 is a perfectly acceptable setup for "ap", as long as it just
strips and ignores the parity on input. Essentially, you cannot get
parity errors with "ap".

my problem at the moment is not 7e1 or any other setting if it were consistent. the trouble is that login uses different settings than everything after that if i use dz devices. if i use the sim h console the settings stay the same.  

> - this happens only if /dev/ttyS0 is connected as a dz serial port device. it does not happen if it is connected to the simh console. there getty stays at 8n1

Some simh strangeness going on here...

> - the 7b/8b option for dz seems not to have any influence or make a difference

Not sure what 7b/8b option you are talking about now, nor how you are
making the assertion.

there is a 7b/8b setting for the simh dz device. but it makes no difference in the observed behaviour hat the shell prompt after login has 7e1 set instead of the values that getty should have left behind.

 

> - i could not find a better solution as the mark/zero workaround from above. but it works considerably less reliable for raspberry build in serial port as it does for a usb serial port.
>
> as far as i have seen the 2.11 bsd and kernel and getty configuration for the console and for the dz serial ports should be identical and should behave the same. but they do not.

Agreed. Console and dz serial ports should be the same.

> some questions:
> - would al real live dz port be used as 7 or 8 bit in the days?

I saw both. It sortof depended on the terminal, and the era.
If we just talk about DEC OSes, they commonly used 7 bits in the early
days with old terminals, but by the time of the VT200, you migrated to
mostly having things be 8-bit clean, using DEC MCS. The DZ was still
extremely common, and you of course then had them running with 8 bit data.

> - what exactly ist the simh 8b option for dz supposed to do?

Mark?

> - do the 2.11 drivers for the newer serial port hardware work? is the simh emulation better?

The 2.11BSD drivers generally work. simh only supports the DZ and the
DHU/DHV if I remember right. Is that working better in simh? No idea. 

i will compile a kernel with dhu/dhv support and try as soon as i can.

[justme1968]

thanks.

but at least on first look it is the same that i'm using with that i see the problematic change from 8n1 to 7e1 after login

has completed. 

> To unsubscribe from this group and stop receiving emails from it, send an email to pid...@googlegroups.com.

[justme1968]

thanks for these comments. at least i'm not imagining things. 

there were still some problem with the console but as the console works more consistent than the dz emulation it would be great if dz could work more like the console.

you say dz and vh currently behave the same? that would mean trying vh instead of dz would make no difference and using the console for the time being is the best?

[Johnny Billquist]

On 2020-08-04 10:36, justme1968 wrote:
> On Tuesday, August 4, 2020 at 12:15:30 AM UTC+2, Johnny Billquist wrote:
>
> On 2020-08-03 21:33, justme1968 wrote:
> > i tried to switch to the raspberry build in serial port and have
> started to look a little more into this but i think there is
> something strange. maybe even a bug in simh.
>
> I don't think I fully follow what you are seeing/doing...
>
> > - the switch from 8n1 for login to 7e1 for getty as already
> observed above is there and can be seen with simh show serial and
> with stty -F on the linux side
>
> This does not make sense. getty is the first thing that is running, and
> which is talking to the terminal.
> getty then starts login. Not the other way around.
>
>
> yes.of corse. that is what you get for editing posts on an iphone. i see
> that this makes the rest of my post quite confusing.
>
> it should read 8n1 with getty and 7e1 after that.

Thanks. That clears up one point that confused me. :-)

A bit surprised that login then appears to be changing the settings,
though. But clearly someone is doing something.

> And getty defaults to 7e1 if nothing else is specified.
> I would not expect login to change anything, so that should just
> continue in whatever mode getty have set.
>
>
> the default entry in gettytab sets ap. this is definitely 8n1 for me.
> verified in my terminal settings and with stty on the linux side. only
> after the login it gets 7e1.

ap is not the same as 8n1. Definitely not.
However, what appears when you check something with stty is a different
story.

> > - getty/gettytab has no option to set the number of bits
>
> Not explicitly, but implicitly.
> To quote the man-page:
>
>       np      bool    false             terminal uses no parity
> (i.e. 8-bit
>                                         characters)
>
>
> this is not in the manage for getty one my system. there is only  ep, op
> and ap and the comment in the code for ap says

[...]
Damn! I wasn't close to a 2.11BSD system, so I checked the man-page for
a different system and hoped it would have been the same. That failed.
Sorry.
It does, however, hint to how getty works anyway.
So there is no clear way of getting something 8-bit clean in getty
within 2.11BSD it would appear.

But still, ap is *not* 8-bit data.

> i'm currently still using the 2.11 bsd image from chase covello
> but the main reason for trouble is not the getty settings but the change
> from login with getty to after login if dz ist used.

Right. So let's try to figure that one out.

> Any other option (ap, ep, op) means you'll have 7-bit characters. There
> is no way to get 8 bits plus parity in getty, or 7 bit with no parity.
>
> It might be a mistake to use "stty -F" on the Linux side and think that
> tells you anything. If done properly, parity processing should be done
> inside simh, and the actual serial line should probably be set to 8n1
> under all circumstances by simh, no matter what parity the software
> inside simh uses.
>
>
> yes maybe. but clearly simh is changing the settings for the linux
> serial port if dz is used. this might just be a symptom of the
> difference in handling the console and the dz emulation that mark
> referenced above and seems to be part of the trouble. also simh is
> repeatedly changing it back to 7e1 for some programme started from the
> shell. maybe they use termcap to reset the terminal. i try to check this.

I have never looked at how simh does things internally here, but I would
argue that it's clearly doing things wrong.
I wonder how it handles if you have 7e1, and you get bytes with the
wrong parity. This should be flagged by the DZ controller, but if simh
leaves that to the host system, how will it be able to properly simulate
the hardware?

This is why I think it should always run the serial ports at 8n1, and do
parity checking itself, to match what the simulated hardware would be doing.

What shell are you using in 2.11BSD by the way? At least tcsh, I think,
are constantly changing the terminal settings back to something "sane".

> > - the gettytab manual and the getty source give the impression
> that setting ap (for any parity) should disable this switching to
> 7e1. this is what is set for the default gettytab entry. but as has
> seen above it has no effect for a dz serial port.
>
> That is incorrect. ap does not mean you get 8n1. It means it will use 7
> bits for data. For output, the parity bit might be anything. For input,
> it is ignored, and stripped.
>
>
> i beg to differ. see above. at least i definelty see 8n1 for the login
> prompt itself.

As I said. I think simh should not be setting the serial port to
anything but 8n1 in the outside host. What 2.11BSD does at ap is a
different story. It should really strip the high bit off, which means it
is not the same as 8n1.
But you might not notice the difference until you start using something
that actually uses 8 bits.

> So, 7e1 is a perfectly acceptable setup for "ap", as long as it just
> strips and ignores the parity on input. Essentially, you cannot get
> parity errors with "ap".
>
>
> my problem at the moment is not 7e1 or any other setting if it were
> consistent. the trouble is that login uses different settings than
> everything after that if i use dz devices. if i use the sim h console
> the settings stay the same.

Which is a rather strange thing, I agree. And it seems Mark acknowledged
there is some kind of known bug in here.

> > - this happens only if /dev/ttyS0 is connected as a dz serial
> port device. it does not happen if it is connected to the simh
> console. there getty stays at 8n1
>
> Some simh strangeness going on here...
>
> > - the 7b/8b option for dz seems not to have any influence or make
> a difference
>
> Not sure what 7b/8b option you are talking about now, nor how you are
> making the assertion.
>
>
> there is a 7b/8b setting for the simh dz device. but it makes no
> difference in the observed behaviour hat the shell prompt after login
> has 7e1 set instead of the values that getty should have left behind.

Inside simh, you means?

[Mark Lawler]

Anton,

I just wanted to say THANK YOU THANK YOU THANK YOU!  I installed 2 USB to Serial TTL adaptors in my PiDP-11, connected through the MAX232 serial chip to RS232 DB9 serial connectors, etc.  I was following instructions that have you hop and skip around all over the place.  Luckily for me, this post had everything I needed to do in one place (vs bouncing around for snippets of info between a bunch of manuals, web pages, and such) to just make it work under 211 BSD on the PiDP-11.

I could feel your frustration as I was going through the permutations and such myself before reading your thread and then while reading it, but the bottom line is this post you made within the thread made my external RS232 port work for me when I followed your instructions to the letter.  For that I thank you!

Best,

-Mark

On Thursday, December 19, 2019 at 9:52:03 AM UTC-8 anton.la...@gmail.com wrote:

My final post on this subject:

This is the DZ device setup that makes 2 serial ports work with BSD2.11 (so login prompt gets output everywhere):

set dz enabled
set dz lines=8
set dz 7b

att dz -m 4000
att -v dz line=1,connect=/dev/ttyUSB1
att -v dz line=2,connect=/dev/ttyUSB0

Note the -m for the first attach -- that makes the entire DZ device use the modem signaling.

Also note that both serial ports must be configured 9600 7 bits with even parity to work correctly (garbage on screen if e.g. 8N1) without any hardware flow control.

(Compared to much simpler and more straightforward setup for RSX, IMO, it's quite different.)

sim> show ser

Serial devices:
 ser0   /dev/ttyAMA0
 ser1   /dev/ttyS0
 ser2   /dev/ttyUSB0

 ser3   /dev/ttyUSB1
Open Serial Devices:
 DZ     Ln-1 /dev/ttyUSB1 {)    Config: 9600-7E1

 DZ     Ln-2 /dev/ttyUSB0 {)    Config: 9600-7E1

sim> show dz
DZ      address=17760100-17760107*, vector=310-314*, BR5, lines=8

        attached to 4000,Line=1,Connect=/dev/ttyUSB1;9600-7E1,Line=2,Connect=/dev/ttyUSB0;9600-7E1, 7b, 4 current connections

sim> show dz conn
line 0: Connection from IP address ::1
Connection [::1]:4000->[::1]:36288
 Connected 00:05:05
 Modem Bits: DTR RTS DCD CTS DSR
 Telnet protocol

line 1: Connected to serial port /dev/ttyUSB1

 Connected 00:15:26
 Modem Bits: DTR RTS DCD RNG CTS DSR

line 2: Connected to serial port /dev/ttyUSB0

 Connected 00:15:26
 Modem Bits: DTR RTS DCD RNG CTS DSR
line 3: Connection from IP address 192.168.1.2
Connection [192.168.1.11]:4000->[192.168.1.2]:60777
 Connected 00:03:41
 Modem Bits: DTR RTS DCD CTS DSR
 Telnet protocol
line 4:  Line disconnected
 Modem Bits: DTR RTS DSR
line 5:  Line disconnected
 Modem Bits: DTR RTS DSR
line 6:  Line disconnected
 Modem Bits: DTR RTS DSR
line 7:  Line disconnected
 Modem Bits: DTR RTS DSR

sim> show mux
Multiplexer device: DZ, lines=8, ModemControl=enabled, Output Unit: DZ-XMT,
    Input Polling Unit: DZ-RCV-CON,
    attached to 4000,Line=1,Connect=/dev/ttyUSB1;9600-7E1,Line=2,Connect=/dev/ttyUSB0;9600-7E1, 4 current connections, sessions=2
Line: 0, Speed=9600 bps
Connection from IP address ::1
Connection [::1]:4000->[::1]:36288
 Connected 00:05:20
 Modem Bits: DTR RTS DCD CTS DSR
 Telnet protocol
  input (on) queued/total = 0/21
  output (on) queued/total = 0/127
  speed = 9600 bps
  bytes in buffer = 127
Line: 1 - notelnet, Speed=9600 bps

Connected to serial port /dev/ttyUSB1

 Connected 00:15:41
 Modem Bits: DTR RTS DCD RNG CTS DSR
  input (on) queued/total = 0/66
  output (on) queued/total = 0/1967
  speed = 9600 bps
  bytes in buffer = 256
Line: 2 - notelnet, Speed=9600 bps

Connected to serial port /dev/ttyUSB0

 Connected 00:15:40
 Modem Bits: DTR RTS DCD RNG CTS DSR
  input (on) queued/total = 0/40
  output (on) queued/total = 0/1849
  speed = 9600 bps
  bytes in buffer = 256
Line: 3, Speed=9600 bps
Connection from IP address 192.168.1.2
Connection [192.168.1.11]:4000->[192.168.1.2]:60777
 Connected 00:03:56
 Modem Bits: DTR RTS DCD CTS DSR
 Telnet protocol
  input (on) queued/total = 0/25
  output (on) queued/total = 0/238
  speed = 9600 bps
  bytes in buffer = 238
Line: 4, Speed=9600 bps
 Line disconnected
 Modem Bits: DTR RTS DSR
Line: 5, Speed=9600 bps
 Line disconnected
 Modem Bits: DTR RTS DSR
Line: 6, Speed=9600 bps
 Line disconnected
 Modem Bits: DTR RTS DSR
Line: 7, Speed=9600 bps
 Line disconnected
 Modem Bits: DTR RTS DSR

# who
root            tty00   Mar 19 04:55
root            tty01   Mar 19 04:48
root            tty02   Mar 19 04:48
root            tty03   Mar 19 04:56

HTH,

Anton

On Thu, Dec 19, 2019 at 8:00 AM Anton Lavrentiev <anton.la...@gmail.com> wrote:

> Apart from that, you seem to have some weird problems. :-)

Well, have you tried a serial line or two in simh with bsd2.11 from the "systems" tarball? 'Cause if you do, there's gonna be the three of us having those weird problems LOL

On Thu, Dec 19, 2019, 3:36 AM Johnny Billquist <b...@softjar.se> wrote:

There is a difference between enabling modem control, and trying to use
modem control as a way of managing flow control. :-)

DEC used modem control lines for modem control. That is, if you
configure a line as remote in a DEC OS, you will not get any reaction on
it until it signals on DCD that there is a remote terminal connected.
That is what DCD means.
In addition, it also cares about CTS. If no CTS, transmitter will not
transmit.
And of course, the computer side will have RTS and DTR active, so that
the terminal sees that there is a computer, and it is ready to receive.

It's just that trying to use these for flow control is not what they
were meant for, and it can lead to unexpected results.

But I'd say for local terminals, it's easier to just set things up as
local, and skip all the modem signalling.

Apart from that, you seem to have some weird problems. :-)

   Johnny

On 2019-12-19 02:06, Anton Lavrentiev wrote:
> BSD2.11 included in PiDP11 systems is already configured correctly:
>
> /etc/ttys lists all ttys where getty would be spawned for, and the
> terminals types used there match the terminal descriptions found in
> /etc/gettytab.
>
> BTW, the terminal story is getting (getty?) weirder :-)  If I add second
> serial line, so that boot.ini looks like this:

>
> set dz enabled
> set dz lines=8
> set dz 7b
> att dz 4000
> att -v dz line=1,connect=/dev/ttyUSB1,modem

> att -v dz line=2,connect=/dev/ttyUSB0,modem
>
> then line=1 (used in previous setup alone) stops working!  But line=2
> works.  Interestingly enough, SimH reports the setup as following:

>
> sim> show serial
> Serial devices:
>   ser0   /dev/ttyAMA0
>   ser1   /dev/ttyS0
>   ser2   /dev/ttyUSB0

>   ser3   /dev/ttyUSB1
> Open Serial Devices:
>   DZ     Ln-1 /dev/ttyUSB1 {)    Config: 9600-7E1
>   DZ     Ln-2 /dev/ttyUSB0 {)    Config: 9600-8N1
> sim> show dz conn
> line 1: Connected to serial port /dev/ttyUSB1
>   Connected 00:06:44
> line 2: Connected to serial port /dev/ttyUSB0
>   Connected 00:06:43
>   Modem Bits: DCD RNG DSR
> sim> show dz
> DZ      address=17760100-17760107*, vector=310-314*, BR5, lines=8
>          attached to
> 4000,Line=1,Connect=/dev/ttyUSB1;9600-7E1,Line=2,Modem,Connect=/dev/ttyUSB0,
> 7b, 2 current connections
>
> And line=2 is a VT320 that I did not yet had a chance to reconfigure, so
> it's 8N1 and no hardware flow control (Johnny must be happy!) and
> everything works!
>
> I'm sure it's another SimH bug here, unfortunately.  I'll report it in
> my open ticket with them (or another one).  OTOH, maybe I don't
> understand the whole picture here, so comments are welcome.
>
>
> On Wed, Dec 18, 2019 at 7:51 PM Chuck Hutchins <ch...@hutchins1.net
> <mailto:ch...@hutchins1.net>> wrote:
>
>     Thanks Anton,
>     Can you point me to some more detail on setting up /etc/ttys and getty ?
>     I've done it on Raspbian but I'm sure the procedure is more complex
>     on BSD 211

>
>     --
>     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 on the web visit

>     https://groups.google.com/d/msgid/pidp-11/082e7643-6a67-45fe-af2f-dfe121cbba09%40googlegroups.com
>     <https://groups.google.com/d/msgid/pidp-11/082e7643-6a67-45fe-af2f-dfe121cbba09%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 on the web visit

> https://groups.google.com/d/msgid/pidp-11/CAAo%3Dyr19rk2n3k9JTcMrTdOBwxvt-Wkp0Whz0Xh6iXWXyWtPgA%40mail.gmail.com
> <https://groups.google.com/d/msgid/pidp-11/CAAo%3Dyr19rk2n3k9JTcMrTdOBwxvt-Wkp0Whz0Xh6iXWXyWtPgA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[billb...@gmail.com]

I recently put together the PiDP-11 that I bought ages ago, and by and large it’s working great.  I also have a real VT-100 (manufactured in 1984) that I typically use to talk with my homebuilt TTL microcomputer (Magic-1, http://www.homebrewcpu.com).  I’d like to also use the VT-100 with my PiDP-11, but am running into a couple of problems - one small, and the other a bit more annoying.  The larger problem is corrupted characters - rare enough that I can still function, but common enough to make the experience a bit unpleasant.  My current suspicion is that with all the layers of simulation, sometimes an XOFF from the VT-100 doesn't get acted upon quickly enough and we get overrun. When I gather a bit more data I’ll post separately about that.

The smaller problem is the one discussed here - the change from 9600-8N1 to 9600-7E1 during getty. 

First, details about my setup:

Pi 3B+.  Cheap USB->TTL adapter plugged into one of the pi’s USB ports and connected to the TTL side of a MAX232.  Serial side of the MAX232 into the TX/RX/GND pins of a male DB9.  The VT-100 is connected via a DB9 <-> DB25 null modem cable.  I ssh into the pi for commands/console via the wireless adapter, and leave the hard-wired eth0 for use by the simh target.  In general, networking seems to work just fine.

Running the 2.11 BSD image, with the magic boot.ini incantations Anton described above:

set dz enabled

set dz lines=8

set dz 7b

attach dz -m 4000

attach -v dz line=1,connect=/dev/ttyUSB0

“Show version” in simh yields: PDP-11 simulator V4.0-0 Current  REALCONS build Aug 14 2019

VT-100 set to 9600-7E1.

After booting into multi-user, I get a garbled login prompt on the VT-100.  If I just hit return, I get the same garble.  However, if I try to enter any printable characters, something must auto-detect and the “password” prompt comes out clean.  Hit return again and I now get a clean login prompt at 7E1 and can successfully log in.

Any suggestions on how to avoid this issue?

Thanks,

...Bill

[Tom Lake]

I only have experience with RSTS/E so this may not apply to you. Does BSD allow multiple rates in its login config files or only one rate? If the former, then there's no escaping the garbage if the baud rate of the terminal doesn't match the first rate tested. Example: in your config you have 9600,1200,300,19200. If you log on with a 9600 baud terminal, then you won't see the garbage. If you're using a 300 baud terminal then your see garbage for two or three presses of a key. Then the rate of 300 is tried successfully. You could rearrange the numbers in the config file like this: 300,1200,9600,19200 and then the 300 baud terminal would come up after one key is hit.

[Johnny Billquist]

You're talking about automatic speed detection. That is possible in
2.11BSD as well, but if you know what speed a terminal is at, why do
this? Better to just set the speed correctly from the start.
In 2.11BSD this is in /etc/ttys and /etc/gettytab.

In RSX, with automatic speed detection, you usually do not need to see
any garbage characters. However, the implementation is depending on some
intimate knowledge of the hardware, which I suspect simh isn't
simulating correctly, so I wouldn't bet that it will work fine in simh.

But again, I doubt this is something people would normally ever need
nowadays. You know what speed you have your terminal on. Just set the
line to the same thing, and be done with it.
Same with the number of bits, parity, and flow control.

Johnny

On 2021-07-31 18:52, Tom Lake wrote:
> I only have experience with RSTS/E so this may not apply to you. Does
> BSD allow multiple rates in its login config files or only one rate? If
> the former, then there's no escaping the garbage if the baud rate of the
> terminal doesn't match the first rate tested. Example: in your config
> you have 9600,1200,300,19200. If you log on with a 9600 baud terminal,
> then you won't see the garbage. If you're using a 300 baud terminal then
> your see garbage for two or three presses of a key. Then the rate of 300
> is tried successfully. You could rearrange the numbers in the config
> file like this: 300,1200,9600,19200 and then the 300 baud terminal would
> come up after one key is hit.
>
> On Friday, July 30, 2021 at 11:31:16 PM UTC-4 billb...@gmail.com wrote:
>
> I recently put together the PiDP-11 that I bought ages ago, and by
> and large it’s working great.  I also have a real VT-100
> (manufactured in 1984) that I typically use to talk with my
> homebuilt TTL microcomputer (Magic-1, http://www.homebrewcpu.com

> <http://www.homebrewcpu.com>).  I’d like to also use the VT-100 with

>  <https://groups.google.com/d/msgid/pidp-11/082e7643-6a67-45fe-af2f-dfe121cbba09%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/pidp-11/082e7643-6a67-45fe-af2f-dfe121cbba09%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 on the web visit
>
> >
> https://groups.google.com/d/msgid/pidp-11/CAAo%3Dyr19rk2n3k9JTcMrTdOBwxvt-Wkp0Whz0Xh6iXWXyWtPgA%40mail.gmail.com
> <https://groups.google.com/d/msgid/pidp-11/CAAo%3Dyr19rk2n3k9JTcMrTdOBwxvt-Wkp0Whz0Xh6iXWXyWtPgA%40mail.gmail.com>
>
> >

> <https://groups.google.com/d/msgid/pidp-11/CAAo%3Dyr19rk2n3k9JTcMrTdOBwxvt-Wkp0Whz0Xh6iXWXyWtPgA%40mail.gmail.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/d/msgid/pidp-11/CAAo%3Dyr19rk2n3k9JTcMrTdOBwxvt-Wkp0Whz0Xh6iXWXyWtPgA%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
>

> --
> 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 on the web visit

> https://groups.google.com/d/msgid/pidp-11/78147578-4244-4be6-a181-b5f7a264c46bn%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/78147578-4244-4be6-a181-b5f7a264c46bn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Tom Lake]

For most people it's not necessary but I have up to eight people dialing into my phone line multiplexer and baud rates all over the place from 110 to 19200. When a user calls, I never know which PiDP-11 RSTS/E port the multiplexer will connect that call to so all the ports have to handle all the baud rates.

[Johnny Billquist]

Ok. I'm really impressed people actually still have 110bps modems
around. Not sure I ever saw any. 300 was pretty common when I started
playing around, as was 75/1200 split speed.

But yes, if you have a modem pool with people dialling in at different
speeds then you really do need the automatic speed detection feature.

Not sure how RSTS/E does it. With 2.11BSD I think it just tries
different speeds and you are supposed to hit enter until it works. I
don't remember if you can even define in which order the different
speeds are tried. Too long since I read the documentation for ttys.

With RSX, you usually just need to hit enter once, and it figures it
out. It knows what bit patterns a CR generates at different speeds with
the receiver set at 4800 (I think it is), and it also knows that the DZ
and DH generates different bit patterns for the CR at that same speed,
because of hardware differences, and it checks for the correct patterns
based on what kind of serial controller it is. So one CR, and it
immediately (hopefully) switches to the right speed.

Johnny

>  <https://groups.google.com/d/msgid/pidp-11/082e7643-6a67-45fe-af2f-dfe121cbba09%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/pidp-11/082e7643-6a67-45fe-af2f-dfe121cbba09%40googlegroups.com?utm_medium=email&utm_source=footer> <https://groups.google.com/d/msgid/pidp-11/082e7643-6a67-45fe-af2f-dfe121cbba09%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/pidp-11/082e7643-6a67-45fe-af2f-dfe121cbba09%40googlegroups.com?utm_medium=email&utm_source=footer>>>.

> <https://groups.google.com/d/msgid/pidp-11/78147578-4244-4be6-a181-b5f7a264c46bn%40googlegroups.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/d/msgid/pidp-11/78147578-4244-4be6-a181-b5f7a264c46bn%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 on the web visit

> https://groups.google.com/d/msgid/pidp-11/00866c64-a60d-4fa9-acaf-7ee9d276bb14n%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/00866c64-a60d-4fa9-acaf-7ee9d276bb14n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[billb...@gmail.com]

Thanks to all for the suggestions.   My biggest issue of corrupted character display on the VT-100 (presumably overrun because the multiple layers of emulation kept an XOFF from being responded to in time) is now largely (or wholly) resolved.  Instead of attaching the VT-100 though a usb/serial adapter on a dz line, I'm now connecting it directly to the pi's built-in UART as a console terminal to the pi.  Then, I can grab the simh session via screen.  Since doing that, I haven't experienced any of the corruption problems I was seeing before.

The last remaining issue is figuring out how to configure screen to play nicer when its underlying display device is a real VT-100.  Currently, it seems not to be able to handle the graphics characters correctly.  I'm sure there are some configuration setting somewhere I need to change - just don't know what they are yet.

Thanks again,

...Bill

[minc...@gmail.com]

Hello — resurrecting this, I'm having the same issue, where the terminal shifts from 8N1 at the login prompt (controlled by getty) to something else.  The odd part, though, is this doesn't appear to be the actual login process or shell doing it, when the session starts, but only when I'm prompted for a password at login...

By default, the 2.11 BSD distribution for the PiDP-11 doesn't have a password on the root account, so entering 'root' at the 'login:' prompt lets me in and everything is fine (aside from getting 33 lines and the wrong escape key, but that's something else!).  But, if I enter a different account name that either has a password or does not exist (i.e. set a password on the root account, or try to login as user 'mr.unknown'), the terminal changes to something else — if I stop the simulation with Ctrl+E and type 'show serial', I get told it's switches to 7E1 or 7O1.

The 'Password:' prompt is then garbled (presumably because we've shifted to some sort of parity from no parity) but I seem to be able to enter the password and then it sorts itself out.  If I get the password wrong, however (or the user account doesn't exist), then the 'login:' prompt is garbled.  I can sort things out by pushing Ctrl+D to restart the getty.

As another test, if I login successfully and all is fine, if I then enter 'login root' (or any other account with a password) then the 'Password:' prompt is garbled in the same way.

So, it looks to be the 'login' program that's actually causing the problem (or at least triggering a problem somewhere else) but I can't think why that would be mucking about with the terminal!  Or maybe getty is messing something up before it runs login, but the shell itself fixes it up.

[Tom Lake]

Have you tried doing an stty in your ./bashrc file to set the parameters to what you want?

[minc...@gmail.com]

I haven’t, no, but the “Password:” prompt will appear before that runs.  I suppose I can ignore that, though, and it’ll just get fixed up - I’ll try that, thanks.

Still seems something in login is amiss!

  - Bob

[Ron Young]

It has been many decades since if looked at the bsd sources. But iirc, the first login prompt is produced by Getty when a terminal connects. Getty then execs /bin/login to print the password prompt and then validate things. My guess is that login is/isn't configuring the tty before before the password prompt


Look at the /etc/ttys file to see if the terminal type is correct.
-ron

[Johnny Billquist]

On 2023-11-08 22:51, Ron Young wrote:
> It has been many decades since if looked at the bsd sources. But iirc,
> the first login prompt is produced by Getty when a terminal connects.
> Getty then execs /bin/login to print the password prompt and then
> validate things. My guess is that login is/isn't configuring the tty
> before before the password prompt

That is correct. But that is for serial lines. telnet is a different story.

But it's also the case that getty should set characteristics before the
user login prompt, and nothing should change between that and the
password prompt by login.

> Look at the /etc/ttys file to see if the terminal type is correct.

Also check /etc/gettytab for the settings of the various things based on
the type given in /etc/ttys.

The terminal type information is only used for setting the TERM
variable. Everything actually about the settings of the line comes from
the argument to getty. Normally something like std.9600. And you'll then
find what that means in /etc/gettytab, where you also deal with parity
settings, and so on...

Johnny

> -ron
>
>
> On November 8, 2023 1:38:09 PM PST, "minc...@gmail.com"
> <minc...@gmail.com> wrote:
>
> I haven’t, no, but the “Password:” prompt will appear before that
> runs.  I suppose I can ignore that, though, and it’ll just get fixed
> up - I’ll try that, thanks.
>
> Still seems something in login is amiss!
>
>   - Bob
>
>
> On Sunday, 5 November 2023 at 19:09:24 UTC Tom Lake wrote:
>
> Have you tried doing an stty in your ./bashrc file to set the
> parameters to what you want?
>

> --
> 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 on the web visit

> https://groups.google.com/d/msgid/pidp-11/DD186402-9610-4730-9987-41A83CDEF4B9%40gmail.com <https://groups.google.com/d/msgid/pidp-11/DD186402-9610-4730-9987-41A83CDEF4B9%40gmail.com?utm_medium=email&utm_source=footer>.