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. 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. Similarly, master clear then RUN (DMC restart) needs to synchronize with the other end, to simulate the effect of the DDCMP initialization sequence. I'll take a look at how hard this would be to fix. It'll probably take a fair amount of work... paul