Core memory emulator using non volatile ram.

Paul Koning paulkoning at
Mon Dec 17 12:58:24 CST 2018

> On Dec 17, 2018, at 1:52 PM, Noel Chiappa via cctalk <cctalk at> wrote:
>> From: Paul Koning
>> For that matter, core memory details such as destructive read weren't
>> visible to the CPU
> Umm, not quite. If you'd said 'core memory details such as destructive read
> weren't visible to the _program_', you'd have been 100% correct.
> But as I suspect you know, just overlooked, most (all?) of the -11 CPU's do
> use 'read-modify-write' cycles on the bus (DATIP in UNIBUS terms, DATIO in
> QBUS) where possible precisely for the benefit of core memory with its
> destructive readout. (And there's some hair for interlocking the multiple
> CPU's on the -11/74 which I don't recall off the top of my head.)

No, that doesn't invalidate what I said.  DATAIP/DATAO on the Unibus doesn't depend on the destructive read property.  It works just fine with DEC semiconductor memory.  It is perfectly valid to implement DATAIP as if it were DATAI, so that transaction simply becomes a read followed by a write.  

The reason it existed is that it allows core memory to optimize the timing, by running a "half cycle", omitting the restore part.  But the DATAO supplies the new content of the word, and so long as the memory does that write you're all set.

If PDP-11s ever did a DATAIP without a DATAO, you'd be able to tell the difference between core and semiconductor memory by reading the location afterwards and looking for non-zero.  But conforming Unibus masters don't do that.


More information about the cctech mailing list