search

simh / simh

The Computer History Simulation Project
http://simh.trailing-edge.com
Other
1.66k stars 304 forks source link

Configuring more than one line in DZ with "modem" causes previous line(s) to lose the "modem" setting #784

Closed al20878 closed 4 years ago

al20878 commented 4 years ago

Attaching serial lines to the DZ device lacks consistency w.r.t. the "modem" setting, at least.

make pdp11

Actually, the lost "modem" setting for line=1 seems to cause BSD2.11 (from PiDP-11 set of systems, see #782 as to how to download the systems' distro) to be unable to issue a login prompt on that line. It works if line=1 is the only one configured (top portion of the above), but if the second line is added, then line=1 stops working, but line=2 does work.

Also, it looks rather unclear why, while DZ is configured 7b, the serial device status shows 9600-8N1.

Lastly, when the above mentioned BSD2.11 boots multi-user with the two serial line config (so getty is spawned on both terminal lines), "show serial" reports the following:

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

Note that line=1 does not work (no login prompt, does not react to any input), while line=2 does! 8N1 for the former looks strange because DZ is told to support 7b characters, but it works!... BTW, hardware attached to line 2 can use either 7E1 or 8N1, and it does not seem to make any difference. (The latter is also true for line=1 when it's working, when configured alone.)

Thanks, Tony

markpizz commented 4 years ago

Several points: 1) The Modem feature on the DZ device is device wide and it enable modem behaviors for the whole simulated device (via -M on the attach command). It is up to the simulated OS configuration to then program the device ports as you want. For the DZ device this generally means that the OS dropping DTR will drop a TCP session. The OS dropping DTR on a line attached to a serial port will drop DTR on that port. 2) If you've got a complicated set of attach commands (you do), then they will have the least side effects if all lines (and the general mux) is attach with a single ATTACH command. This command should be done BEFORE you boot your simulated OS and if you're going to change anything about the setup you will need to reboot the OS. Changes to attach details on a mux device are equivalent to inserting and removing boards in the computer - you didn't do that with the OS running. You may plug in or remove serial devices in the host system's serial ports at any time just like you could do with the original system.

FYI. You should also use SHOW MUX to display the state of some things.

al20878 commented 4 years ago

All the configuration shown in my first post was done BEFORE booting the OS. Only "show" commands were issued after it had booted, to inspect the state of the device. No re-attachment (on "pulling the board out") was done on a live OS. With that, only "connected" serial lines were affected, telnet lines seemed to work properly (one can telnet to port 4000, and get the login prompt).

The obvious fact, though, that serial line=1 stopped working in the presence of serial line=2, in BSD2.11 (on Raspberry Pi, 3B+, buster, with all the current updates installed), in the (almost) latest SimH version built from the sources. The same behavior was observed in SimH shipped within PiDP-11 package (much older SimH), so it's def not new.

On Thu, Dec 19, 2019, 9:42 AM Mark Pizzolato notifications@github.com wrote:

Several points:

  1. The Modem feature on the DZ device is device wide and it enable modem behaviors for the whole simulated device (via -M on the attach command). It is up to the simulated OS configuration to then program the device ports as you want. For the DZ device this generally means that the OS dropping DTR will drop a TCP session. The OS dropping DTR on a line attached to a serial port will drop DTR on that port.
  2. If you've got a complicated set of attach commands (you do), then they will have the least side effects if all lines (and the general mux) is attach with a single ATTACH command. This command should be done BEFORE you boot your simulated OS and if you're going to change anything about the setup you will need to reboot the OS. Changes to attach details on a mux device are equivalent to inserting and removing boards in the computer - you didn't do that with the OS running. You may plug in or remove serial devices in the host system's serial ports at any time just like you could do with the original system.

FYI. You should also use SHOW MUX to display the state of some things.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/simh/simh/issues/784?email_source=notifications&email_token=AKV67VYY43KUZTZVJU6MTGTQZOB33A5CNFSM4J4ZHIEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHJZ4FY#issuecomment-567516695, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKV67V4SKOLEFGINWNE5Q53QZOB33ANCNFSM4J4ZHIEA .

al20878 commented 4 years ago

Thanks for the "SHOW MUX" tip, it was quite helpful.

So the following setup makes BSD2.11 happy with all terminals working (tried two serial plus two telnet, localhost and outside):

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

I noticed that I had to use the 7E1 setting for the serial lines, to match that of SimH report:

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

The individual "modem" setting per line is very misleading then, at least the way it is documented in "HELP DZ".

Also, I do not understand why telnet lines are working with just "attach dz 4000" (i.e. with the "-m" omitted) but serial ones aren't...

markpizz commented 4 years ago

Since the DZ device was implemented a very long time ago, well before any of the more complete mux and serial functionality was added to simh, there are features in this device which persist to support configuration scripts that may exist in various places around the net. These features include SET DZ 7B and such, along with the -M switch on the attach command.

Also, I do not understand why telnet lines are working with just "attach dz 4000" (i.e. with the "-m" omitted) but serial ones aren't...

Some of this is also a legacy behavior. Without the attach -M switch, you'll notice that incoming telnet sessions don't signal carrier loss to the OS which, depending on OS configuration can let the OS know to drop a user login session.

The inconsistent behaviors with serial ports is likely related to them being implemented deeper in the generic MUX logic and the fact that they really need modem signalling to be well behaved.

markpizz commented 4 years ago 
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

This gets the job done and the sequence of attach commands should be equivalent to:

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

which is what I meant when I said:

If you've got a complicated set of attach commands (you do), then they will have the least side effects if all lines (and the general mux) is attach with a single ATTACH command.

al20878 commented 4 years ago

Ok, got it about combining the config into one-liner; although, it looks like nothing prevents it to be used over a few lines, for the sake of readability.

As for "support configuration scripts that may exist in various places around the net", I think you exaggerate the reality: if setting up one line with the "modem" setting kicks out such a setting from the previous one, that's plainly a bug and nobody in their decent mind would be using such a "feature". So obviously fixing that won't break anything.

Lastly, I was reading the DEC's DZ documentation and it looks to me that the lines are pretty much independent there, some can be using the modem signalling, some don't have to.

The Modem feature on the DZ device is device wide and it enable modem behaviors for the whole

So having per-line "modem" settings for selectively propagating the signaling for serial connections when needed, seems to be proper (regardless of the '-m' flag, which is already actually the default for any telnet connections; just can be treated as an "umbrella" flag for all serial ones too -- like having then with the "modem" setting implicitly -- if set with the "attach" command).

Bottom line, there are many inconsistencies in the DZ device configuration (I guess applies to all MUX-based terminals) that cannot be figured out from reading HELP or even via the trial-and-error approach (which also tends to be quite time consuming). Sorting those out would be much appreciated.

markpizz commented 4 years ago

Ok, got it about combining the config into one-liner; although, it looks like nothing prevents it to be used over a few lines, for the sake of readability.

The single line is specifically ordered to get the desired operation. Separating into multiple configuration lines might imply to some that the order doesn't matter, which it does.

As for "support configuration scripts that may exist in various places around the net", I think you exaggerate the reality: if setting up one line with the "modem" setting kicks out such a setting from the previous one, that's plainly a bug and nobody in their decent mind would be using such a "feature". So obviously fixing that won't break anything.

Support for serial and different behaviors for separate lines did not exist in the early days, but -M and -A switches were there originally. Legacy published scripts are absolutely there. That fact shouldn't bother you one way or another, you just have to get the specific configuration worked out for what you want to do (which you may then publish for others to end up using).

There should be no need for you to specifically mention MODEM in any line configuration for the DZ device as long as you specifically attach with the -M switch. The line attach modem feature exists in the TMXR layer for the many other devices which use it and don't have device specific -M switches.

The -M switch lets the modem signals that the OS may programmatically manipulate propagate out through the DZ device to the TMXR simulation layer (which includes Serial ports). Certainly, for all use cases you may need to deal with, you always want this set (as I said earlier, it isn't set due to the earlier version cases that didn't have it set). Once that option is selected, the OS configuration may decide to program some ports with modem control or not. You also want to specifically set the -A option at attach time. This option specifically affects what happens when the simulated system programmatically drops DTR. If it set and DTR is dropped, that details is passed through to the TMXR simulation layer and this will cause telnet connections to be disconnected, and serial connections to drop DTR on the host serial port.

Once again, these details exist since they were implemented when the DZ device was originally added to simh. If we were starting today, these maybe options wouldn't exist, or maybe they would. The fact that an option exists for host side disconnect (-A) and connection side disconnect (-M) reflects the fact that many DZ devices were connected with 3 wire (data only, TD, RD, GND) cables. Unplugging such a cable, generally wouldn't be noticed by either the PDP11 or VAX or the terminal.

Bottom line, there are many inconsistencies in the DZ device configuration (I guess applies to all MUX-based terminals) that cannot be figured out from reading HELP or even via the trial-and-error approach (which also tends to be quite time consuming). Sorting those out would be much appreciated.

This is why folks work out the proper config and then publish them so everyone doesn't have to struggle through determining the details.