Digital Technologies/Electronics: DMANAGER (1975 – 1982)
The DMANAGER (1975 – 1982)
The DMA maNAGER (DManager) was developed and used between 1975 and 1982. DManager was a multi-microcomputer system for interfacing. Until the mid-70s, interfacing equipment with computers was time-consuming and therefore costly. The reason was that manufacturers often did not supply open hardware interfaces and operating software. An interface enables communication between a peripheral device and a computer. If one considers the interface itself as a device, it must be connected both to the computer and to the peripheral device. The computer connection consists of three different functional parts:
- a programmed channel (program channel) through which input and output instructions are handled (start an activity),
- a Direct Memory Access (DMA) channel allowing direct access to computer memory for reading or writing,
- an interrupt channel through which the interrupt signals are transported.
Technically, a device interface has three channel connections with a computer and one with the device to be connected. The idea of the DMA manager (DMANAGER) was to use a single link with a computer (with three-channel connections) to connect more peripherals to one device interface. At that time, only one specific connection for each peripheral device had to be developed. By linking self-developed or specially purchased equipment to a computer for the manifold of laboratory experiments, the use of DMANAGER could result in a considerable time and cost reduction. This idea was fuelled by the emergence of microprocessors that could enable the realisation of a standard interface with such an architecture that only minimal hardware had to be added for that equipment-specific interface and some software. Using such a standard, only the hardware and software for the three-channel connections to the computer and the connection to the peripheral device had to be designed and manufactured. The realised DMANAGER could link multiple devices such as processors, tape units, disk drives, and displays via a single 38-bit wide data bus on a DMA (Direct Memory Access) basis: 32 data bits and 6-bit address code. A peripheral device was connected to the DMANAGER-bus via a specific Peripheral Oriented Processor (POP); this was an INTEL 8080 microprocessor with communication facilities. A POP uses standard hardware for the connection with the data bus, the DMA request signal line, the accept signal line, and a three-bit state bus. In addition, the POP has a Device Dependent Unit (DDU), which consists of the specific hardware to connect the peripheral device. Up to 60 POPs could be connected to the data bus; the other addresses were reserved for the Priority unit and the DMA buffer unit. The DMANAGER allowed peripheral devices to exchange information with each other over the bus and via the DMA buffer unit with the computer memory. Access and control over the data bus were controlled by the Priority unit. Types of communication:
- Program Channel Unit to a POP data transport from computer to a peripheral device
- POP to the DMA Buffer Unit – DMA data transport from (peripheral) device to the computer
- DMA buffer unit to POP – DMA data transport from computer to a (peripheral) device
- POP to interrupt unit – the peripheral device sends an interrupt to the computer
- POP to POP – data transport between two peripherals
The DMA Buffer Unit and all POPs had a variable, programmable priority (0-127) for their bus transports. As a result, a unit that only occasionally dealt with a time-critical process had to seize the bus capacity during that time slot only. The priority regulation was innovative. If a POP or the DMA Buffer Unit requested transport over the bus, access was granted if its priority was the highest at that time. If the supplied data rate was large enough, the unit received a claim on the data bus. However, if the data rate was smaller than the bus capacity, the unit shared the bus with all other units with a lower priority. This method made optimal use of the bus and prevented the unnecessary loss of bus capacity.
Units that wanted to perform a transport notified that by putting their priority on the bus. This request was interpreted by the Priority unit. This unit then identified the unit by his address for data transport which had the highest priority. Then the requesting unit put one word to the addressed unit on the bus to signal whether a data transport could take place or not.
A distinction was made between transports for the DMA Buffer Unit, i.e. for computer memory, and the other bus transports. DMA Buffer Unit transports always took priority over all other transports. Data transport from the DMA Buffer Unit to the requester, which is the result of DMA read operations on the computer memory, had the highest priority. The DMANAGER design assumed that the DMANAGER would be able to simultaneously facilitate data transport with a computer memory with a cycle time of 600 nanoseconds and data transports between POPs. A necessary design requirement for a bus on a word basis is a quick selection of the next POP or another unit that wants to transport data. In essence, the priority of all 64 units must be compared. The fastest selection method was a parallel scan of 128 bus lines, while the data transports could suffice with a 40-line bus. An optimum was found in a distributed decision capacity, one part in the Priority unit, and the other part in each unit connected to the bus. The priorities were therefore divided into four groups of 32 bits. The 7-bit priority word of a unit could then be interpreted as a 2-bit group designation (0-3) and a 5-bit level (0-31) assignment within that group. The bus was divided into a 32-bit level field and a 4-bit group address field. A unit indicated that it wanted to request a bus transport by selecting one of the four bits in the ‘Bus Scan system state’ in the bus group field and designating the corresponding priority level bit within its group in the 32-bit level field. The decision-making task of the POP consisted of examining the group field. When a higher group request was detected, it had to withdraw its request. After stabilisation, the highest group of 32 (sub)priorities remained on the bus. The Priority Unit then searched for the highest active level. In the Priority Grant state, the Priority Unit sent the highest priority in coded form to all units.
Because there was no handshaking, every transmitting unit had to put a recipient address code on the bus with each transport, in addition to the 32 information bits. The addressee who recognised the addressing code as his then took the data stream from the bus. If this was not possible, the unit indicated that by placing a signal on the ACCEPT line. The design of the DMANAGER used the programming language SIMULA with which the various parallel processes could be simulated on the Control Data 6400 computer. The SIMULA model checked the basic design of the DMANAGER for timing and other logic errors.
The DMANAGER has been used since the end of 1975 for the control and processing of the information from the experimental phased array radar system FUCAS (see our radar development section). The DMANAGER printed circuit boards are sized 18.5 by 15.5 inches to fit into a 19″ rack. The main computer for FUCAS was a Data General NOVA Eclipse S/200 used. The development and testing of the hardware required the necessary wirewrap modifications of the wires between the TTL chips. Once a week a new logic drawing was produced; intermediate changes were indicated on the diagram using a four-colour pen, for each day of the week a different colour.
In 1981, a software program was developed to automatically verify the correct operation of the DMANAGER hardware units such as the POPs.
