The ENABLE took an incoming UNIBUS segment, containing the CPU and all DMA devices, and ran all memory read-write cycles 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, which type any given cycle was) and produced an EUB. This could hold stock EUB memory cards.
Physically, the ENABLE was a hex card which plugged into a standard MUD backplane, being 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 register set used for mapping CPU cycles was indentical in function to the PAR's of the standard PDP-11 Memory Management system, but at different addresses. 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 a fixed UNIBUS address; that would require 3*2*64KB, or 384KB of address space, and the UNIBUS only has 256KB available.