DATIP from clr always? (obscure unibus & pdp-11 question) - test-drb@ccmp.vtda.org

30 Aug 2006

Don North <ak6dn at mindspring.com> skrev:
...

Brad Parker wrote:
> > Don North wrote:
>> >> On all the discrete logic 11s and LSI11 the CLR instr does a
> > ...
> >
> > thanks!
>> >> So if your hardware can't tolerate a read access to a register, 
then you
...
 >> >> can do a MOV #0,ADR instead of CLR
ADR (and make a note in your  code why
...
  > >>
so some poor soul 30 years from now understands why you are doing a
> >> non-optimal MOV #0,xxx!)
 >
 > I fixed the hardware  :-)  I was just curious about which machines did
 > what.
 >
 > The problem was that the two transactions are back to back and the bus
 > master keeps overnership.  I was waiting for BBSY to go away...
 >
 > -brad 
The 'original' use for DATIP-DATO (vs a sequence of DATI, DATO) was to
let core memory know it did not have to do the read-restore cycle, since
a DATO was coming right away to the exact same location and would
overwrite with new data. The memory could then be a little bit faster.
With MOS memory this is not necessary.

Some later CPUs (11/74) iirc altered all the 'normal' memory accesses to
be just DATI and DATO(B) cycles, and implemented the special sequence
DATIP-DATOB for the ASRB instruction to act as the atomic memory
interlock. But I digress...

Don 
I don't remember for sure here, but can't you have other times where 
several transactions come back to back without the bus being released?

I really should look into the documentation, unfortunately it's not 
where I am right now.

As for the 11/74, it didn't modify the interpretation of the Unibus 
transactions, since the memory isn't on the Unibus. :)
The 11/7x memory bus do have a transaction that keeps the location 
locked until a write have occurred however. Not used in the 11/70, but 
the 11/74 uses that. (Obviously.) It's documented in the memory 
subsystem manual for the 11/70. The only instruction using that bus 
transaction is the ASRB howewer.

Not sure if the 11/84 might have redefined the Unibus somewhat. I 
remember that there is some note about possible problems with some 
Unibus devices in an 11/84, but I think it has to do with timing during 
a bus reset.

Wish my memory was more accurate. :)

	Johnny