[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: 04 January 2013 22:15
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] DMC11 in next simh version... looks nice, and
question
about TOPS-10


On Jan 2, 2013, at 4:33 PM, Jordi Guillaumes i Pons wrote:

Hello,

The upcoming SIMH version (4.0) comes with a virtual DMC11. It has been
merged to the head branch in the git repository, so I have been playing
with
it a little bit. The simh team has done an aswesome work again, so kudos
for Bob, Mark and all the others... It seems the DMCx are supported in
pdp10, pdp11 and the VAXen.

I grabbed the current code (from git) to try this on RSTS/E.

Some results:

1. The stock build does not work at all (on my Mac).   It never gets a boot
prompt.   In fact, the simulator is utterly wedged: it doesn't respond to
control/E or SIGTERM.   I have to "kill -9" it to make it go away.   GDB
shows
that it's sitting on some semaphore wait.

2. If I build with NOASYNCH=1, the pdp11 simulation works.   Now on to the
DMC emulation...

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?




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.



Similarly, master clear then RUN (DMC
restart) needs to synchronize with the other end, to simulate the effect
of
the DDCMP initialization sequence.


As you know, there is no DDCMP under the covers. It would be nice to add it,
but is presumably a fairly significant effort. You seem to suggest that some
other kind of synchronisation could be done with the other end in the
absence of DDCMP, I am not sure what exactly you are suggesting here, can
you explain?

Regards

Rob



I'll take a look at how hard this would be to fix.   It'll probably take a
fair
amount of work...

	paul