Difference between revisions of "Able ENABLE"
(minor clarifications) |
(→Programming model: Note no PDRs in ENABLE) |
||
Line 11: | Line 11: | ||
The register set used for mapping DMA cycles exactly emulated the [[UNIBUS map]], as in the [[PDP-11/70]] and later [[PDP-11/44]], and was used in exactly the same way. | The register set used for mapping DMA cycles exactly emulated the [[UNIBUS map]], as in the [[PDP-11/70]] and later [[PDP-11/44]], and was used in exactly the same way. | ||
− | 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. | + | 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. (The ENABLE did not have PDRs; the standard 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 [[PDP-11 Memory Management|Split I+D]], whether it is an instruction or data fetch. | 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 [[PDP-11 Memory Management|Split I+D]], whether it is an instruction or data fetch. |
Revision as of 20:58, 2 January 2018
The ENABLE from Able Computer (also variously given in Able documentation as the EnABLE and ENABLE/34) was a UNIBUS device which allowed the smaller PDP-11's to have up to 4 MBytes of main memory.
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.
Programming model
The register set used for mapping DMA cycles exactly emulated the UNIBUS map, as in the PDP-11/70 and later PDP-11/44, and was used in exactly the same way.
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. (The ENABLE did not have PDRs; the standard 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 a fixed UNIBUS address; that would require 3*2*64KB, or 384KB of address space, and the UNIBUS only has 256KB available.