Thanks for that - very informative! I'm more interested in _what_ the two boards are doing! :-) It seems they must be jumpering UNIBUS A and UNIBUS B together. (Which I didn't expect, but maybe... will have to ponder.) As to what _else_ it is doing, and why it has the cable to the main card... I think that it must intercept MSYN from the processor and only let it pass if there's no hit in the cache. (To explain why it would need to do that... normally with the MS11, there's a static partitioning between FastBus memory and UNIBUS A memory. So when the CPU goes to do a memory cycle, it can put the address out on both the UNIBUS and FastBus, with the certainty that it will only get a reply on one. But with the cache, if there's a hit, it would in theory get a reply on both, which might confuse it. Or if it takes the cache copy, and terminates the UNIBUS cycle, that might confuse the memory.) Or maybe I'm confused, because now that I think about it, UNIBUS A goes straight from the CPU to the UNIBUS A out slot, so the Able board couldn't intercept MSYN? I guess I need to understand the fine details of the UNIBUS A and B stuff, maybe it will make sense at that point. Oh, wait a moment: slot 26 is UNIBUS A out, slot 27 is 'UNIBUS B in', and slot 28 is UNIBUS B 'termination'. (27 is 'in' because when the M9200 is installed in 26/27 to join the two UNIBI together, obviously one has to connect an 'out' to an 'in'... and then 28 is not 'UNIBUS B termination', it's 'UNIBUS out' to the rest of the system. OK, so that works - MSYN coming out of slot 26 is intercepted by the dual double-card, and is only allowed to pass on cache miss. Yeah, that sounds like it should work. One of two; the other is slot 16. According to that marketing thing you found, "User may optimize hit ratio by upper/lower limit switch settings", so one would have to configure the Cache/45 to not cache the block that the 'other' MS11 controller thinks it owns... otherwise both might respond to requests for addresses in that range.... :-) Noel