Difference between revisions of "Able ENABLE"
m (clarify) |
m (+New category) |
||
(4 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
− | [[Image:BrochureAbleENABLE.jpg|250px|thumb|right|Able ENABLE as shown in an Able brochure]] | + | [[Image:BrochureAbleENABLE.jpg|250px|thumb|right|Able ENABLE, as shown in an Able brochure]] |
− | 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''' 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 ([[PDP-11/34]] through [[PDP-11/45]]) to have up to 4 MBytes of [[main memory]]. |
− | The ENABLE took an incoming UNIBUS segment, containing the [[Central Processing Unit|CPU]] and all [[Direct Memory Access|DMA]] devices, and ran all | + | The ENABLE took an incoming UNIBUS segment, containing the [[Central Processing Unit|CPU]] and all [[Direct Memory Access|DMA]] [[peripheral controller|devices]], and ran all read-write cycles from them to memory through two different sets of relocation [[register]]s - 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). It then produced cycles to relocated [[address]]es on a separate [[Extended UNIBUS]]; the latter could hold stock EUB memory cards, up to the 4MB standard on the EUB. |
Physically, the ENABLE was a [[DEC card form factor|hex]]-width 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. | Physically, the ENABLE was a [[DEC card form factor|hex]]-width 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. | ||
Line 9: | Line 9: | ||
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 [[DEC edge connector contact identification|edge connectors]] where the card plugged into the MUD/EUB 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 [[DEC edge connector contact identification|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.) Details on both are given below. | + | There was also an optional 8KB [[cache]] card; and also 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.) Details on both are given below. |
==Programming model== | ==Programming model== | ||
Line 19: | Line 19: | ||
Also, the method for deciding which ABLE PAR to use for any given CPU memory cycle was different. | 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 ( | + | In the basic PDP-11 [[memory management]], the PAR to use for any given memory cycle is selected based on the [[virtual address]], the CPU's current mode (Kernel, User, etc), and, for machines which support [[PDP-11 Memory Management|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. | 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. | ||
Line 25: | Line 25: | ||
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. | 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 [[ | + | 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 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. | ||
Line 83: | Line 83: | ||
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 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 [[ | + | The ENABLE, being behind all the DMA devices, will of course not see the [[Non-Processor Request and Grant|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.) |
==Optional cache== | ==Optional cache== | ||
− | The cache came on a [[DEC card form factor|quad]]-width card which plugged into the [[DEC edge connector contact identification|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 | + | The cache came on a [[DEC card form factor|quad]]-width card which plugged into the [[DEC edge connector contact identification|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 an [[over the back]] [[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 [[Small Peripheral Controller|SPC]] portion of the slot, were used, but the still-extant documentation does not cover this level of detail.) | (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 [[Small Peripheral Controller|SPC]] portion of the slot, were used, but the still-extant documentation does not cover this level of detail.) | ||
Line 105: | Line 105: | ||
==External links== | ==External links== | ||
+ | * [http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/Enable_DocCirca1980.pdf ENABLE User's Guide] - pre-release version | ||
* [http://gopher.quux.org:70/Archives/usenet-a-news/FA.unix-wizards/81.07.09_ucbvax.2202_fa.unix-wizards.txt Adding additional memory to 11/45s] | * [http://gopher.quux.org:70/Archives/usenet-a-news/FA.unix-wizards/81.07.09_ucbvax.2202_fa.unix-wizards.txt Adding additional memory to 11/45s] | ||
* [http://gopher.quux.org:70/Archives/usenet-a-news/FA.unix-wizards/81.07.12_ucbvax.2254_fa.unix-wizards.txt More ENABLE/34 Info...] | * [http://gopher.quux.org:70/Archives/usenet-a-news/FA.unix-wizards/81.07.12_ucbvax.2254_fa.unix-wizards.txt More ENABLE/34 Info...] | ||
+ | * [http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/Enable_Paper_Complete.pdf Modifications to UNIX to Allow Four Mega Bytes of Main Memory on a 11/40 Class Processor] | ||
[[Category: PDP-11s]] | [[Category: PDP-11s]] | ||
+ | [[Category: UNIBUS]] | ||
+ | [[Category: Extended UNIBUS]] |
Latest revision as of 14:47, 6 February 2024
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 (PDP-11/34 through PDP-11/45) 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 read-write cycles from them to memory 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). It then produced cycles to relocated addresses on a separate Extended UNIBUS; the latter could hold stock EUB memory cards, up to the 4MB standard on the EUB.
Physically, the ENABLE was a hex-width 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 also 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.) Details on both are given below.
Contents
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 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 on the virtual address, the CPU's current mode (Kernel, 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.
Registers
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 | ||||||||||||
15 | 14 | 13 | 12 | 11 | 10 | 09 | 08 | 07 | 06 | 05 | 04 | 03 | 02 | 01 | 00 |
The layout of SSR4 (763674) is:
Unused | Enable | ||||||||||||||
15 | 14 | 13 | 12 | 11 | 10 | 09 | 08 | 07 | 06 | 05 | 04 | 03 | 02 | 01 | 00 |
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 | |||||||||||||||
15 | 14 | 13 | 12 | 11 | 10 | 09 | 08 | 07 | 06 | 05 | 04 | 03 | 02 | 01 | 00 |
and the High Error Address Register(77742) is:
C0 | C1 | Unused | Address bits 21-16 | ||||||||||||
15 | 14 | 13 | 12 | 11 | 10 | 09 | 08 | 07 | 06 | 05 | 04 | 03 | 02 | 01 | 00 |
C0 and C1 are the UNIBUS control lines which give the bus cycle type:
C0 | C1 | Cycle type |
---|---|---|
0 | 0 | Data In |
0 | 1 | Data In |
1 | 0 | Data Out |
1 | 1 | Data Out Byte |
Technical details
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.)
Optional cache
The cache came on a quad-width 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 an over the back 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.)
Memory Adapter
The Memory Adapter, or 'MemDap', card was a dual-width 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.