Re: [Simh] Configuring DMC11 Devices

[Paul Koning]

> On Jan 4, 2016, at 2:38 PM, Paul Koning  wrote:
> 
> It looks like the problems RSTS is having with DMC/DMR is due to unexpected 
> behavior of the master clear bit.  It's documented as self-clearing, so the 
> driver sets it and then subsequently assumes it will read as cleared.  That 
> isn't actually happening correctly, at least not if two accesses are close 
> together:
> 
> DBG(4466384761)> DMC REG: dmc_wr(DMC0), addr=0x003fe038, SEL0, 
> newdata=0x4000, olddata=0x8200
> DBG(4466384761)> DMC REG: DMC0: Setting SEL0 (0x4000) MCLR 
> DBG(4466384764)> DMC REG: dmc_wr(DMC0), addr=0x003fe038, BSEL0, newdata=23, 
> olddata=0x00
> DBG(4466384764)> DMC REG: DMC0: Setting SEL0 (0x4023) MCLR RQI 
> 
> This is the driver doing a master clear, quickly followed by a Request In 
> asking to set the Base address.  That second operation is a byte write to 
> BSEL0, and it relies on MCLR being either write-only, or at least 
> self-clearing fast enough.  In this case, clearly that is not working; MCLR 
> is still set so the byte write sets not just RQI and BASEI, but also MCLR -- 
> so RDYI is never set, the driver times out, and the cycle repeats.
> 
> This patch (hack?) fixes the issue, and now my two cross-connected DMCs 
> successfully start:
> 
> diff --git a/PDP11/pdp11_dmc.c b/PDP11/pdp11_dmc.c
> index e0e0111..6034683 100644
> --- a/PDP11/pdp11_dmc.c
> +++ b/PDP11/pdp11_dmc.c
> @@ -3592,7 +3592,7 @@ else {
> 
> if ((dmc_getsel(reg) == 0) || (dmc_getsel(reg) == 1)) {/* writes to SEL0 and 
> SEL2 are actionable */
> if (0 == controller->dmc_wr_delay) {/* Not waiting? */
> -controller->dmc_wr_delay = 10;  /* Wait a bit before acting on 
> the changed register */
> +controller->dmc_wr_delay = 1;  /* Wait a bit before acting on 
> the changed register */
> sim_activate_abs (controller->unit, controller->dmc_wr_delay);
> }
> }

It would be nice to get this change into the official code, because right now 
that's the only thing keeping the DMC from working with RSTS.  (I just checked, 
after being prompted by R. Voorhorst).

paul


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Configuring DMC11 Devices

[Timothe Litt]

On 05-Jan-16 20:23, Paul Koning wrote:
> The thing to keep in mind is that BSEL1 is implemented in logic; it's not 
> like the higher numbered registers that are just a dual ported memory 
> manipulated by the KMC11 microcode.  The KMC11 reference manual spells some 
> of this out; for example, you can't make sense of MSTEP and ROMI references 
> in the driver from the DMC11 manual, you need the KMC11 manual for that.
>
>   paul
>
>
IIRC the DMR tech manual has more detail than the DMC.  The KMC11 manual
is best read with the prints in sight and a TTL data book nearby. 
Unless you remember the formulae for timing resistors/caps on TTL 7412x
and other arcana.

The KMC11 functional emulation that I did handles single-stepping the
micro-instructions used by the OS for reading and writing the
instruction and data RAM.  (Well, at least the ones I knew about.  I
didn't test under RSTS.)  See kmc_doMicroinstruction() in pdp11_kmc.c. 
The emulation went to some trouble to support microcode load and dump,
and to present a moving microPC.

I believe you'll also find that I made master clear immediate; as in
it's never set in the register.  So apparently Mark didn't take that
part of the KMC when he forked the DMC/DMR.  Again, the KMC emulation
emulates the COMMIOP-DUP microcode, not a general KMC.

Although I provided some advice, I don't think I ever took a close look
at the DMC/DMR code; I certainly never reviewed or validated it, though
debugging the DMR on the KS10 was (and is) on my "needs a round TUIT" list.

All assuming other fingers haven't been in the KMCit's been a couple
of years since I touched that code.






smime.p7s
Description: S/MIME Cryptographic Signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Configuring DMC11 Devices

[Mark Pizzolato]

On Tuesday, January 5, 2016 at 5:23 PM, Paul Koning wrote:
> > On Jan 5, 2016, at 4:59 PM, Mark Pizzolato  wrote:
> >
> > ECOCHK: MOV R0,-(SP);PRESERVE THE UNIT # *2
> > CLR R0  ;SET A STARTING ADDRESS
> > MOV #3,R4   ;TWO CHANCES TO MATCH MICRO-CODE (2
> BITS)
> > MOV #HICOD,R1   ;HIGH SPEED MICRO CODE ADDRESS
> > MOV #LOCOD,R2   ;LOW SPEED MICRO CODE ADDRESS
> > 10$:MOVB#ROMI,BSEL1(R3) ;SET UP FOR A ROMI
> > MOV #100400,-(SP)   ;SET THE INSTRUCTION TO USE
> > BIS R0,(SP) ;  AND NOW THE ADDRESS
> > MOV (SP)+,SEL6(R3)  ;PUT THE INSTRUCTION IN,
> > BISB#MSTEP!ROMI,BSEL1(R3) ;  AND EXECUTE IT
> > MOVB#ROMO,BSEL1(R3) ;NOW CLEAR THE BITS
> > MOV SEL6(R3),R5 ;GET THE MICRO-CODE FROM THAT ADDRESS
> > CLRBBSEL1(R3)   ;AND CLEAR THE CSR
> > CMP R5,(R1)+;MATCH THE HIGH ONE?
> > BEQ 20$ ; YES, SO CONTINUE
> > BIC #1,R4   ;NOT HIGH SPEED, SO CLEAR THE HIGH SPEED
> BIT
> > 20$:CMP R5,(R2)+;MATCH THE LOW ONE?
> > BEQ 30$ ; YES, SO CONTINUE
> > BIC #2,R4   ;NOT LOW SPEED SO CLEAR THE LOW SPEED
> BIT
> > 30$:TST R4  ;DID EITHER ONE MATCH?
> > BEQ 100$;NEITHER ONE MATCHES, SO QUIT RIGHT
> NOW
> >
> > We've got 5 instructions in a row referencing the device registers.  A 
> > write,
> a read-modify-write, a write, a read and a write.
> >
> > I'm a software guy who knows how to simulate things.  I don't know how
> > the real hardware works, but unless there is some sort of interlocked
> > behavior with the DMC microcontroller it would seem that a sufficiently fast
> > PDP11 would get ahead of the DMC.  No?
> 
> The thing to keep in mind is that BSEL1 is implemented in logic; it's not like
> the higher numbered registers that are just a dual ported memory
> manipulated by the KMC11 microcode.  The KMC11 reference manual spells
> some of this out; for example, you can't make sense of MSTEP and ROMI
> references in the driver from the DMC11 manual, you need the KMC11
> manual for that.

Along with Tim's strong declaration that the DMC/DMR devices are merely 
KMC devices with code running from RAM instead of ROM.

So immediate completion makes sense, but it certainly wasn't how those 
activities 
were interpreted when this work was done originally.  This fact along with the 
detail that Tim points out that the KMC is faster than the actual bottleneck 
(the Unibus) will reliably make the BSEL1 operations complete in one 
instruction 
without regard to the speed of the PDP11 CPU.

Thanks.

- Mark

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Configuring DMC11 Devices

[Paul Koning]

> On Jan 5, 2016, at 4:59 PM, Mark Pizzolato  wrote:
> 
> On Monday, January 4, 2016 at 12:06 PM, Paul Koning wrote:
>>> On Jan 4, 2016, at 2:53 PM, Mark Pizzolato  wrote:
>>> I vaguely remember that something else depends on how it is currently
>>> implemented.  The wait delay was added to accommodate the fact that
>>> something didn't expect immediate response.  A delay of 1 is essentially the
>>> same as no delay.
>>> 
>>> It is hard to imagine that the OS driver would expect that the device would
>>> complete some operation in one instruction time.  This would tend to fail as
>>> newer models of CPU were implemented which used the same peripheral
>>> hardware, no?
>> 
>> All I can say is that it does work on real hardware.
>> 
>> The manual says that the bit is "self-clearing".  That isn't the same words 
>> as
>> the more common "write only" but it implies roughly the same thing.  The
>> driver definitely does not expect the whole master clear process to complete
>> in a few instruction times; it patiently waits for RUN to become set.  But it
>> DOES expect that MCLR does not read back as set, not even very quickly
>> after it was set by the driver.
>> 
>> So maybe the thing to do is have the process master clear action be started
>> at the CSR write rather than delayed (while other CSR operations can remain
>> delayed) so that at least the clear_master_clear part is done right away.
> 
> Actually it seems that any number of things must consistently complete in one 
> or at most a couple of instructions.  If you look at the RSTS ROM checking 
> code:
> 
> ECOCHK:   MOV R0,-(SP);PRESERVE THE UNIT # *2
>   CLR R0  ;SET A STARTING ADDRESS
>   MOV #3,R4   ;TWO CHANCES TO MATCH MICRO-CODE (2 BITS)
>   MOV #HICOD,R1   ;HIGH SPEED MICRO CODE ADDRESS
>   MOV #LOCOD,R2   ;LOW SPEED MICRO CODE ADDRESS
> 10$:  MOVB#ROMI,BSEL1(R3) ;SET UP FOR A ROMI
>   MOV #100400,-(SP)   ;SET THE INSTRUCTION TO USE
>   BIS R0,(SP) ;  AND NOW THE ADDRESS
>   MOV (SP)+,SEL6(R3)  ;PUT THE INSTRUCTION IN,
>   BISB#MSTEP!ROMI,BSEL1(R3) ;  AND EXECUTE IT
>   MOVB#ROMO,BSEL1(R3) ;NOW CLEAR THE BITS
>   MOV SEL6(R3),R5 ;GET THE MICRO-CODE FROM THAT ADDRESS
>   CLRBBSEL1(R3)   ;AND CLEAR THE CSR
>   CMP R5,(R1)+;MATCH THE HIGH ONE?
>   BEQ 20$ ; YES, SO CONTINUE  
>   BIC #1,R4   ;NOT HIGH SPEED, SO CLEAR THE HIGH SPEED BIT
> 20$:  CMP R5,(R2)+;MATCH THE LOW ONE?
>   BEQ 30$ ; YES, SO CONTINUE
>   BIC #2,R4   ;NOT LOW SPEED SO CLEAR THE LOW SPEED BIT
> 30$:  TST R4  ;DID EITHER ONE MATCH?
>   BEQ 100$;NEITHER ONE MATCHES, SO QUIT RIGHT NOW
> 
> We've got 5 instructions in a row referencing the device registers.  A write, 
> a read-modify-write, a write, a read and a write.
> 
> I'm a software guy who knows how to simulate things.  I don't know how the 
> real hardware works, but unless there is some sort of interlocked behavior 
> with the DMC microcontroller it would seem that a sufficiently fast PDP11 
> would get ahead of the DMC.  No?

The thing to keep in mind is that BSEL1 is implemented in logic; it's not like 
the higher numbered registers that are just a dual ported memory manipulated by 
the KMC11 microcode.  The KMC11 reference manual spells some of this out; for 
example, you can't make sense of MSTEP and ROMI references in the driver from 
the DMC11 manual, you need the KMC11 manual for that.

paul

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Configuring DMC11 Devices

[Timothe Litt]

> On Monday, January 4, 2016 at 12:06 PM, Paul Koning wrote:
>>> On Jan 4, 2016, at 2:53 PM, Mark Pizzolato  wrote:
>>> I vaguely remember that something else depends on how it is currently
>>> implemented.  The wait delay was added to accommodate the fact that
>>> something didn't expect immediate response.  A delay of 1 is essentially the
>>> same as no delay.
>>>
>>> It is hard to imagine that the OS driver would expect that the device would
>>> complete some operation in one instruction time.  This would tend to fail as
>>> newer models of CPU were implemented which used the same peripheral
>>> hardware, no?
>> All I can say is that it does work on real hardware.
>>
>> The manual says that the bit is "self-clearing".  That isn't the same words 
>> as
>> the more common "write only" but it implies roughly the same thing.  The
>> driver definitely does not expect the whole master clear process to complete
>> in a few instruction times; it patiently waits for RUN to become set.  But it
>> DOES expect that MCLR does not read back as set, not even very quickly
>> after it was set by the driver.
>>
>> So maybe the thing to do is have the process master clear action be started
>> at the CSR write rather than delayed (while other CSR operations can remain
>> delayed) so that at least the clear_master_clear part is done right away.
> Actually it seems that any number of things must consistently complete in one 
> or at most a couple of instructions.  If you look at the RSTS ROM checking 
> code:
>
> ECOCHK:   MOV R0,-(SP);PRESERVE THE UNIT # *2
>   CLR R0  ;SET A STARTING ADDRESS
>   MOV #3,R4   ;TWO CHANCES TO MATCH MICRO-CODE (2 BITS)
>   MOV #HICOD,R1   ;HIGH SPEED MICRO CODE ADDRESS
>   MOV #LOCOD,R2   ;LOW SPEED MICRO CODE ADDRESS
> 10$:  MOVB#ROMI,BSEL1(R3) ;SET UP FOR A ROMI
>   MOV #100400,-(SP)   ;SET THE INSTRUCTION TO USE
>   BIS R0,(SP) ;  AND NOW THE ADDRESS
>   MOV (SP)+,SEL6(R3)  ;PUT THE INSTRUCTION IN,
>   BISB#MSTEP!ROMI,BSEL1(R3) ;  AND EXECUTE IT
>   MOVB#ROMO,BSEL1(R3) ;NOW CLEAR THE BITS
>   MOV SEL6(R3),R5 ;GET THE MICRO-CODE FROM THAT ADDRESS
>   CLRBBSEL1(R3)   ;AND CLEAR THE CSR
>   CMP R5,(R1)+;MATCH THE HIGH ONE?
>   BEQ 20$ ; YES, SO CONTINUE  
>   BIC #1,R4   ;NOT HIGH SPEED, SO CLEAR THE HIGH SPEED BIT
> 20$:  CMP R5,(R2)+;MATCH THE LOW ONE?
>   BEQ 30$ ; YES, SO CONTINUE
>   BIC #2,R4   ;NOT LOW SPEED SO CLEAR THE LOW SPEED BIT
> 30$:  TST R4  ;DID EITHER ONE MATCH?
>   BEQ 100$;NEITHER ONE MATCHES, SO QUIT RIGHT NOW
>
> We've got 5 instructions in a row referencing the device registers.  A write, 
> a read-modify-write, a write, a read and a write.
>
> I'm a software guy who knows how to simulate things.  I don't know how the 
> real hardware works, but unless there is some sort of interlocked behavior 
> with the DMC microcontroller it would seem that a sufficiently fast PDP11 
> would get ahead of the DMC.  No?
There is no interlock.  The KMC11 is faster than the Unibus.  So fast
that KMC ucode has cases where it has to read its CSRs twice to make
sure it has a stable value.  It's a strange beast.

IIRC, master clear is a hardware reset that triggers a one-shot (don't
have prints handy, but probably at most a few usec).  This code is
single-stepping the KMC while forcing some microinstructions. 
Basically, it forces the KMC's CPU to execute instructions from a
register instead of from ROM.  I emulated the interesting
microinstructions in the KDP. 

The microdiags can run for a while, but there's a 'done' bit to check
and a spec for how long to wait - I think ~10 msec.  The KMC clock was
something like 200 nsec; the Unibus is asynchronous, but the best one
can do is about 1 usec.  Because many of the device drivers weren't
updated when the DMR came out, there's a switch to disable the
microdiags.  That allows the old DMC drivers to work.  (Assuming the
hardware is OK.)  OTOH, there are drivers that insist on the DMR &
microdiags.  So the switch needs to be emulated.

No matter how fast the CPU became, the Unibus was limited by electrical
considerations (and existing peripherals).

And before someone asks, the DMC/DMR are KMC11s with the RAM microcode
store replaced by ROMs.  And an paired line card (the KMC talks to it on
a private bus.) 

The DMR supported microdiagnostics, DDCMP 4.0,  and half-duplex DDCMP. 
The DMC did none of the above, but provided increased entertainment by
having a few bugs.  I think the latter were most evident using the
custom coax cable with the 1Mbit line card. 

Both had various options for interfaces - rs232, v.34, etc.  And each
has two versions of the processor module - different microcodes for
local (internal modem with coax) and remote (external modem to ph

Re: [Simh] Configuring DMC11 Devices

[Mark Pizzolato]

On Monday, January 4, 2016 at 12:06 PM, Paul Koning wrote:
> > On Jan 4, 2016, at 2:53 PM, Mark Pizzolato  wrote:
> > I vaguely remember that something else depends on how it is currently
> > implemented.  The wait delay was added to accommodate the fact that
> > something didn't expect immediate response.  A delay of 1 is essentially the
> > same as no delay.
> >
> > It is hard to imagine that the OS driver would expect that the device would
> > complete some operation in one instruction time.  This would tend to fail as
> > newer models of CPU were implemented which used the same peripheral
> > hardware, no?
> 
> All I can say is that it does work on real hardware.
> 
> The manual says that the bit is "self-clearing".  That isn't the same words as
> the more common "write only" but it implies roughly the same thing.  The
> driver definitely does not expect the whole master clear process to complete
> in a few instruction times; it patiently waits for RUN to become set.  But it
> DOES expect that MCLR does not read back as set, not even very quickly
> after it was set by the driver.
> 
> So maybe the thing to do is have the process master clear action be started
> at the CSR write rather than delayed (while other CSR operations can remain
> delayed) so that at least the clear_master_clear part is done right away.

Actually it seems that any number of things must consistently complete in one 
or at most a couple of instructions.  If you look at the RSTS ROM checking code:

ECOCHK: MOV R0,-(SP);PRESERVE THE UNIT # *2
CLR R0  ;SET A STARTING ADDRESS
MOV #3,R4   ;TWO CHANCES TO MATCH MICRO-CODE (2 BITS)
MOV #HICOD,R1   ;HIGH SPEED MICRO CODE ADDRESS
MOV #LOCOD,R2   ;LOW SPEED MICRO CODE ADDRESS
10$:MOVB#ROMI,BSEL1(R3) ;SET UP FOR A ROMI
MOV #100400,-(SP)   ;SET THE INSTRUCTION TO USE
BIS R0,(SP) ;  AND NOW THE ADDRESS
MOV (SP)+,SEL6(R3)  ;PUT THE INSTRUCTION IN,
BISB#MSTEP!ROMI,BSEL1(R3) ;  AND EXECUTE IT
MOVB#ROMO,BSEL1(R3) ;NOW CLEAR THE BITS
MOV SEL6(R3),R5 ;GET THE MICRO-CODE FROM THAT ADDRESS
CLRBBSEL1(R3)   ;AND CLEAR THE CSR
CMP R5,(R1)+;MATCH THE HIGH ONE?
BEQ 20$ ; YES, SO CONTINUE  
BIC #1,R4   ;NOT HIGH SPEED, SO CLEAR THE HIGH SPEED BIT
20$:CMP R5,(R2)+;MATCH THE LOW ONE?
BEQ 30$ ; YES, SO CONTINUE
BIC #2,R4   ;NOT LOW SPEED SO CLEAR THE LOW SPEED BIT
30$:TST R4  ;DID EITHER ONE MATCH?
BEQ 100$;NEITHER ONE MATCHES, SO QUIT RIGHT NOW

We've got 5 instructions in a row referencing the device registers.  A write, a 
read-modify-write, a write, a read and a write.

I'm a software guy who knows how to simulate things.  I don't know how the real 
hardware works, but unless there is some sort of interlocked behavior with the 
DMC microcontroller it would seem that a sufficiently fast PDP11 would get 
ahead of the DMC.  No?

In any case, in order to meet the requirements of this instruction stream it 
seems that maintenance activities (which these are) need to be done without 
delay.  
I'll work on that.

- Mark

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Configuring DMC11 Devices

[Mark Pizzolato]

On Monday, January 4, 2016 at 9:38 PM, Christian Gauger-Cosgrove wrote:
> On 5 January 2016 at 00:25, Mark Pizzolato  wrote:
> > I don't see the " XM4: is missing ECO's, but will still function." 
> > Messages...
> Can you explain?
> >
> There's only one DMR11 and one DMC11 configured. When you boot up,
> you'll see:
> sim> b rq
> 
> XM1: is missing ECO's, but will still function.

AAHHH!!!  How easy for it to be the first output during the boot.  I only 
looked where the network seemed to be coming up.

Thanks.

> Both of the devices are ATTACHed. So the DMR11 doesn't error, the
> DMC11 (DMC1 to SIMH; XM1 to RSTS/E) still shows the ECO message. I'm
> still running git commit ca4a6901; I have not applied Paul Koning's
> patch yet.
>
> Comment out the "attach DMCn" lines in the config and you'll get both
> errors:
> sim> b rq
> 
> Device XM0: internal micro-diagnostic failure - device disabled.
> XM1: is missing ECO's, but will still function.

Once I get the clean ECO check in place I'll also address what Paul noticed but 
probably more along the lines of what we discussed rather than his initial shot 
at fixing it.

- Mark
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Configuring DMC11 Devices

[Christian Gauger-Cosgrove]

On 5 January 2016 at 00:25, Mark Pizzolato  wrote:
> Thanks for the image and config.
>
You're quite welcome.


> I don't see the " XM4: is missing ECO's, but will still function." 
> Messages...  Can you explain?
>
There's only one DMR11 and one DMC11 configured. When you boot up, you'll see:
sim> b rq

XM1: is missing ECO's, but will still function.


RSTS V10.1-L RSTS   (DU0) INIT V10.1-0L


Both of the devices are ATTACHed. So the DMR11 doesn't error, the
DMC11 (DMC1 to SIMH; XM1 to RSTS/E) still shows the ECO message. I'm
still running git commit ca4a6901; I have not applied Paul Koning's
patch yet.

Comment out the "attach DMCn" lines in the config and you'll get both errors:
sim> b rq

Device XM0: internal micro-diagnostic failure - device disabled.
XM1: is missing ECO's, but will still function.


RSTS V10.1-L RSTS   (DU0) INIT V10.1-0L


Regards,
Christian
-- 
Christian M. Gauger-Cosgrove
STCKON08DS0
Contact information available upon request.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Configuring DMC11 Devices

[Mark Pizzolato]

Hi Christian,

Thanks for the image and config.

I don't see the " XM4: is missing ECO's, but will still function." Messages...  
Can you explain?

Thanks.

- Mark

On Monday, January 4, 2016 at 8:11 PM, Christian wrote:
> Forgot to mention: The password for account [1,2] is "operator"; the account
> [1,4] is also created, using [1,2] as a template; it also has the password
> "operator".
> 
> And just for clarity's sake: The system has the DECnet address of 11.94, and
> node name of RSTS10. It knows of two other systems (provide them yourself
> or change their definitions), namely: TESTME:: (at
> 11.70) and DRAGON:: (at 11.84).


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Configuring DMC11 Devices

[Christian Gauger-Cosgrove]

Forgot to mention: The password for account [1,2] is "operator"; the
account [1,4] is also created, using [1,2] as a template; it also has
the password "operator".

And just for clarity's sake: The system has the DECnet address of
11.94, and node name of RSTS10. It knows of two other systems (provide
them yourself or change their definitions), namely: TESTME:: (at
11.70) and DRAGON:: (at 11.84).

And here's the Dropbox link to the .7z file again just in case it gets
lost in all the noise:




Regards,
Christian


On 4 January 2016 at 23:07, Christian Gauger-Cosgrove
 wrote:
> I've setup a small RSTS/E 10.1-L system with DECnet; it's kitted out
> with a DELUA, DMR11, and a DMC11.
>
> Here's the output of "ncp show known nodes" and "ncp show known circuits":
> $ ncp show known nodes
> Known Node Volatile Summary as of 4-JAN-16 22:56:38
>
> Executor Node = 11.94 (RSTS10)
>
> State  = On
> Identification = DECnet/E V4.1
> Active Links   = 0
>
> Remote Node = 11.70 (TESTME)
>
> State  = Unreachable
>
> Remote Node = 11.84 (DRAGON)
>
> State  = Unreachable
> $ ncp show known circuits
> Known Circuit Volatile Summary as of 4-JAN-16 22:57:04
>
> Circuit = DMR-0
>
> State  = On-Starting
>
> Circuit = DMC-1
>
> State  = Off
>
> Circuit = UNA-0
>
> State  = On
> $
> The DMC11 is only off because it's providing the constant barrage of
> circuit initialization failures; on start up the circuit state is on.
>
>
> And here is a Dropbox link to a 7-Zip archive of the system disk
> (RA60) and the simulator configuration. You will want to change the
> Ethernet device that the DELUA (XU) device connects to.
> 
>
>
> Cheers,
> Christian
> --
> Christian M. Gauger-Cosgrove
> STCKON08DS0
> Contact information available upon request.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Configuring DMC11 Devices

[Christian Gauger-Cosgrove]

On 4 January 2016 at 18:10, Mark Pizzolato  wrote:
> I still need a RSTS disk image and configuration file which has several 
> DMC/DMR's
> configured and attempts to start the network
>
I've setup a small RSTS/E 10.1-L system with DECnet; it's kitted out
with a DELUA, DMR11, and a DMC11.

Here's the output of "ncp show known nodes" and "ncp show known circuits":
$ ncp show known nodes
Known Node Volatile Summary as of 4-JAN-16 22:56:38

Executor Node = 11.94 (RSTS10)

State  = On
Identification = DECnet/E V4.1
Active Links   = 0

Remote Node = 11.70 (TESTME)

State  = Unreachable

Remote Node = 11.84 (DRAGON)

State  = Unreachable
$ ncp show known circuits
Known Circuit Volatile Summary as of 4-JAN-16 22:57:04

Circuit = DMR-0

State  = On-Starting

Circuit = DMC-1

State  = Off

Circuit = UNA-0

State  = On
$
The DMC11 is only off because it's providing the constant barrage of
circuit initialization failures; on start up the circuit state is on.


And here is a Dropbox link to a 7-Zip archive of the system disk
(RA60) and the simulator configuration. You will want to change the
Ethernet device that the DELUA (XU) device connects to.



Cheers,
Christian
-- 
Christian M. Gauger-Cosgrove
STCKON08DS0
Contact information available upon request.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Configuring DMC11 Devices

[Mark Pizzolato]

On Monday, January 4, 2016 at 12:06 PM, Paul Koning wrote:
> > On Jan 4, 2016, at 2:53 PM, Mark Pizzolato  wrote:
> >
> >> ...
> >
> > I vaguely remember that something else depends on how it is currently
> > implemented.  The wait delay was added to accommodate the fact that
> > something didn't expect immediate response.  A delay of 1 is essentially the
> > same as no delay.
> >
> > It is hard to imagine that the OS driver would expect that the device would
> > complete some operation in one instruction time.  This would tend to fail as
> > newer models of CPU were implemented which used the same peripheral
> > hardware, no?
> 
> All I can say is that it does work on real hardware.
> 
> The manual says that the bit is "self-clearing".  That isn't the same words as
> the more common "write only" but it implies roughly the same thing.  The
> driver definitely does not expect the whole master clear process to complete
> in a few instruction times; it patiently waits for RUN to become set.  But it
> DOES expect that MCLR does not read back as set, not even very quickly
> after it was set by the driver.
> 
> So maybe the thing to do is have the process master clear action be started
> at the CSR write rather than delayed (while other CSR operations can remain
> delayed) so that at least the clear_master_clear part is done right away.

Sounds reasonable.  I've got to see if I can find the reason the delay was 
initially added and make sure a change like this is compatible.

> >> By the way, if I connect a DMC to a DMR, it doesn't come up.  Is that
> >> expected?  I thought DMC and DMR were sufficiently compatible that it
> >> would work...
> >
> > They absolutely should work as long as the both get turned on by software.
> > The wire protocol is the same.  The wire protocol is also compatible to host
> > based DDCMP protocol implementations on the PDP10 and RSX since it can
> > reliably talk to KMC/DUP configurations.
> 
> Ok, that's what I figured.  The wire protocols in the real hardware are 
> actually
> not identical (DDCMP 3.1 vs. DDCMP 4.0, and in the case of the "high speed"
> DMC-11, 3.1 with some bugs that I might still have documented somewhere).
> But yes, they are supposed to be interoperable.

I still need a RSTS disk image and configuration file which has several 
DMC/DMR's 
configured and attempts to start the network


Thanks.

- Mark

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Configuring DMC11 Devices

[Johnny Billquist]

On 2016-01-04 21:05, Paul Koning wrote:



On Jan 4, 2016, at 2:53 PM, Mark Pizzolato  wrote:


...


I vaguely remember that something else depends on how it is currently 
implemented.  The wait delay was added to accommodate the fact that something 
didn't expect immediate response.  A delay of 1 is essentially the same as no 
delay.

It is hard to imagine that the OS driver would expect that the device would 
complete some operation in one instruction time.  This would tend to fail as 
newer models of CPU were implemented which used the same peripheral hardware, 
no?


All I can say is that it does work on real hardware.

The manual says that the bit is "self-clearing".  That isn't the same words as the more 
common "write only" but it implies roughly the same thing.  The driver definitely does 
not expect the whole master clear process to complete in a few instruction times; it patiently 
waits for RUN to become set.  But it DOES expect that MCLR does not read back as set, not even very 
quickly after it was set by the driver.

So maybe the thing to do is have the process master clear action be started at 
the CSR write rather than delayed (while other CSR operations can remain 
delayed) so that at least the clear_master_clear part is done right away.


What about just always returning that bit as zero when read? Seems that 
should be good enough. Or is something else also expected to happen that 
don't? Just masking out the master clear means you can keep the delay 
for the rest as it is, or did I miss something more?


Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Configuring DMC11 Devices

[Paul Koning]

> On Jan 4, 2016, at 2:53 PM, Mark Pizzolato  wrote:
> 
>> ...
> 
> I vaguely remember that something else depends on how it is currently 
> implemented.  The wait delay was added to accommodate the fact that something 
> didn't expect immediate response.  A delay of 1 is essentially the same as no 
> delay.
> 
> It is hard to imagine that the OS driver would expect that the device would 
> complete some operation in one instruction time.  This would tend to fail as 
> newer models of CPU were implemented which used the same peripheral hardware, 
> no?

All I can say is that it does work on real hardware.

The manual says that the bit is "self-clearing".  That isn't the same words as 
the more common "write only" but it implies roughly the same thing.  The driver 
definitely does not expect the whole master clear process to complete in a few 
instruction times; it patiently waits for RUN to become set.  But it DOES 
expect that MCLR does not read back as set, not even very quickly after it was 
set by the driver.

So maybe the thing to do is have the process master clear action be started at 
the CSR write rather than delayed (while other CSR operations can remain 
delayed) so that at least the clear_master_clear part is done right away.

>> By the way, if I connect a DMC to a DMR, it doesn't come up.  Is that
>> expected?  I thought DMC and DMR were sufficiently compatible that it
>> would work...
> 
> They absolutely should work as long as the both get turned on by software.  
> The wire protocol is the same.  The wire protocol is also compatible to host 
> based DDCMP protocol implementations on the PDP10 and RSX since it can 
> reliably talk to KMC/DUP configurations.

Ok, that's what I figured.  The wire protocols in the real hardware are 
actually not identical (DDCMP 3.1 vs. DDCMP 4.0, and in the case of the "high 
speed" DMC-11, 3.1 with some bugs that I might still have documented 
somewhere).  But yes, they are supposed to be interoperable.

Will investigate what's going wrong.

paul


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Configuring DMC11 Devices

[Mark Pizzolato]

On Monday, January 4, 2016 at 11:38 AM, Paul Koning wrote:
> It looks like the problems RSTS is having with DMC/DMR is due to
> unexpected behavior of the master clear bit.  It's documented as self-
> clearing, so the driver sets it and then subsequently assumes it will read as
> cleared.  That isn't actually happening correctly, at least not if two 
> accesses
> are close together:
> 
> DBG(4466384761)> DMC REG: dmc_wr(DMC0), addr=0x003fe038, SEL0, 
> newdata=0x4000, olddata=0x8200 
> DBG(4466384761)> DMC REG: DMC0: Setting SEL0 (0x4000) MCLR 
> DBG(4466384764)> DMC REG: dmc_wr(DMC0), addr=0x003fe038, BSEL0, newdata=23, 
> olddata=0x00 
> DBG(4466384764)> DMC REG: DMC0: Setting SEL0 (0x4023) MCLR RQI
> 
> This is the driver doing a master clear, quickly followed by a Request In 
> asking
> to set the Base address.  That second operation is a byte write to BSEL0, and
> it relies on MCLR being either write-only, or at least self-clearing fast 
> enough.
> In this case, clearly that is not working; MCLR is still set so the byte 
> write sets
> not just RQI and BASEI, but also MCLR -- so RDYI is never set, the driver 
> times
> out, and the cycle repeats.
> 
> This patch (hack?) fixes the issue, and now my two cross-connected DMCs
> successfully start:
> 
> diff --git a/PDP11/pdp11_dmc.c b/PDP11/pdp11_dmc.c index
> e0e0111..6034683 100644
> --- a/PDP11/pdp11_dmc.c
> +++ b/PDP11/pdp11_dmc.c
> @@ -3592,7 +3592,7 @@ else {
> 
>  if ((dmc_getsel(reg) == 0) || (dmc_getsel(reg) == 1)) {/* writes to SEL0 and
> SEL2 are actionable */
>  if (0 == controller->dmc_wr_delay) {/* Not waiting? */
> -controller->dmc_wr_delay = 10;  /* Wait a bit before acting on 
> the
> changed register */
> +controller->dmc_wr_delay = 1;  /* Wait a bit before acting on the
> changed register */
>  sim_activate_abs (controller->unit, controller->dmc_wr_delay);
>  }
>  }

I vaguely remember that something else depends on how it is currently 
implemented.  The wait delay was added to accommodate the fact that something 
didn't expect immediate response.  A delay of 1 is essentially the same as no 
delay.

It is hard to imagine that the OS driver would expect that the device would 
complete some operation in one instruction time.  This would tend to fail as 
newer models of CPU were implemented which used the same peripheral hardware, 
no?

> By the way, if I connect a DMC to a DMR, it doesn't come up.  Is that
> expected?  I thought DMC and DMR were sufficiently compatible that it
> would work...

They absolutely should work as long as the both get turned on by software.  The 
wire protocol is the same.  The wire protocol is also compatible to host based 
DDCMP protocol implementations on the PDP10 and RSX since it can reliably talk 
to KMC/DUP configurations.



___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Configuring DMC11 Devices

[Tom Morris]

On Mon, Jan 4, 2016 at 2:38 PM, Paul Koning  wrote:

By the way, if I connect a DMC to a DMR, it doesn't come up.  Is that
> expected?  I thought DMC and DMR were sufficiently compatible that it would
> work...


The DMR had a switch-selectable DMC compatibility mode.  Not sure if that's
implemented by the emulator, but, if so, it would need to be selected.

Tom
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Configuring DMC11 Devices

[Paul Koning]

It looks like the problems RSTS is having with DMC/DMR is due to unexpected 
behavior of the master clear bit.  It's documented as self-clearing, so the 
driver sets it and then subsequently assumes it will read as cleared.  That 
isn't actually happening correctly, at least not if two accesses are close 
together:

DBG(4466384761)> DMC REG: dmc_wr(DMC0), addr=0x003fe038, SEL0, newdata=0x4000, 
olddata=0x8200
DBG(4466384761)> DMC REG: DMC0: Setting SEL0 (0x4000) MCLR 
DBG(4466384764)> DMC REG: dmc_wr(DMC0), addr=0x003fe038, BSEL0, newdata=23, 
olddata=0x00
DBG(4466384764)> DMC REG: DMC0: Setting SEL0 (0x4023) MCLR RQI 

This is the driver doing a master clear, quickly followed by a Request In 
asking to set the Base address.  That second operation is a byte write to 
BSEL0, and it relies on MCLR being either write-only, or at least self-clearing 
fast enough.  In this case, clearly that is not working; MCLR is still set so 
the byte write sets not just RQI and BASEI, but also MCLR -- so RDYI is never 
set, the driver times out, and the cycle repeats.

This patch (hack?) fixes the issue, and now my two cross-connected DMCs 
successfully start:

diff --git a/PDP11/pdp11_dmc.c b/PDP11/pdp11_dmc.c
index e0e0111..6034683 100644
--- a/PDP11/pdp11_dmc.c
+++ b/PDP11/pdp11_dmc.c
@@ -3592,7 +3592,7 @@ else {
 
 if ((dmc_getsel(reg) == 0) || (dmc_getsel(reg) == 1)) {/* writes to SEL0 and 
SEL2 are actionable */
 if (0 == controller->dmc_wr_delay) {/* Not waiting? */
-controller->dmc_wr_delay = 10;  /* Wait a bit before acting on the 
changed register */
+controller->dmc_wr_delay = 1;  /* Wait a bit before acting on the 
changed register */
 sim_activate_abs (controller->unit, controller->dmc_wr_delay);
 }
 }

By the way, if I connect a DMC to a DMR, it doesn't come up.  Is that expected? 
 I thought DMC and DMR were sufficiently compatible that it would work...

paul

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Configuring DMC11 Devices

[Paul Koning]

> On Jan 4, 2016, at 4:51 AM, Mark Pizzolato  wrote:
> 
> On Sunday, January 3, 2016 at 2:17 PM, Paul Koning wrote:
>> ...That is with two DMCs pointing at each other:
>> 
>> sim> show dmc
>> DMC  lines=2, connectpoll=2, address=17760070-17760107*
>>  vector=300*, 2 units
>>  DMC0attached to 10143, peer=127.0.0.1:11043, speed=0 (unrestricted)
>>  MicroDiag=enabled, type=DMC
>>  DMC1attached to 11043, peer=127.0.0.1:10143, speed=0 (unrestricted)
>>  MicroDiag=enabled, type=DMC
> 
> This configuration is very odd.  You've got DMC0 connecting to itself AND 
> you've got DMC1 also connecting to itself using the exact same ports as DMC0. 
>  I wouldn't expect this to ever work...

No, they are cross-connected.  I admit it is hard to read because of the 
similar looking port numbers.

paul


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Configuring DMC11 Devices

[Mark Pizzolato]

On Sunday, January 3, 2016 at 2:17 PM, Paul Koning wrote:
> > On Jan 3, 2016, at 1:46 PM, Christian Gauger-Cosgrove
>  wrote:
> >
> > Well, I was attempting it with RSTS/E since the "XM0: is missing
> > ECO's, but will still function." error implies that the DMC11 device
> > would still function. I turned on debug for the DMC device using "SET
> > DMC DEBUG" and nothing seems to be getting printed even though the
> DMC
> > device is being "used" by RSTS/E.
> 
> You need to specify a debug output file, for example "set debug stdout".
> 
> With that, I see the following:
> 
> DBG(4762921805)> DMC REG: dmc_rd(DMC0), addr=0x003fe038, SEL0,
> data=0x8000
[...]
> 
> 
> Event type 4.11, Circuit initialization failure - circuit fault
> Occurred 20-Dec-28 17:13:27.0 on node 1.43 (SIMH43)
> Circuit DMC-1
> Reason = Circuit synchronization lost
> Adjacent node address = 0
> 
> 
> 
> Event type 4.11, Circuit initialization failure - circuit fault
> Occurred 20-Dec-28 17:13:27.0 on node 1.43 (SIMH43)
> Circuit DMC-0
> Reason = Circuit synchronization lost
> Adjacent node address = 0
> 
>   DBG(5118754449)> DMC TRACE: dmc_poll_svc()
> 
> 
> 
> That is with two DMCs pointing at each other:
> 
> sim> show dmc
> DMC   lines=2, connectpoll=2, address=17760070-17760107*
>   vector=300*, 2 units
>   DMC0attached to 10143, peer=127.0.0.1:11043, speed=0 (unrestricted)
>   MicroDiag=enabled, type=DMC
>   DMC1attached to 11043, peer=127.0.0.1:10143, speed=0 (unrestricted)
>   MicroDiag=enabled, type=DMC

This configuration is very odd.  You've got DMC0 connecting to itself AND 
you've got DMC1 also connecting to itself using the exact same ports as DMC0.  
I wouldn't expect this to ever work...

- Mark

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Configuring DMC11 Devices

[Paul Koning]

> On Jan 3, 2016, at 1:46 PM, Christian Gauger-Cosgrove 
>  wrote:
> 
> Well, I was attempting it with RSTS/E since the "XM0: is missing
> ECO's, but will still function." error implies that the DMC11 device
> would still function. I turned on debug for the DMC device using "SET
> DMC DEBUG" and nothing seems to be getting printed even though the DMC
> device is being "used" by RSTS/E.

You need to specify a debug output file, for example "set debug stdout".

With that, I see the following:

DBG(4762921805)> DMC REG: dmc_rd(DMC0), addr=0x003fe038, SEL0, data=0x8000
DBG(4762921808)> DMC REG: DMC0: Getting SEL0 (0x8000) RUN 
DBG(4762921808)> DMC REG: dmc_rd(DMC0), addr=0x003fe038, SEL0, data=0x8000
DBG(4762921817)> DMC REG: DMC0: Getting SEL0 (0x8000) RUN 
DBG(4762921817)> DMC REG: dmc_rd(DMC0), addr=0x003fe038, SEL0, data=0x8000
DBG(4762921820)> DMC REG: DMC0: Getting SEL0 (0x8000) RUN 
DBG(4762921820)> DMC REG: dmc_rd(DMC0), addr=0x003fe038, SEL0, data=0x8000
DBG(4762921827)> DMC REG: dmc_wr(DMC0), addr=0x003fe038, SEL0, newdata=0x4000, 
olddata=0x8000
DBG(4762921827)> DMC REG: DMC0: Setting SEL0 (0x4000) MCLR 
DBG(4762921830)> DMC REG: dmc_wr(DMC0), addr=0x003fe03e, SEL6, newdata=0xa40b, 
olddata=0x
DBG(4762921830)> DMC REG: DMC0: Setting SEL6 (0xa40b)
DBG(4762921831)> DMC REG: dmc_wr(DMC0), addr=0x003fe039, BSEL1, newdata=82, 
olddata=0x40
DBG(4762921831)> DMC REG: DMC0: Setting SEL0 (0x8200) RUN ROMI 
DBG(4762921837)> DMC TRACE: dmc_svc(DMC0)
DBG(4762925339)> DMC REG: dmc_wr(DMC1), addr=0x003fe040, SEL0, newdata=0x4000, 
olddata=0x8200
DBG(4762925339)> DMC REG: DMC1: Setting SEL0 (0x4000) MCLR 
DBG(4762925342)> DMC REG: dmc_wr(DMC1), addr=0x003fe046, SEL6, newdata=0xa40b, 
olddata=0xa40b
DBG(4762925342)> DMC REG: DMC1: Setting SEL6 (0xa40b)
DBG(4762925343)> DMC REG: dmc_wr(DMC1), addr=0x003fe041, BSEL1, newdata=82, 
olddata=0x40
DBG(4762925343)> DMC REG: DMC1: Setting SEL0 (0x8200) RUN ROMI 
DBG(4762925349)> DMC TRACE: dmc_svc(DMC1)
DBG(4763203477)> DMC REG: dmc_wr(DMC0), addr=0x003fe038, SEL0, newdata=0x4000, 
olddata=0x8200
DBG(4763203477)> DMC REG: DMC0: Setting SEL0 (0x4000) MCLR 
DBG(4763203480)> DMC REG: dmc_wr(DMC0), addr=0x003fe03e, SEL6, newdata=0xa40b, 
olddata=0xa40b
DBG(4763203480)> DMC REG: DMC0: Setting SEL6 (0xa40b)
DBG(4763203481)> DMC REG: dmc_wr(DMC0), addr=0x003fe039, BSEL1, newdata=82, 
olddata=0x40
DBG(4763203481)> DMC REG: DMC0: Setting SEL0 (0x8200) RUN ROMI 
DBG(4763203487)> DMC TRACE: dmc_svc(DMC0)


Event type 4.11, Circuit initialization failure - circuit fault
Occurred 20-Dec-28 17:13:27.0 on node 1.43 (SIMH43)
Circuit DMC-1
Reason = Circuit synchronization lost
Adjacent node address = 0

  

Event type 4.11, Circuit initialization failure - circuit fault
Occurred 20-Dec-28 17:13:27.0 on node 1.43 (SIMH43)
Circuit DMC-0
Reason = Circuit synchronization lost
Adjacent node address = 0

  DBG(5118754449)> DMC TRACE: dmc_poll_svc()



That is with two DMCs pointing at each other:

sim> show dmc
DMC lines=2, connectpoll=2, address=17760070-17760107*
vector=300*, 2 units
  DMC0  attached to 10143, peer=127.0.0.1:11043, speed=0 (unrestricted)
MicroDiag=enabled, type=DMC
  DMC1  attached to 11043, peer=127.0.0.1:10143, speed=0 (unrestricted)
MicroDiag=enabled, type=DMC


paul

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Configuring DMC11 Devices

[Christian Gauger-Cosgrove]

On 3 January 2016 at 07:19, Mark Pizzolato  wrote:
> Well, HELP suggests the following
>
> sim> help dmc config example
> Device DMC is currently disabled
> DMC help.  Type  to exit, HELP for navigation help
> Examples
> To configure two simulators to talk to each other use the 
> following
> example:
>
> Machine 1
> sim> SET DMC ENABLE
> sim> SET DMC0 PEER=LOCALHOST:
> sim> ATTACH DMC0 
>
> Machine 2
> sim> SET DMC ENABLE
> sim> SET DMC0 PEER=LOCALHOST:
> sim> ATTACH DMC0 
>
> You should be able to confirm that this is sufficient if you try connecting 
> DMCs together when running 'known to work' OS configurations (these include 
> VMS and RSX).
>
I guess I need to install RSX or VMS then. And that was the first
configuration I tried.


> Meanwhile, since RSTS's drivers (or network startup code) have issued 
> warnings about problems with the version of the device we can't really be 
> sure that it is actually starting up the device.  The DMC device simulator 
> won't try to connect to the peer until the simulated OS brings the device 
> online.
>
Well, I was attempting it with RSTS/E since the "XM0: is missing
ECO's, but will still function." error implies that the DMC11 device
would still function. I turned on debug for the DMC device using "SET
DMC DEBUG" and nothing seems to be getting printed even though the DMC
device is being "used" by RSTS/E.

In any case, after DECnet/E 4.1 starts up the following gets printed:
Event type 4.11, Circuit initialization failure - circuit fault
Occurred 20-Dec-28 13:25:10.0 on node 1.250 (HOUOU)
Circuit DMC-0
Reason = Circuit synchronization lost
Adjacent node address = 0


The above message repeats, continuously, of course with date and time
matching. Trying with a date before 2000, still results in the same
circuit initialization failure (just with the correct date, of
course).


> If someone has RSTS DMC11 device driver source we could determine the details 
> of the version requirements and/or other behavior that it needs.
>
Unfortunately, I can't help with that since the driver sources don't
come with the RSTS/E 10.1-L installation tape.


Cheers,
Christian
-- 
Christian M. Gauger-Cosgrove
STCKON08DS0
Contact information available upon request.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Configuring DMC11 Devices

[Mark Pizzolato]

On Saturday, January 2, 2016 at 10:47 PM, Christian Gauger-Cosgrove wrote:
> So, I believe I'm having a bit of a "blonde moment" in trying to configure the
> DMC device in the PDP-11 simulator. I'm attempting to setup a point-to-point
> DDCMP link for DECnet between two PDP-11's running RSTS/E 10.1-L. The
> KMC11 (KDP) and DUP11 (DUP) devices do not work under RSTS/E 10.1-L; it
> only supports: the DMC11, DMR11, DMP11, and DMV11.
> 
> What would be the correct way of configuring two simulators with DMC
> devices to connect?
> 
> Trying it like such:
> SIMULATOR A:
> set DMC0 PEER=127.0.0.1:11085
> attach DMC0 11097,Connect=127.0.0.1:11085
> 
> SIMULATOR B:
> set DMC0 PEER=127.0.0.1:11097
> attach DMC0 11085,Connect=127.0.0.1:11097
> 
> Results in neither connecting. I have also tried omitting the "Connect="
> parameters on one or both; and using "localhost" in place of 127.0.0.1
> without success. I have also tried connecting a DUP device to a DMC device
> also without success.
>
> So, could someone please enlighten me as to the correct way to configure
> the DMC devices?

Well, HELP suggests the following

sim> help dmc config example
Device DMC is currently disabled
DMC help.  Type  to exit, HELP for navigation help
Examples
To configure two simulators to talk to each other use the following
example:

Machine 1
sim> SET DMC ENABLE
sim> SET DMC0 PEER=LOCALHOST:
sim> ATTACH DMC0 

Machine 2
sim> SET DMC ENABLE
sim> SET DMC0 PEER=LOCALHOST:
sim> ATTACH DMC0 

You should be able to confirm that this is sufficient if you try connecting 
DMCs together when running 'known to work' OS configurations (these include VMS 
and RSX).

Meanwhile, since RSTS's drivers (or network startup code) have issued warnings 
about problems with the version of the device we can't really be sure that it 
is actually starting up the device.  The DMC device simulator won't try to 
connect to the peer until the simulated OS brings the device online.

If someone has RSTS DMC11 device driver source we could determine the details 
of the version requirements and/or other behavior that it needs.

- Mark
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh