[Simh] Multiple telnet ports in SimH to RSTS/E 9.6

Post by Will Senn
I am not able to figure out what devices to enable in SimH PDP-11 to get
multiple telnet connections in RSTS/E 9.6.
I'm using a PDP-11/73 with 4megs of memory and I have the console
SET CONSOLE TELNET=10000
I am able to telnet into port 10000. It works as a login terminal no problem.
But, then I also tried to set up some DZ11 lines to support additional logins
SET DZ ENABLE
SET DZ LINES=8
ATTACH DZ 10001
SHOW DZ
but these don't seem to be picked up by RSTS/E. SimH let's me connect via
telnet to ports 10001-10007, but RSTS/E does not respond in the telnet
session. I reviewed my sysgen for RSTS/E and it doesn't appear to have a
DZ11 peripheral configuration section. My sense is that RSTS/E doesn't
support DZ11s.
Accept Peripheral defaults ? <N >
---snip disk drives, paper tape, etc.
DMC11's/DMR11's ? <00>
DMV11's/DMP11's ? <00>
IBM 3271 or 2780/3780 simultaneous links ? <00>
RJ2780 support ? <N >
In looking at the
AA-2669J-TC_RSTS-E_System_Installation_and_Update_Guide.pdf file, page
49. It has this to say about the IBM 3271 or 2780/3780 option (sounds like an
Explanation - Each KMC-11 microprocessor controls one DUP11 synchronous
line interface to the 3271 or 2780/3780 host... and so on.
Does SimH support the KMC-11/DUP11 pairing somehow?
Or is there another suitable device available in SimH for providing access to
RSTS/E via telnet?
If so, what are the device names on the SimH side and the RSTS/E side of
things?

The KMC/DUP and DMC devices are only supported in simh for simulator
to simulator DECnet connections. These are WAN synchronous devices
which have nothing to do with connecting to a simulator via telnet.

You are on the right track looking at SYSGEN to configure the OS side of
enabling DZ functionality. You may also want to look at DL and DC devices
which can also provide incoming telnet connections to a simulator. Since,
I've never been a RSTS user, I can't begin to suggest how you configure
that OS to enable these devices.

Good Luck.

- Mark

Will Senn

2015-12-31 20:10:57 UTC

Post by Mark Pizzolato
The KMC/DUP and DMC devices are only supported in simh for simulator
to simulator DECnet connections. These are WAN synchronous devices
which have nothing to do with connecting to a simulator via telnet.

I'm not ready to tackle DECnet yet. I'll leave these devices for another
day.

Post by Mark Pizzolato
You are on the right track looking at SYSGEN to configure the OS side of
enabling DZ functionality. You may also want to look at DL and DC devices
which can also provide incoming telnet connections to a simulator. Since,
I've never been a RSTS user, I can't begin to suggest how you configure
that OS to enable these devices.
Good Luck.
- Mark

Paul Koning set me straight on figuring out that DZ, as configured, was
actually working. Duh, press RETURN twice to get BAUD detected properly,
then all is right in the world. The other devices might work too, but
since DZ worked, I'm happy.

Thanks for responding.

Will

Paul Koning

2015-12-31 20:26:40 UTC

...
Paul Koning set me straight on figuring out that DZ, as configured, was actually working. Duh, press RETURN twice to get BAUD detected properly, then all is right in the world. The other devices might work too, but since DZ worked, I'm happy.

In late versions of RSTS/E, the following are supported: DL11 and equivalent, DH11, DZ11 DHV11, DHU11.

DC-11 support existed in RSTS V4A, not sure about later. I don't remember that DJ11 support was ever done. Also note that V4A supports only single line interfaces (KL11, DL11, DC11, DL11-E); mux support arrived in RSTS/E V5A.

Originally you specified the terminal configuration with SYSGEN. As I mentioned, that disappeared at a late stage; I believe in V9.0 but I may be off a bit. If SYSGEN asks, you need to answer; if a particular version doesn't ask about terminals, that means it has terminal autoconfiguration at boot time.

Something related: RSTS/E knows how to find devices at boot time and disables anything configured that isn't actually present. That appeared in RSTS V5B. Before that time, you had to be careful in SYSGEN *not* to specify non-existent devices, because RSTS would try to reference them and crash.

paul

Will Senn

2015-12-31 20:31:24 UTC

In late versions of RSTS/E, the following are supported: DL11 and equivalent, DH11, DZ11 DHV11, DHU11.
DC-11 support existed in RSTS V4A, not sure about later. I don't remember that DJ11 support was ever done. Also note that V4A supports only single line interfaces (KL11, DL11, DC11, DL11-E); mux support arrived in RSTS/E V5A.
Originally you specified the terminal configuration with SYSGEN. As I mentioned, that disappeared at a late stage; I believe in V9.0 but I may be off a bit. If SYSGEN asks, you need to answer; if a particular version doesn't ask about terminals, that means it has terminal autoconfiguration at boot time.
Something related: RSTS/E knows how to find devices at boot time and disables anything configured that isn't actually present. That appeared in RSTS V5B. Before that time, you had to be careful in SYSGEN *not* to specify non-existent devices, because RSTS would try to reference them and crash.
paul

Is there a noticeable advantage of one over the other in SimH of using
DL11, DH11, DZ11, DHV11 or DHU11?

Thanks,

Will

Paul Koning

2015-12-31 20:40:58 UTC

In late versions of RSTS/E, the following are supported: DL11 and equivalent, DH11, DZ11 DHV11, DHU11.
DC-11 support existed in RSTS V4A, not sure about later. I don't remember that DJ11 support was ever done. Also note that V4A supports only single line interfaces (KL11, DL11, DC11, DL11-E); mux support arrived in RSTS/E V5A.
Originally you specified the terminal configuration with SYSGEN. As I mentioned, that disappeared at a late stage; I believe in V9.0 but I may be off a bit. If SYSGEN asks, you need to answer; if a particular version doesn't ask about terminals, that means it has terminal autoconfiguration at boot time.
Something related: RSTS/E knows how to find devices at boot time and disables anything configured that isn't actually present. That appeared in RSTS V5B. Before that time, you had to be careful in SYSGEN *not* to specify non-existent devices, because RSTS would try to reference them and crash.
paul

Is there a noticeable advantage of one over the other in SimH of using DL11, DH11, DZ11, DHV11 or DHU11?

Not likely. RSTS runs at blinding speed in emulation no matter what you use. DH/DHV/DHU have DMA output which means fewer interrupts. On a real PDP11 with very high output demands, that can make a clear difference. For example, the internal DEC tools used to control systems under test in manufacturing used RSTS, and specifically with DH mux interfaces because of the large output bandwidth required. But for most applications you're not likely to notice, and that's especially true in emulation.

paul

Clem Cole

2015-12-31 22:34:03 UTC

Post by Paul Koning
DH/DHV/DHU have DMA output which means fewer interrupts. On a real PDP11
with very high output demands, that can make a clear difference.

âThis is an understatement. More over real DH's supported a DM11 which
was full modem control, sadly the DZ had a half-way modem control. The
designer (whom I will not mention by name) later messed up the original
modem control on the console of the MC-500. It took a SW guy (i.e. me) to
teach him how why all of the wires are needed.â

The downside of the original DH was that was a "full system unit" -- its
was SSI/MSI TTL with the only LSI part being the Western Digital UART.
Actually a very impressive design, but expensive to manufacture. The DZ
was designed to replace it begin 8 lines per single board - so you got the
same # of serial ports (16) in two slots, as opposed to entire system unit
- but the system interface sucked and you lost modem control.

Post by Paul Koning
â....
But for most applications you're not likely to notice, and that's
especially true in emulation.

âCan't speak for RSTS or RSX but for UNIX it makes a >>huge<< difference.
In fact Ken O of Able Computer made the definitive DH not DEC. His product
was called the DHDM which was a single board with 16 lines and full modem
control, could run all the DEC diagnostics and actually was a little
smarter than the DEC implementation as he supported HW flow control which
the original did not.â

â Many (most) serious UNIX systems with his product, particularly when
you attached things like "trailblazer" modem to yours system at 38K or
more. A single DHDM with full modem control, cost the same as a single 8
line DZ; so it was a no brainer from a purchasing stand point.

Although in defense of Paul, being inside DEC at the time, was probably
hard to get the Able product; although I think I remember aps saying he had
get a couple for decvax because the DZ load was killing them (aps I think
you read this - do you remember/care to comment??).

Which brings me a question for Mark and Bob? IIRC simh does not support
the DH, only the DZ. I think I saw there was support for one of the QBUS
DH's but not the real thing. If that's true, how hard would it be to make
it support the regular DH?

âClemâ

â*** â
Ken
â â
is someone
I will add to Warren's UNIX people list at some point
â. BTW: At one point I got him to make a really cool product - which I
think I have seen Noel also refer and ask about -- the Enable11 which was
an UNIBUS cache card with a MMU on it, which he and I collaborated on (my
first "published" paper - years ago). Anyway it allowed you to get 22 bit
addressing on an 11/40 class system - did not solve the I/D issue, but was
a major help for 11/34A systems (again adding that to simH would might make
some sense. 2.xBSD will recognize it on boot and use it).

â As another side note, the DHDM was his biggest seller and a couple of
years later, I also tried to get him to make a DHDM like card for the PC.
At the time, he said that he could not figure out how to make money at it
because add-in cards on the PC bus were so cheap. Eventually the Rocket
Port guys did something similar with a custom ASIC and that became the
serial solution for PC UNIX systems (I think I still have one in my
collection of old stuff in the basement).â

Mark Pizzolato

2016-01-01 00:09:02 UTC

Which brings me a question for Mark and Bob? IIRC simh does not support
the DH, only the DZ. I think I saw there was support for one of the QBUS
DH's but not the real thing. If that's true, how hard would it be to make
it support the regular DH?

There is Qbus and Unibus DH support. The simh device name is VH. If you
can demonstrate that it doesn't work as expected on some OS it can be fixed.

Ken is someone I will add to Warren's UNIX people list at some point
BTW: At one point I got him to make a really cool product - which I think
I have seen Noel also refer and ask about -- the Enable11 which was an
UNIBUS cache card with a MMU on it, which he and I collaborated on
(my first "published" paper - years ago). Anyway it allowed you to get
22 bit addressing on an 11/40 class system - did not solve the I/D issue,
but was a major help for 11/34A systems (again adding that to simH
would might make some sense. 2.xBSD will recognize it on boot and use it).

If there are detailed programming specs for this you should be able to
add it to the simulator without much trouble. It would be significantly
harder working backwards from the 2.xBSD driver. Feel free to take a
crack at it.

- Mark

Will Senn

2016-01-01 21:56:21 UTC

Post by Will Senn
Paul Koning set me straight on figuring out that DZ, as configured,
was actually working. Duh, press RETURN twice to get BAUD detected
properly, then all is right in the world. The other devices might work
too, but since DZ worked, I'm happy.
Thanks for responding.
Will

Oh. And one other thing. Not only do you have to press enter twice, for
BAUD rate, but the main console session has be be started and
timesharing/system startup has to be finished before you can attach
another telnet session. I think this may have been the problem I was
having originally rather than the BAUD rate. I had started the telnet
session and booted the disk, but I hadn't started timesharing, when I
fired up telnet on port 10001.

Will

Paul Koning

2016-01-01 22:01:38 UTC

Paul Koning set me straight on figuring out that DZ, as configured, was actually working. Duh, press RETURN twice to get BAUD detected properly, then all is right in the world. The other devices might work too, but since DZ worked, I'm happy.
Thanks for responding.
Will

Oh. And one other thing. Not only do you have to press enter twice, for BAUD rate, but the main console session has be be started and timesharing/system startup has to be finished before you can attach another telnet session. I think this may have been the problem I was having originally rather than the BAUD rate. I had started the telnet session and booted the disk, but I hadn't started timesharing, when I fired up telnet on port 10001.

That makes sense. Until you've started timesharing, you're in a program called INIT, which is essentially the RSTS OS loader. It's a standalone program that talks only to the console, as well as the disks on which RSTS lives (and, in limited ways, the tape drives for accessing RSTS kit tapes). None of the other terminal lines are enabled at that time.

If you say "Start" for "start timesharing" (instead of just entering Return or "Yes") it does a somewhat more verbose startup which tells you about each controller that's disabled because it's not visible.

paul

Johnny Billquist

2016-01-02 11:20:39 UTC

Paul Koning set me straight on figuring out that DZ, as configured, was actually working. Duh, press RETURN twice to get BAUD detected properly, then all is right in the world. The other devices might work too, but since DZ worked, I'm happy.
Thanks for responding.
Will

Oh. And one other thing. Not only do you have to press enter twice, for BAUD rate, but the main console session has be be started and timesharing/system startup has to be finished before you can attach another telnet session. I think this may have been the problem I was having originally rather than the BAUD rate. I had started the telnet session and booted the disk, but I hadn't started timesharing, when I fired up telnet on port 10001.

That makes sense. Until you've started timesharing, you're in a program called INIT, which is essentially the RSTS OS loader. It's a standalone program that talks only to the console, as well as the disks on which RSTS lives (and, in limited ways, the tape drives for accessing RSTS kit tapes). None of the other terminal lines are enabled at that time.
If you say "Start" for "start timesharing" (instead of just entering Return or "Yes") it does a somewhat more verbose startup which tells you about each controller that's disabled because it's not visible.

If I read Will right, it does not make sense. Yes, you will not get any
response until timesharing have started, but you should be able to
telnet into the port as soon as simh has started. And once timesharing
is running, you should be able to get a response. I don't think there is
any reason why you would have to have even doing the telnet until
timesharing have started. I know that you don't have to wait under RSX.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

Paul Koning

2016-01-02 19:20:19 UTC

Paul Koning set me straight on figuring out that DZ, as configured, was actually working. Duh, press RETURN twice to get BAUD detected properly, then all is right in the world. The other devices might work too, but since DZ worked, I'm happy.
Thanks for responding.
Will

Oh. And one other thing. Not only do you have to press enter twice, for BAUD rate, but the main console session has be be started and timesharing/system startup has to be finished before you can attach another telnet session. I think this may have been the problem I was having originally rather than the BAUD rate. I had started the telnet session and booted the disk, but I hadn't started timesharing, when I fired up telnet on port 10001.

That makes sense. Until you've started timesharing, you're in a program called INIT, which is essentially the RSTS OS loader. It's a standalone program that talks only to the console, as well as the disks on which RSTS lives (and, in limited ways, the tape drives for accessing RSTS kit tapes). None of the other terminal lines are enabled at that time.
If you say "Start" for "start timesharing" (instead of just entering Return or "Yes") it does a somewhat more verbose startup which tells you about each controller that's disabled because it's not visible.

If I read Will right, it does not make sense. Yes, you will not get any response until timesharing have started, but you should be able to telnet into the port as soon as simh has started. And once timesharing is running, you should be able to get a response. I don't think there is any reason why you would have to have even doing the telnet until timesharing have started. I know that you don't have to wait under RSX.

Yes, it would seem reasonable that the telnet connection would go through. And indeed it does. I just ran that test.

Specifically, what happens when a RSTS system is in INIT: the telnet server in SimH accepts the connection, as usual. But you do NOT get the "Connected to the PDP-11 simulator DZ device, line 0" message.

paul

Timothe Litt

2016-01-02 19:39:34 UTC

Paul Koning set me straight on figuring out that DZ, as configured, was actually working. Duh, press RETURN twice to get BAUD detected properly, then all is right in the world. The other devices might work too, but since DZ worked, I'm happy.
Thanks for responding.
Will

Oh. And one other thing. Not only do you have to press enter twice, for BAUD rate, but the main console session has be be started and timesharing/system startup has to be finished before you can attach another telnet session. I think this may have been the problem I was having originally rather than the BAUD rate. I had started the telnet session and booted the disk, but I hadn't started timesharing, when I fired up telnet on port 10001.

That makes sense. Until you've started timesharing, you're in a program called INIT, which is essentially the RSTS OS loader. It's a standalone program that talks only to the console, as well as the disks on which RSTS lives (and, in limited ways, the tape drives for accessing RSTS kit tapes). None of the other terminal lines are enabled at that time.
If you say "Start" for "start timesharing" (instead of just entering Return or "Yes") it does a somewhat more verbose startup which tells you about each controller that's disabled because it's not visible.

If I read Will right, it does not make sense. Yes, you will not get any response until timesharing have started, but you should be able to telnet into the port as soon as simh has started. And once timesharing is running, you should be able to get a response. I don't think there is any reason why you would have to have even doing the telnet until timesharing have started. I know that you don't have to wait under RSX.

Yes, it would seem reasonable that the telnet connection would go through. And indeed it does. I just ran that test.
Specifically, what happens when a RSTS system is in INIT: the telnet server in SimH accepts the connection, as usual. But you do NOT get the "Connected to the PDP-11 simulator DZ device, line 0" message.

This is expected behavior. Telnet TCP connection states are mapped to
RS232 modem control signals.

A connection sets RI (ring indicator) on the virtual RS232 interface.
The OS "answers the call" by asserting DTR when it is ready to talk. As
far as it knows, it's talking to a real modem. (If an OS is configured
not to respect modem control, it will still set DTR when it's ready -
but without waiting for RI or monitoring CD/DSR.)

SimH doesn't do the output until the OS is ready because the message
informs you that the OS has answered the call. So you know when to
"autobaud" or get its attention in some other way. Remember that the
telnet ports can be accessed by people who aren't in the same place as
the person who boots the simulator... and an OS in the simulator can be
in many states other than timesharing, where it intentionally ignores RI.

The OS can hang up by dropping DTR, which has the expected effect of
dropping the tcp connection. This is the usual response to CD/DSR
dropping - which is what happens if the client closes the tcp connection.

This is true for all comm interfaces (well, those that support modem
control).

Post by Paul Koning
paul
_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh

Mark Pizzolato

2016-01-02 19:43:46 UTC

Post by Will Senn

Post by Will Senn

Post by Will Senn
Paul Koning set me straight on figuring out that DZ, as configured, was

actually working. Duh, press RETURN twice to get BAUD detected properly,
then all is right in the world. The other devices might work too, but since DZ
worked, I'm happy.

Post by Will Senn

Post by Will Senn
Thanks for responding.
Will

Oh. And one other thing. Not only do you have to press enter twice, for

BAUD rate, but the main console session has be be started and
timesharing/system startup has to be finished before you can attach another
telnet session. I think this may have been the problem I was having originally
rather than the BAUD rate. I had started the telnet session and booted the
disk, but I hadn't started timesharing, when I fired up telnet on port 10001.

Post by Paul Koning
That makes sense. Until you've started timesharing, you're in a program

called INIT, which is essentially the RSTS OS loader. It's a standalone program
that talks only to the console, as well as the disks on which RSTS lives (and, in
limited ways, the tape drives for accessing RSTS kit tapes). None of the
other terminal lines are enabled at that time.

Post by Paul Koning
If you say "Start" for "start timesharing" (instead of just entering Return

or "Yes") it does a somewhat more verbose startup which tells you about
each controller that's disabled because it's not visible.

Post by Johnny Billquist
If I read Will right, it does not make sense. Yes, you will not get any

response until timesharing have started, but you should be able to telnet
into the port as soon as simh has started. And once timesharing is running,
you should be able to get a response. I don't think there is any reason why
you would have to have even doing the telnet until timesharing have started.
I know that you don't have to wait under RSX.
Yes, it would seem reasonable that the telnet connection would go through.
And indeed it does. I just ran that test.
Specifically, what happens when a RSTS system is in INIT: the telnet server in
SimH accepts the connection, as usual. But you do NOT get the "Connected
to the PDP-11 simulator DZ device, line 0" message.

You don't get this due to the DZ device driver not having set the "Master Scan
Enable" bit In the DZ CSR. The DZ device only looks for incoming connections
after this bit has been set. Some operating systems (VMS) set this bit when
the driver is loaded, clearly others (RSTS) must do it later OR maybe the driver
isn't actually loaded until timeshareing is enabled...

Other MUX simulators generally will accept incoming connections whenever
the device has been ATTACHed and simulator is executing instructions.

- Mark

Paul Koning

2015-12-31 19:52:08 UTC

I am not able to figure out what devices to enable in SimH PDP-11 to get multiple telnet connections in RSTS/E 9.6.
SET CONSOLE TELNET=10000
I am able to telnet into port 10000. It works as a login terminal no problem.
SET DZ ENABLE
SET DZ LINES=8
ATTACH DZ 10001
SHOW DZ
but these don't seem to be picked up by RSTS/E. SimH let's me connect via telnet to ports 10001-10007, but RSTS/E does not respond in the telnet session. I reviewed my sysgen for RSTS/E and it doesn't appear to have a DZ11 peripheral configuration section. My sense is that RSTS/E doesn't support DZ11s.
Accept Peripheral defaults ? <N >
---snip disk drives, paper tape, etc.
DMC11's/DMR11's ? <00>
DMV11's/DMP11's ? <00>
IBM 3271 or 2780/3780 simultaneous links ? <00>
RJ2780 support ? <N >
Explanation - Each KMC-11 microprocessor controls one DUP11 synchronous line interface to the 3271 or 2780/3780 host... and so on.
Does SimH support the KMC-11/DUP11 pairing somehow?
Or is there another suitable device available in SimH for providing access to RSTS/E via telnet?
If so, what are the device names on the SimH side and the RSTS/E side of things?

KMC/DUP are used for the 2780 emulation feature, which is a rather obscure layered product -- I don't know anything about it.

As of RSTS V9.0, if memory serves, terminal configuration is no longer set during Sysgen. Instead, the monitor contains drivers for each supported terminal interface, and these are loaded at startup according to what hardware was found.

When you boot the system (at the "Start timesharing" prompt) enter "hardware list" to confirm that the DZ11s were indeed seen:

Start timesharing? <Yes> HA LI

Name Address Vector Comments
TT0: 177560 060
RL0: 174400 160 Units: 0(RL01) 1(RL01)
RM0: 177440 210 Units: 0(RK06) 1(RK06) 2(RK06) 3(RK06) 4(RK06) 5(RK06)
6(RK06) 7(RK06)
RU0: 172150 P340 RQDX3 Units: 0(RA82) 1(RA82) 2(RD54) 3(RX50)
MU0: 174500 P344 TK50 Units: 0(TK50) 1(TK50) 2(TK50) 3(TK50)
TU0: 172440 224 BAE=+034, Units: 0(TE16 @TM03 #0) 1(TE16 @TM03 #0)
TC0: 177340 214
LP0: 177514 200
DZ0: 160100 300 Sub-lines: 8
DZ1: 160110 310 Sub-lines: 8
DZ2: 160120 320 Sub-lines: 8
DZ3: 160130 330 Sub-lines: 8
XE0: 174510 120 DELUA Address: 08-00-2B-CC-DD-EE

KW11L 177546 100
SR 177570
DR 177570

Hertz = 60.

Other: FPU, SL, 22-Bit, Data space, Cache w/address, System ID = 4660

Option: <Start>

Next... I don't know why you expected telnet ports 10001-10007 to be active when you attached 10001. The attach command sets up just that TCP port number as one SIMH listens to, serving all the mux ports behind it. So you should be able to telnet to the port you specified multiple times, and when you do, SIMH should tell you that you're now connected to some port:

pkoning$ telnet localhost 9999
Trying ::1...
Connected to localhost.
Escape character is '^]'.

Connected to the PDP-11 simulator DZ device, line 1

RSTS P10.1-L 31-Dec-15 02:41 PM
User:
User: 1,211
Last interactive login on 31-Dec-15, 02:41 PM at KB5:
Last non-interactive login on 02-Apr-15, 04:31 PM
2 other users are logged in under this account

$

The other point to remember is that RSTS expects to do auto baud on all ports other than 0, in the standard setup at least. So you need to enter RETURN twice before you get the login prompt.

Will Senn

2015-12-31 20:07:07 UTC

Post by Paul Koning
KMC/DUP are used for the 2780 emulation feature, which is a rather obscure layered product -- I don't know anything about it.

First, I should say that my knowledge of RSTS/E is limited to a half day
of trying it out. I appreciate your telling me that you don't know
anything about this particular device either. It may seem insignificant,
but it helps me categorize things as I learn to know if I should know it
or it is actually obscure.

Post by Paul Koning
As of RSTS V9.0, if memory serves, terminal configuration is no longer set during Sysgen. Instead, the monitor contains drivers for each supported terminal interface, and these are loaded at startup according to what hardware was found.

This was really good to learn. I was concerned that sysgen had so few
devices to configure.

Post by Paul Koning
Start timesharing? <Yes> HA LI
Name Address Vector Comments
TT0: 177560 060
RL0: 174400 160 Units: 0(RL01) 1(RL01)
RM0: 177440 210 Units: 0(RK06) 1(RK06) 2(RK06) 3(RK06) 4(RK06) 5(RK06)
6(RK06) 7(RK06)
RU0: 172150 P340 RQDX3 Units: 0(RA82) 1(RA82) 2(RD54) 3(RX50)
MU0: 174500 P344 TK50 Units: 0(TK50) 1(TK50) 2(TK50) 3(TK50)
TC0: 177340 214
LP0: 177514 200
DZ0: 160100 300 Sub-lines: 8
DZ1: 160110 310 Sub-lines: 8
DZ2: 160120 320 Sub-lines: 8
DZ3: 160130 330 Sub-lines: 8
XE0: 174510 120 DELUA Address: 08-00-2B-CC-DD-EE
KW11L 177546 100
SR 177570
DR 177570
Hertz = 60.
Other: FPU, SL, 22-Bit, Data space, Cache w/address, System ID = 4660
Option: <Start>

Hardware list is a brilliant tip. I see the DZ device in my list, good news.
You are correct, of course. I originally confirmed 10001, but assumed
the others (I know, bad idea at this stage, assumptions...). Multiple
connections can be made to 10001. I learned something new again.

Post by Paul Koning
pkoning$ telnet localhost 9999
Trying ::1...
Connected to localhost.
Escape character is '^]'.
Connected to the PDP-11 simulator DZ device, line 1
RSTS P10.1-L 31-Dec-15 02:41 PM
User: 1,211
Last non-interactive login on 02-Apr-15, 04:31 PM
2 other users are logged in under this account
$
The other point to remember is that RSTS expects to do auto baud on all ports other than 0, in the standard setup at least. So you need to enter RETURN twice before you get the login prompt.

This was the key. I only hit RETURN once to check, not twice. After
hitting enter twice, it worked like a champ.

Thanks for the help!

Will

Mark Pizzolato

2015-12-31 20:42:41 UTC

Post by Paul Koning
KMC/DUP are used for the 2780 emulation feature, which is a rather
obscure layered product -- I don't know anything about it.

First, I should say that my knowledge of RSTS/E is limited to a half day of
trying it out. I appreciate your telling me that you don't know anything about
this particular device either. It may seem insignificant, but it helps me
categorize things as I learn to know if I should know it or it is actually obscure.

The KMC/DUP may have been useful for 2780 emulation with real hardware,
but it is ONLY there for simulator to simulator DECnet connections now.

- Mark

Paul Koning

2015-12-31 20:53:31 UTC

Post by Mark Pizzolato

Post by Paul Koning
KMC/DUP are used for the 2780 emulation feature, which is a rather
obscure layered product -- I don't know anything about it.

First, I should say that my knowledge of RSTS/E is limited to a half day of
trying it out. I appreciate your telling me that you don't know anything about
this particular device either. It may seem insignificant, but it helps me
categorize things as I learn to know if I should know it or it is actually obscure.

The KMC/DUP may have been useful for 2780 emulation with real hardware,
but it is ONLY there for simulator to simulator DECnet connections now.

I wonder if it would actually work with 2780 emulation -- connecting the SIMH emulated DUP with whatever a 2780 ports looks like in a simulated IBM/360.

As for DECnet, yes indeed. Note though that RSTS/E does not support that combination for DECnet; the only DECnet devices it supports are DMC11 (from the start), DMV11 and DMP11 (V7.1 and up), Ethernet (V9.3 and up), and software DDCMP on terminal ports (not clearly supported but present if you dig enough (V9.6 to some extent, V10.0 in cleaner form). So synchronous DDCMP is DMC and friends only (unless you count the Pro printer/console USART work I did as a midnight project in V9.6).

paul

Timothe Litt

2015-12-31 22:03:50 UTC

Post by Mark Pizzolato

Post by Paul Koning
KMC/DUP are used for the 2780 emulation feature, which is a rather
obscure layered product -- I don't know anything about it.

First, I should say that my knowledge of RSTS/E is limited to a half day of
trying it out. I appreciate your telling me that you don't know anything about
this particular device either. It may seem insignificant, but it helps me
categorize things as I learn to know if I should know it or it is actually obscure.

The KMC/DUP may have been useful for 2780 emulation with real hardware,
but it is ONLY there for simulator to simulator DECnet connections now.

I wonder if it would actually work with 2780 emulation -- connecting the SIMH emulated DUP with whatever a 2780 ports looks like in a simulated IBM/360.

No. The KMC emulation has some hooks for non-DECnet, but the DUP
doesn't. It knows enough to parse the commands to go into the other
modes, but doesn't know what to do with them.

The KMC emulation is a functional emulator; although it requires a
sensible microcode file (COMMIOP/DUP) to be loaded, it doesn't execute
the microcode. There's no point in emulating the KMC-11
microprocessor. (The check for microcode version is partly so the OS
goes thru the load process, and partly so that if someone tries to load,
say COMMIOP/DZ ucode, the failure will be obvious.) There are some
private hooks between the KMC and DUP emulations to make things work
reasonably efficiently.

DECnet uses DDCMP, which is a character oriented counted-length
protocol. Bisync is a character-stuffing protocol. The bit-stuffing
protocols (e.g. SDLC, X.25) are supported by the real KDP, but not by
the emulation.

The KDP emulation can be told to introduce CRC errors once in a while,
so you can watch error recovery work and enjoy the network management tools.

Extending the KMC emulation to deal with other ucodes and/or protocols
is certainly possible. But non-trivial. Happy coding.

I did test the KDP emulation with DECnet on the PDP-11 (rsx) as well as
VAX and the KS10.

Post by Paul Koning
As for DECnet, yes indeed. Note though that RSTS/E does not support that combination for DECnet; the only DECnet devices it supports are DMC11 (from the start), DMV11 and DMP11 (V7.1 and up), Ethernet (V9.3 and up), and software DDCMP on terminal ports (not clearly supported but present if you dig enough (V9.6 to some extent, V10.0 in cleaner form). So synchronous DDCMP is DMC and friends only (unless you count the Pro printer/console USART work I did as a midnight project in V9.6).
paul
_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh

Christian Gauger-Cosgrove

2015-12-31 22:34:11 UTC

Post by Will Senn
I am not able to figure out what devices to enable in SimH PDP-11 to get
multiple telnet connections in RSTS/E 9.6.
SET CONSOLE TELNET=10000
I am able to telnet into port 10000. It works as a login terminal no problem.

That's your "master" console device. If that telnet session
disconnects your sim will halt. (Make sure you add a buffer if you
want to be safe.)

Post by Will Senn
But, then I also tried to set up some DZ11 lines to support additional
SET DZ ENABLE
SET DZ LINES=8
ATTACH DZ 10001
SHOW DZ
but these don't seem to be picked up by RSTS/E. SimH let's me connect via
telnet to ports 10001-10007, but RSTS/E does not respond in the telnet
session. I reviewed my sysgen for RSTS/E and it doesn't appear to have a
DZ11 peripheral configuration section. My sense is that RSTS/E doesn't
support DZ11s.

Like Mark Pizzolato stated, the eight DZV11 lines will be on port
10001. Add "-am" options to the attach statement to make your life
easier for the actual configuration of the ports. (I'll cover that
later.)

Post by Will Senn
Accept Peripheral defaults ? <N >
---snip disk drives, paper tape, etc.
DMC11's/DMR11's ? <00>
DMV11's/DMP11's ? <00>
IBM 3271 or 2780/3780 simultaneous links ? <00>
RJ2780 support ? <N >
In looking at the
AA-2669J-TC_RSTS-E_System_Installation_and_Update_Guide.pdf file, page 49.
It has this to say about the IBM 3271 or 2780/3780 option (sounds like an
Explanation - Each KMC-11 microprocessor controls one DUP11 synchronous line
interface to the 3271 or 2780/3780 host... and so on.
KMC/DUP are used for the 2780 emulation feature, which is a rather obscure layered product -- I don't know anything about it.

Both of those layered products let you connect your RSTS/E PDP-11 to
an IBM System/370 mainframe via BISYNC and have your '11 pretend it is
either a 3271 or an RJE station. I'm particularly interested in
finding the the RJE one, and the 3271 one; since I fool around with
Hercules a lot and I'd love to try out RJE via a PDP-11 (and the 3271
product sounds interesting as well).

Post by Will Senn
As of RSTS V9.0, if memory serves, terminal configuration is no longer set during Sysgen. Instead, the monitor contains drivers for each supported terminal interface, and these are loaded at startup according to what hardware was found.

Correct, terminal configuration is done in the startup command file:
SY:[0,1]START.COM

So, let's do the whole thing of setting up RSTS/E to use the DZV11
ports. I'm using RSTS/E V10.1-L, and I'm too lazy to pull up V9.6, but
the syntax/process to set up the ports are the same in both:

First of all inside of your simulator configuration:
set TTI 8B ; Full 8-bit transmission, needed for VT-100 to work right
set TTO 8B ; As above
<...>
set CONSOLE TELNET=10000 ; Connect master console (TTI/TTO devices) to
telnet port
; set CONSOLE TELNET=LOG=conlog.txt ; Uncomment this if you want a
log of your terminal session
set CONSOLE TELNET=BUFFERED=1048576 ; Buffer the console (in case your
telnet disconnects)

As a fun suggestion, try running the RSTS SYSGEN after setting both
TTI and TTO to 8B mode. The results are nifty:
<Loading Image...

>
$ CREATE/ACCOUNT/NAME="W. Senn"/TEMPLATE=_SY:[1,2] [1,4]
$ BYE
<extraneous output snipped for brevity>

HELLO 1,4
$ SET TERMINAL/DEVICE_TYPE=VT100
$ SHOW DEVICES/ALL
Device _DV0: Status: Disabled by INIT
<extraneous output snipped for brevity>
Device _KB12: (KBG0:) Control DZ0:0 CSR 760100 Status: Restricted
Device _KB13: (KBG1:) Control DZ0:1 CSR 760100 Status: Restricted
<More DZ11 lines output trimmed because I configured 64 lines;
UNIBUS for the win>
Device _KB74: (KBG62:) Control DZ7:6 CSR 760170 Status: Restricted
Device _KB75: (KBG63:) Control DZ7:7 CSR 760170 Status: Restricted
<extraneous output snipped for brevity>

Post by Will Senn
Write down, or otherwise note the KBG#: for each of the DZV11 lines.

$ COPY SY:[0,1]START.COM [1,4]START.COM
[File [0,1]START .COM copied to [1,4]START .COM]
$ COPY START.COM START.BCK
[File START .COM copied to [1,4]START .BCK]
$ EDIT START.COM
1 $ !
*CH
set terminal kbg0:/permanent/noautobaud/speed=9600/device_type=VT100
set terminal kbg1:/permanent/noautobaud/speed=9600/device_type=VT100
<repeat until you've setup all your lines>
set terminal kbg63:/permanent/noautobaud/speed=9600/device_type=VT100
! DZV lines as VT-100 at 9600 baud

Post by Will Senn
Feel free to change the device type of KB0: to a VT100 if you wish.
Return to EDT's line mode, and exit.

<Ctrl-Z>
*exit
START .COM 329 lines

$
$ COPY START.COM _SY:[0,1]START.COM
OK to replace existing file DR0:[0,1]START .COM ? YES
[File START .COM copied to [0,1]START .COM]
$

Post by Will Senn
Restart your RSTS/E system.

$ RUN $SHUTUP

Once the system is restarted, telnet into the DZV11 port, and you
should have working DZV11 lines. Personally however, I find that the
DHV11/DHQ11 is a much better terminal multiplexer. Especially since
modem control actually works on them from inside RSTS/E. And
consequently when you logoff or if your telnet disconnects when
connected to a DHV11/DHQ11 line setup as a "/DIALUP" line from RSTS/E,
the it will disconnect your telnet session (in the first case), or
automatically log you out (in the second case).

I feck around with RSTS/E *a lot* so feel free to bug me as much as you want.

Cheers,
Christian

--
Christian M. Gauger-Cosgrove
STCKON08DS0
Contact information available upon request.

d***@caltech.edu

2016-01-02 00:11:29 UTC