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

[Timothe Litt]

On 02-Jan-16 14:20, Paul Koning wrote:
>> On Jan 2, 2016, at 6:20 AM, Johnny Billquist <bqt at softjar.se> wrote:
>>
>> On 2016-01-01 23:01, Paul Koning wrote:
>>>> On Jan 1, 2016, at 4:56 PM, Will Senn <will.senn at gmail.com> wrote:
>>>>
>>>>
>>>>
>>>> On 12/31/15 2:10 PM, Will Senn wrote:
>>>>> 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).

> 	paul
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4994 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20160102/59c038ab/attachment.bin>