[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 <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?
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 phone
lines) operation.  Don't remember details.

Finally, the KMC has very few CSR bits that are implemented in
hardware.  Most are defined by microcode.  So aside from the maintenance
bits, the operating protocol is interlocked with bits like ready in/
ready out - that are implemented by microcode.  And you'll see the KDP
and DMC/DMR registers look different to software, even though the
hardware is the same.

> 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 at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4994 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20160105/9e574946/attachment-0001.bin>