<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Sep 6, 2018 at 4:12 PM, Johnny Billquist <span dir="ltr"><<a href="mailto:bqt@softjar.se" target="_blank">bqt@softjar.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The problem is that the MK11 memory boxes also have CSRs, and those are living in that last 8K space. If you have memory mapping those same addresses, I have no idea what happens, but either way is not good. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Either you have the memory, in which case the CSRs are unaccessible, and
 they control how the memory box works. Or else you have the CS‰s, but 
what then happens to those memory cells?<span class="gmail-HOEnZb"></span><br><span class="gmail-HOEnZb"></span></blockquote><div><span class="gmail-HOEnZb"><font color="#888888">
</font></span><br></div><div>You're right. The Unibus does not go to the MK11, which only connects via the memory bus to the KB11-C cache, so at least some I/O page accesses have to go across the memory bus for the MK11 CSRs. Rather than decoding and only sending the specific MK11 CSR I/O page accesses to the memory page, the KB11-C cache system most likely just sends all I/O page accesses to both Unibus and the memory bus, expecting only one to acknowledge.</div><div><br></div><div>If I was desperate to have 4088KB/2044KW, I could probably kludge up additional logic to the MK11 control modules to explicitly disable the RAM operation for the entire I/O page range. However, I have only ten M8722 modules (2.5MB/1.25MW), so it isn't something I actually need.</div><div><br></div></div></div></div>