Difference between revisions of "Able ENABLE"

From Computer History Wiki
Jump to: navigation, search
(A start, more details coming soon)
 
m (Minor tweaks)
 
(8 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
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 to have up to 4 MBytes of [[main memory]].
  
The ENABLE took an incoming UNIBUS segment, containing the [[Central Processing Unit|CPU]] and all [[DMA]] devices, and ran all memory read-write cycles through two different sets of relocation [[register]]s (one set for the CPU, and a separate set for the devices) and produced an [[Extended UNIBUS|EUB]]. This could hold stock EUB memory cards.
+
The ENABLE took an incoming UNIBUS segment, containing the [[Central Processing Unit|CPU]] and all [[Direct Memory Access|DMA]] devices, and ran all memory read-write cycles on it 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) - 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|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.
+
Physically, the ENABLE was a [[DEC card form factor|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 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.)
  
 
==Programming model==
 
==Programming model==
Line 11: Line 13:
 
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 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 [[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.
  
 
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 19: Line 23:
 
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 [[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 were needed.
+
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:
 +
{{16bit-header}}
 +
| colspan=10 | Unused || Enable UNIBUS Map || Enable 22-bit || colspan=4 | Unused
 +
{{16bit-bitout}}
 +
 
 +
The layout of SSR4 (763674) is:
 +
{{16bit-header}}
 +
| colspan=15 | Unused || Enable
 +
{{16bit-bitout}}
 +
 
 +
===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:
 +
{{16bit-header}}
 +
| colspan=16 | Address bits 15-0
 +
{{16bit-bitout}}
 +
 
 +
and the High Error Address Register(77742) is:
 +
{{16bit-header}}
 +
| C0 || C1 || colspan=8 | Unused || colspan=6 | Address bits 21-16
 +
{{16bit-bitout}}
 +
 
 +
C0 and C1 are the UNIBUS control lines which give the bus cycle type:
 +
 
 +
{| class="wikitable"
 +
! 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 [[bus grant line|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 [[DEC card form factor|quad]] 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 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 [[Small Peripheral Controller|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 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 [[Dual Inline Package|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.
 +
 
 +
==External links==
  
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.
+
* [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...]

Latest revision as of 14:49, 6 May 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 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.)

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 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.

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 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.)

Memory Adapter

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.

External links