> On Monday, January 4, 2016 at 12:06 PM, Paul Koning wrote: >>> On Jan 4, 2016, at 2:53 PM, Mark Pizzolato <m...@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@trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh