> On Jan 5, 2016, at 4:59 PM, Mark Pizzolato <[email protected]> wrote:
>
> On Monday, January 4, 2016 at 12:06 PM, Paul Koning wrote:
>>> On Jan 4, 2016, at 2:53 PM, Mark Pizzolato <[email protected]> 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
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
