[HECnet] DMC11 in next simh version... looks nice, and question about TOPS-10

[Rob Jarratt]

-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Paul_Koning at Dell.com
Sent: 05 January 2013 20:12
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] DMC11 in next simh version... looks nice, and
question
about TOPS-10


On Jan 5, 2013, at 4:32 AM, Rob Jarratt wrote:



-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-
hecnet at Update.UU.SE]
On Behalf Of Paul_Koning at Dell.com
...
3. The first thing RSTS does to the DMC after resetting it is to set
RUN
and
ROMI in SEL0, with a magic value in SEL6.   What that does (according
to
the
driver comments) is to put the DMC microcontroller in a state where
it executes the opcode in SEL6 every clock tick.   That instruction is
a "move
line
status register to BSEL3".   The RSTS/E driver uses this to test for
DSR;
it
takes no further startup action until DSR has been set for 2 seconds.
So
I
added code to pdp11_dmc.c to handle this magic (it simply sets the
DSR bit unconditionally if it sees ROMI and the magic opcode value).
With that, RSTS/E will complete the device startup.


As I have only tested this with VMS I have not seen the VMS driver do
this so the emulation doesn't do it. It sounds like this could be a
good way for the OS to know that the other end is up and so it can
start doing a Master Clear and sending messages. This might help with
the other problem you mention below. It might be good to change the
code to set the status of DSR according to whether the TCP connection
is open. What does the RSTS driver do once it has seen the DSR set for
2 seconds, does it just clear the ROM INPUT bit? Can you send me your
code?

Here's the first step:

	MOV	R0,R3		;RESTORE DEVICE CSR POINTER
	BIS	#MCLR,(R3)	;MASTER CLEAR THE DMC11 AND TURN DTR
ON.
	MOV	#DSPDSR,SEL6(R3)	;SET INSTRUCTION TO MOVE DSR
TO BSEL3
	MOVB	#DMCRUN,BSEL1(R3)	;HAVE DMC EXECUTE SEL6 EVERY
300 NSEC

definitions:

DMCRUN	=	202		;WHEN MOVED TO BSEL1 THE DMC
EXECUTES THE
				;INSTRUCTION IN SEL6 EVERY 300 NSEC.
DSPDSR	=	021263		;MOVE LINE UNIT STATUS TO BSEL3
				;   OUT   IBUS, MODEM CSR, BSEL3



Actually I meant the code you added to the pdp11_dmc.c file, but the above
is still useful



By the way, the background for this can be found in the KMC-11 manual.
Next, once DSR has been seen on for 2 seconds, it does another master
clear, then the Base In operation.

Since Master Clear needs to drop the connection, I don't think that tying
DSR
to the connection being alive will work.   It does seem like an obvious
thing to
do, but that second master clear suggests it isn't the way to go.


Not sure I follow. It seems to be that the driver is using DSR just to tell
it that the line is up. Of course if we use Master Clear to close the
connection then that would not work, but if we didn't close the connection
then it would work. Wouldn't it?







4. Now I see a "circuit up" message from DECnet, but that is followed
by some combination of "circuit down, listener timeout" and "circuit
down, unexpected packet type".   After staring at packet traces ("set
dmc0
debug=data") for a while, the reason is obvious: when one side of the
connection is started and the other is not yet started, one side
sends a packet and the other side discards that.   You can't do that.
DDCMP is a connection oriented protocol: if you discard a packet
that's a protocol violation, and DECnet will absolutely positively
get bent out of shape because it assumes the DDCMP implementation
will not do such a thing.

What has to be done is that a transmit remains pending if the other
end is not able to receive it.   That can happen because there is no
connection,
or
because the other end hasn't turned its DMC on yet, or it's on but it
currently
doesn't have receive buffers.


The code should already do this. It will not try to send a buffer if
there isn't an open socket to the other side. See the
dmc_get_transmit_socket() routine. It may not be perfect but that is
the best I can think of when there isn't a single permanent cable
between the two sides. On VMS this seems to work without any circuit
down messages.

Ok, but then why did I see a "Discarding received data while controller is
not
running" message?   That's the problem, I believe.



I don't often set the level of tracing that would give this message, but
even when I have, I have not seen this message. It happens if the receiving
end has not made any buffers available yet. There is not enough protocol
between the two ends to do it correctly, we would probably have to implement
DDCMP. I would argue that in practice it does not have a significant effect,
circuits do get established and DECnet can operate over the link without
seeing any errors, at least on VMS, not sure about other OSs which may
implement their drivers differently. I would have to test a bit more to be
fully sure of all this though as I usually start both ends more or less at
the same time, it might happen if there is a significant delay between
starting DECnet at each end.

Regards

Rob