[Simh] Configuring DMC11 Devices

[Paul Koning]

> On Jan 5, 2016, at 4:59 PM, Mark Pizzolato <Mark at infocomm.com> wrote:
> 
> On Monday, January 4, 2016 at 12:06 PM, Paul Koning wrote:
>>> On Jan 4, 2016, at 2:53 PM, Mark Pizzolato <Mark at infocomm.com> 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
> 	CLRB	BSEL1(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