The ENABLE took an incoming UNIBUS segment, containing the CPU and all DMA devices, and ran all memory read-write cycles on it through two different sets of relocation registers - one set for the CPU, and a separate set for the devices (the ENABLE was able to tell, by watching the details of the bus cycles, the source of any given cycle) - and produced cycles to a relocated address on an Extended UNIBUS. This could hold stock EUB memory cards, up to the 4MB standard on the EUB.
Physically, the ENABLE was a hex card which plugged into a standard Modified UNIBUS Device backplane, which was used in EUB mode. (Since the EUB re-purposed existing bus lines, which were bussed to all the slots in an MUD backplane, this worked.) The stock EUB memory cards plugged into this backplane.
The incoming UNIBUS segment was introduced to the ENABLE via a standard UNIBUS connector on the back edge of the ENABLE card, into which a standard BC11A UNIBUS cable from the rest of the machine was plugged. The ENABLE's EUB interface was via the card's edge connectors where the card plugged into the MUD/EUB backplane.
There was also an optional 8KB cache card; and an optional 'Memory Adapter' card, from which came another UNIBUS segment, to which could be attached other non-DMA devices, and/or up to 128KB of existing UNIBUS memory. (The reason for the limitation is not clear.)
The register set used for mapping CPU cycles was indentical in function to the PAR's of the standard PDP-11 Memory Management system, but had different addresses from the ones built into the CPU. (The ENABLE did not have PDRs; the PDRs in the CPU were used.)
Also, the method for deciding which ABLE PAR to use for any given CPU memory cycle was different.
In the basic PDP-11 memory management, the PAR to use for any given memory cycle is selected based the virtual address, the CPU's current mode (Kerner, User, etc), and, for machines which support Split I+D, whether it is an instruction or data fetch.
The ENABLE, being a UNIBUS device, had access to none of the information about CPU mode, fetch type, etc. Instead, the ENABLE chose which of its PARs to use for any given memory cycle based solely on the UNIBUS address. For 256KB of address space, it had 32 PARs, each one thus applying to 8KB of address space - the same size as with the PDP-11's native PARs.
One simple programming model for using all this was to set up the native PARs to statically map different CPU address spaces (e.g. Kernel I space) to distinct blocks of the UNIBUS address space, and from then on, leave the native PARs untouched, using only the ABLE PARs, as the operating system ran.
For Unix, this was particularly easy to achieve; the file which contained the definition of the PAR addresses was modified, the OS was recompiled, and no other changes (other than properly initializing the ENABLE and the CPU's PARs) were needed.
The only disadvantage of this simple approach was that with 3 CPU modes; instruction and data fetches; and a 64KB virtual address, there is no way to statically map all of them to fixed UNIBUS addresses; that would require 3*2*64KB, or 384KB of address space, and the UNIBUS only has 256KB available.
The ENABLE has two control registers, and two sets of 32 mapping registers (i.e. one for every 8KB block of UNIBUS address space): one set for the CPU, and one set for DMA devices.
The CPU set are just like the standard PARs of the CPU, and give mapped base addresses in the EUB memory in units of 0100 bytes; the device set are double-word registers, and give base addresses as word addresses.
The CPU set occupy locations 763700 (applies to UNIBUS addresses of the form 00xxxx) through 763776 (applies to UNIBUS addresses of the form 76xxxx).
The device set are identical to those of a standard UNIBUS map, so the pair at 770200/02 applies to UNIBUS addresses of the form 00xxxx, through to the pair at 770374/76, which is used for addresses 76xxxx. (Note that this last pair maps the UNIBUS' I/O page.)
The two control registers are named SSR3 and SSR4, at 763676 and 763674, respectively. These names are slightly confusing, since the standard PDP-11 memory management already has an SSR3 register (on machines with the non-subset memory management). This name was probably picked because it contains bits found in SSR3 on 22-bit machines such as the PDP-11/70 and /44. Some users referred to the registers on the ENABLE as SSR4 and SSR5 to prevent confusion.
The layout of the ENABLE SSR3 (763676) is:
|Unused||Enable UNIBUS Map||Enable 22-bit||Unused|
The layout of SSR4 (763674) is:
Memory System Error Register
The ENABLE also contains a Memory System Error Register, a double-word register at 777740/2 (exactly the same as in the -11/70); it contains information about the first error (all bits are read-only).
The layout of the Low Error Address Register(77740) is:
|Address bits 15-0|
and the High Error Address Register(77742) is:
|C0||C1||Unused||Address bits 21-16|
C0 and C1 are the UNIBUS control lines which give the bus cycle type:
|1||1||Data Out Byte|
The still-extant documentation does not cover the details of how the ENABLE could tell whether a bus cycle was from the CPU, or a DMA device, but it is possible to analyze the framework.
The ENABLE, being behind all the DMA devices, will of course not see the NPG grant signal, but it can observe NPR, SACK and BBSY, and from this work out that when BBSY is re-asserted after it sees SACK, all bus read/write cycles during that assertion of BBSY must be from a DMA device. (Technically, a device can also do DMA cycles after gaining control of the bus with a BRn signal, usually used for an interrupt, so perhaps the ENABLE only monitored SACK and BBSY.)
The cache came on a quad card which plugged into the C-F connectors of the first slot of the MUD/EUB backplane holding the ENABLE main card. All "necessary" signals between the ENABLE and cache were carried by a flat cable which plugged into connectors on the tops of both cards; the backplane provided only power.
(It is possible that the data lines and/or lower address lines of the EUB, which are accessible on the lower connectors of the EUB/MUD backplane in the SPC portion of the slot, were used, but the still-extant documentation does not cover this level of detail.)
The Memory Adapter, or 'MemDap', card was a dual card which plugged into the 'out' slot of the EUB backplane; the 'out' secondary UNIBUS from it appeared on a UNIBUS connector on the top edge of the card, and was carried on a standard BC11A cable to another backplane.
A 4-wide DIP switch on the MemDap card indicated where the address space of the secondary UNIBUS appeared, in the full EUB address space. (This was apparently so that the UNIBUS memory, if it started at 0 on the secondary UNIBUS, would appear contiguously with the EUB memory.)
The functioning of it was apparently fairly simple; when an address in the range designated by the configuration switch appeared on the EUB, the MemDap card passed that cycle through to the secondary UNIBUS, with the high address bits stripped out, but otherwise un-modified.
Additional EUB backplanes
It was possible to carry the EUB to a second backplane, using a special 'UNIBUS' cable which carried the additional address lines of the EUB; this had to be plugged into the A-B connectors of a MUD slot on the first EUB backplane (remember that the A-B connectors of the first and last slots on a MUD backplane carry the standard UNIBUS), and similarly on the second backplane.