Data processing system having data entry backspace character apparatus4383295Abstract In a data processing system which includes one or more common buses to which a plurality of input/output controllers are connected for the transfer of data, blocks of data may be transferred between main memory and an input/output controller (IOC) synchronously with operation of the central processor unit (CPU). Logic is provided for enabling one unit of data to be transferred during a Data Multiplex Control (DMC) data transfer operation in which the requesting IOC requests a DMC data transfer of the CPU and later provides the CPU with a channel number assigned to the requesting IOC. In order to allow a data entry operator inputting data via a peripheral device connected to an IOC the ability to correct errors, a backspace character is provided so that the operator can enter it to indicate to the system to ignore the preceding character. Logic is provided within the system to allow a DMC IOC to detect the output of a backspace character from the peripheral device connected to the IOC and to inform the CPU of the entry of the backspace character by a special (backspace) input/output interrupt. Further logic is provided within the CPU to adjust pointers to the main memory input buffer to effectively ignore the byte of data corresponding to the character preceding the backspace character. Still further logic is provided within the DMC IOC to prohibit the sending of special (backspace) input/output interrupts to the CPU if there are no bytes of data remaining in the input buffer. Claims What is claimed is: Description CROSS-REFERENCE TO RELATED APPLICATIONS
______________________________________
SERIAL
TITLE INVENTORS NO.
______________________________________
Data Processing System
Ming T. Miu 008,010, filed
Having Centralized
John J. Bradley Feb. 12, 1979
Non-Existent Memory
William Panepinto, Jr.
Address Detection
Jian-Kuo Shen
Data Processing System
Jian-Kuo Shen 008,121, filed
Having Centralized
John J. Bradley Jan. 31, 1979
Data Alignment for
Richard L. King
I/O Controllers
Robert C. Miller
Ming T. Miu
Theodore R. Staplin, Jr.
Data Processing System
Theodore R. Staplin, Jr.
008,122, filed
Having Synchronous
John J. Bradley Jan. 31, 1979
Bus Wait/Retry Cycle
Richard L. King
Robert C. Miller
Ming T. Miu
Jian-Kuo Shen
Data Processing Sys-
Ming T. Miu 008,005, filed
tem Having Hardware
John J. Bradley Jan. 31, 1979
Interrupt Apparatus
Jian-Kuo Shen
Data Processing Sys-
John J. Bradley 008,003, filed
tem Having Data Multi-
Robert C. Miller
Jan. 31, 1979
plex Control Apparatus
Ming T. Miu
Jian-Kuo Shen
Theodore R. Staplin, Jr.
Data Processing Sys-
Robert C. Miller
008,002, filed
tem Having Data Multi-
John J. Bradley Jan. 31, 1979
plex Control Bus
Richard L. King
Cycle Ming T. Miu
Jian-Kuo Shen
Theodore R. Staplin, Jr.
Data Processing Sys-
John J. Bradley 008,001, filed
tem Having Direct
Thomas O. Holtey
Jan. 31, 1979
Memory Access Bus
Robert C. Miller
Cycle Ming T. Miu
Jian-Kuo Shen
Theodore R. Staplin, Jr.
Data Processing System
Ming T. Miu 008,123, filed
Having Centralized
John J. Bradley Jan. 31, 1979
Bus Priority Resolu-
Jian-Kuo Shen
tion
Data Processing System
John J. Bradley 008,004, filed
Having Multiple
Ming T. Miu Jan. 31, 1979
Common Buses Jian-Kuo Shen
______________________________________
BACKGROUND OF THE INVENTION 1. Field of the Invention This invention generally relates to data processing systems and more specifically to the interchange of data between an input/output (I/O) controller for a peripheral device and the main memory in such data processing systems. 2. Discussion of the Prior Art A data processing system usually includes a central processing unit (CPU) which executes software instructions which are stored at addresses, or locations, in main memory. These software instructions are transferred to the CPU sequentially under the control of a program counter. The data that is processed is transferred into and out of the system by way of input/output devices, or peripheral devices, such as teletypewriters, magnetic disks, magnetic tapes or line printers. Usually the data is temporarily stored in the main memory before or after the processing by the central processing unit. In a system having a plurality of devices coupled over one or more common buses, an orderly system must be provided by which bidirectional transfer of information may be provided between such devices. This problem becomes more complicated when such devices include, for example, one or more memory units and various peripheral devices. Various methods and apparatus are known in the prior art for interconnecting such a system. Such prior art systems range from those having common data bus paths to those which have special paths between various devices. Such systems also may include a capability for either synchronous or asynchronous operation in combination with the bus type. Some of such systems, independent of the manner in which such devices are connected or operate, require the central processor's control of any such data transfer on the bus even though, for example, the transfer may be between devices other than the central processor. In addition, such systems normally include various parity checking apparatus, priority schemes and interrupt structures. One such structural scheme is shown in U.S. Pat. No. 3,866,181. A data processing system utilizing a common asynchronous communication bus is shown in U.S. Pat. No. 3,886,524. Another in which all units in the system, including the memory, are connected in parallel is shown in U.S. Pat. No. 3,710,324. The manner in which addressing is provided in such systems as well as the manner in which, for example, any one of the devices may control the data transfer is dependent upon the implementation of the system, i.e., whether there is a common bus, whether the operation thereof is synchronous or asynchronous, etc. The systems's response and throughput capability is greatly dependent on those various structures. A particular structured scheme is shown in U.S. Pat. Nos. 3,993,981, 3,995,258, 3,997,896, 4,000,485, 4,001,790 and 4,030,075 which describe an asynchronously operated common bus. There are several ways to transfer data between a peripheral device and a main memory unit. Two popular methods are implemented by transferring data from/to the peripheral device through the CPU to/from main memory or directly from/to the peripheral device to/from the main memory. PROGRAMMED I/O In the first method, commonly called programmed I/O, the input/output transfer is done under the control of the software program being executed within the central processing unit. For example, to input a character from a teletypewriter peripheral, a software program executed within the CPU would be written such that it would execute one or more software instructions to first input the character entered by the teletypewriter peripheral into a register within the CPU, such as the accumulator, and then a subsequent software instruction would store the contents of the accumulator into a specified main memory location. Thus, the input transfer would have taken place under software control with the data passing through the CPU. Similarly, on output the data would first be loaded from main memory into the accumulator by one software instruction and then output from the accumulator to the teletypewriter peripheral by one or more subsequent software input/output instructions. Variations of this method are known in which the software program either loops, checking the status of an indicator to determine whether the input/output transfer has been completed between the CPU and the peripheral device, or alternatively, the completion of the transfer may be signalled by a software interrupt initiated by the peripheral device. In either case, this method is inefficient in that it requires the attention of a software program in the CPU to each individual character as it is transferred between the peripheral device and the CPU. Nevertheless, this method is often used for a low-speed peripheral device because this method usually results in the reduction in the amount of logic needed within the input/output controller to which the peripheral device is attached. DIRECT MEMORY TRANSFERS Direct memory transfers, the second method, permits large quantities of data to be moved between the main memory and the peripheral device with greatly increased efficiency. Using the direct memory transfer method, the software program within the CPU initiates the transfer of a group of information and once initiated the transfer takes place between the peripheral device and the main memory without further intervention. Using this method, the software program initiates a transfer by indicating the peripheral device to which the transfer data is to be input from or output to, the starting address in main memory to which the data is to be transferred to or from, and the number of characters or words of data to be transferred in the group or block. Then, once the transfer is initiated, the transfer takes place on a character by character, word by word basis directly between the peripheral device and the main memory unit without further software intervention. Once the last character or word of the group has been transferred, the software in the CPU is notified either by continually checking a status indicator or upon receipt of an interrupt and the software program may then process the transferred data or initiate another transfer. This second method (direct memory transfers) is more efficient than the first method (programmed I/O) and frees the CPU for the execution of software during the time that the input/output transfer is taking place. This increase in efficiency is offset by the additional logic required within the system to hold the starting main memory address and the number of characters or words (range) of data to be transferred in the block. There are several places within the data processing system where this added logic for direct memory transfer may be placed. For example, this added logic is often placed within the input/output controller (IOC) to which the peripheral device is attached by placing a starting address register and a range counter within the IOC. In this method, which is commonly called Direct Memory Access (DMA), when the software initiates the transfer the starting address is transferred from the CPU to the starting address register within the IOC and the block size (range) is also transferred to the range register within the IOC. The IOC then contains sufficient logic so that the address may be incremented by one as each word is transferred between the peripheral device and the main memory and the range may be, for example, counted down until it reaches zero indicating the end of the group has been transferred. In addition, the IOC must contain sufficient logic to interface directly with the main memory. This interface logic in the IOC may provide the needed read/write main memory signals and may provide for the handling of exception conditions such as: main memory busy, addressing a nonexistent main memory location, and resolution of conflicts between the IOC and other units (the CPU or another IOC) competing for the same resource (such as the system (I/O) bus or main memory). Thus, it can be seen that the logic within the IOC is increased by having to provide the address and range registers along with decrementing and incrementing logic and the main memory interface logic. An article entitled "DMA Controller Capitalizes on Clock Cycles to Bypass CPU"by Joseph Nissim describing direct memory access can be found in the January, 1978, issue of Computer Design. DATA MULTIPLEX CONTROL Alternatively, other direct memory transfer methods are known, such as that found on Honeywell Information Systems, DDP-516 computer. In this method, known as Data Multiplex Control (DMC), rather than placing the address range registers within the I/O controller a starting address and ending address are contained in two locations within main memory which are dedicated to the particular channel to which the peripheral device is attached, there being sixteen separate channels using a total of 32 locations in main memory. In addition, other logic is present within the system which is multiplexed between the 16 channels to increment the starting address as each word is transferred and to compare the incremented starting address with the ending address to see whether the last word of the group is being transferred. Using the data multiplex control method, an input/output transfer is initiated by the software first storing the starting address into the channel's main memory location and then storing the ending address into the channel's main memory location using non-I/O software instructions. After the starting and ending address main memory locations have been initiated, the program then executes one or more I/O software instructions which actually initiate the transfer of data between the peripheral device and main memory. Once initiated, each time the peripheral device determines that it requires another word of data to be sent to or from the main memory, it signals the DMC logic on a unique line associated with and dedicated to the particular channel on which the peripheral device is assigned. The DMC logic then prioritizes these transfer request signals among the one or more channels that are requesting and requests the CPU to break at the end of the current software instruction. Once the break request is honored, at the end of the current software instruction, software execution is halted and the DMC logic takes over control of the system for four main memory cycles. During the first main memory cycle, the contents of the starting address location are fetched from main memory and stored in the address counter register of the DMC logic. The channel number corresponding to the data transfer request from the peripheral device is used to determine which main memory location contains the starting address for the particular peripheral device making the data transfer. During the second main memory cycle, the contents of the ending address location in main memory are fetched and compared with contents of the address counter register by the DMC logic. If the contents are equal an end-of-range indicator is set and no data transfer takes place. During the third main memory cycle, the data transfer takes place between the peripheral device and main memory and is controlled by the contents of the address counter register within the DMC logic. The direction of the transfer, whether input (from the peripheral device to main memory) or output (from main memory to the peripheral device), is determined by a bit within the main memory location containing the starting address. This bit is also transferred to the address counter register when the starting address is transferred from memory to the DMC logic. During this third main memory cycle, the contents of the address counter register are used to address the main memory with the contents of the addressed location either being read from main memory and transferred to the peripheral device or the word from the peripheral device being stored into the addressed location in main memory. During this main memory cycle, the contents of the address counter register are incremented by one. During the fourth and final main memory cycle, the contents of the address counter register are stored in the channel's starting address location within main memory. If another data transfer request is waiting, another data transfer cycle starts. If no register is waiting, the CPU resumes control and the previously halted software program resumes execution at the next software instruction. During the first main memory cycle, the DMC logic sets a unique device address line which informs the peripheral device that the current input/output transfer is being conducted on its behalf. There are sixteen device address lines, one for each of the sixteen channels, and the setting of the line during the first main memory cycle is used by the peripheral device's IOC during the third main memory cycle to either place data from the peripheral device on the bus for transfer to main memory or to take data from the I/O bus, placed there by main memory, and output it to the peripheral device. During the end of the CPU's execution of a software instruction, the DMC logic performs a synchronization cycle. During the synchronization cycle a priority network within the data multiplex control logic determines if any channel is making a data transfer request and if so, determines the highest priority request of the one or more channels requesting a transfer. If any peripheral connected to the DMC logic is requesting a data transfer, the DMC logic informs the CPU that a data transfer break is required. Although this data multiplex control method of direct transfer is more efficient that the programmed control method, it has the disadvantage that four separate main memory transfer cycles are required and that the software execution is suspended during these four main memory cycles. In addition, the data transfer may only occur at the end of the software instruction thus lengthening the response to a data transfer request in the event of a software instruction which has a long execution time. Further, since there must be one data request line and one device address line per channel, this method results in the widening of the input/output bus connecting the peripherals, device controllers and the central processor and main memory by requiring two lines per available channel. DIRECT MEMORY ACCESS Within the Honeywell DDP-516 computer system the Direct Memory Access (DMA) method of direct transfer discussed above is also used for some I/O controllers. The DDP-516 DMA provides a direct, high-speed path for a peripheral device to the main memory for up to four channels. To effect a transfer, the DMA logic causes breaks between CPU cycles without regard to the end of the software instruction being processed by the CPU. The initiation and termination of the DMA cycle is controlled by the peripheral device request lines. I/O software instructions are used for loading the address and range counters of the DMA control logic and for reading the contents of the range counters. The DMA control logic contains a priority network for determining the priority of the active DMA requests from the peripheral devices and the logic for initiating and controlling the DMA cycle. The DDP-516 DMA control logic provides the CPU with an alternate memory register and an alternate memory address register. DMA data transfers take place through the alternate memory register without disturbing the contents of the normal CPU memory register. The contents of the CPU memory address register are temporarily shuttled into the alternate memory address register and then returned upon completion of the DMA cycle. These registers give the DDP-516 DMA its cycle-stealing ability and allow it, for example, to break between the fetch and execution cycles of a software instruction. Addresses are multiplexed into the CPU memory address register from one of four DMA channels. Each channel has a 16-bit hardware address counter which stores the starting address. The high order bit of the starting address is used to specify input or output mode. The remaining 15 bits specify the main memory address from or to which the first DMA data transfer will take place. In addition, each DMA channel has a 16-bit hardware range counter which stores the two's complement of the size of the block of data to be transferred. Both the address counter and the range counter are incremented each time a DMA data transfer takes place. Overflow of the range counter signifies completion of the group transfer by generating an end-of-range signal which disables the peripheral device and can be used to cause a software program interrupt. In addition, the contents of the range counter can be read into the CPU under software program control to determine, at any time, the number of words remaining to be transferred. DMA channels have their address and range information loaded under software program control by the I/O bus of the computer system. Unique I/O software instructions are provided to load each. Peripheral devices are connected to the DMA control logic via the DMA bus. Similar to the I/O bus, the DMA bus contains 16 input lines, 16 output lines, and various control lines. Data is transferred in parallel directly to main memory from the data buffer in the peripheral device interface. The DMA has top priority in a system and therefore takes precedence over any other operation such as a DMC data transfer request, priority interrupt processing, or real-time clock incrementation. When a peripheral device is ready to transfer data it makes a DMA request. If two DMA requests occur simultaneously, the lowest numbered DMA channel will be acknowledged first. A DMA request causes a break in the CPU processing of the software at the next CPU cycle, if it occurs in sufficient time prior to the start of the next CPU cycle. A DMA break can occur between fetch and execute phases of a software instruction or it could, for example, happen between DMC data transfer cycles. Once the DMA break has been initiated, the DMA cycles will continue to occur as long as further DMA requests are received in sufficient time prior to the end of the current CPU cycle. A DMA break effects the CPU only to the extent that it requires main memory cycles. If a DMA request should cause a DMA break during that portion of a software instruction not requiring a main memory cycle, the processing of the software instruction will continue uninterrupted. DMA data transfer occur independently of the software program. However, I/O software instructions are provided to load the address counter and range counter in order to set up a DMA transfer. I/O software instructions are also provided to monitor the range counter in order to determine, at any time, how many words of data remain to be transferred between the DMA peripheral device and main memory. A DMA cycle is activated by a peripheral device DMA request. The DMA control logic priority network determines the request priority and enables the proper DMA channel logic. The contents of the CPU memory address register are transferred to the alternate memory address register for preservation. The DMA cycle starts a main memory cycle, which is a read or write cycle depending upon the high order bit of the address counter. The CPU memory address register is cleared and the contents of the address counter representing the address to be accessed in the first DMA cycle are placed in the CPU memory address register. The address counter is then incremented to form the address for the next DMA cycle. For a DMA read cycle, the contents of the addressed memory location are inhibited from the CPU memory register and placed in the alternate memory register. The alternate memory register is then transferred to the 16 output lines and from there to the external peripheral device. For a DMA write cycle, the external peripheral device data is transferred from the peripheral device to the alternate memory register via the 16 input lines and from the alternate memory register to the addressed main memory location. If end-of-range is reached, the peripheral device disables its DMA request lines and DMA transfers from the channel are terminated. End-of-range is detected by the DMA control logic determining if the range counter equals all binary ONE's. The contents of the range counter are then incremented. The DMA control logic again searches its DMA request lines. If any are active, it causes another DMA cycle. If no DMA request exists, the DMA control logic returns the control to the CPU after transferring the contents of the alternate memory address register into the CPU memory address register. Thus it can be seen that the Honeywell DDP-516 computer software programmer when programming an input/output transfer must be cognizant of whether the I/O controller for the peripheral device is a Direct Memory Access (DMA) IOC or a Data Multiplex Control (DMC) IOC. This cognizance is required because of the way in which the software initiates the data transfer. In the case of a DMC type IOC, the software programmer must store the starting and ending address within the main memory using non I/O software instructions and then initiate the transfer by giving the peripheral devices' IOC a go signal using an I/O software instruction, whereas in the case of a DMA type IOC, the software programmer sends the starting address and the range to the DMA IOC by using I/O software instructions and then initiates the data transfer with another I/O software instruction. This presents a problem in that, for example, a serial line printer, because of the relatively low transfer rate of the data, may be controlled by a DMC type IOC, whereas a high speed line printer may be controlled by a DMA IOC. Because of the difference in software programming methods used on the two types of printers, the substitution of one type of printer for the other and the consequent change in IOC type will also necessitate a software program change. OBJECT OF THE INVENTION Accordingly, it is a primary object of the present invention to provide an improved direct memory transfer method or apparatus for data processing systems including the ability to correct data entry errors by use of a backspace operation. SUMMARY OF THE INVENTION In accordance with this invention, a data processing system comprising a central processing unit (CPU), a main memory, a peripheral device and an input/output controller (IOC) is provided with a direct memory transfer means. Means are provided within the IOC to detect a backspace character input from the peripheral device and signal the CPU of its occurence. Means are provided within the CPU to respond to the IOC backspace signal and to effectively remove the last unit of data transferred to an input buffer in main memory. Further means are provided within the IOC to count the number of non-backspace units of data already transferred to the input buffer during the current input operation and to inhibit the signal to the CPU that indicates the occurrence of a backspace character if the non-backspace units of data count equals zero. Means are provided within the IOC to decrement the non-backspace units of data count by one as each backspace character is detected. Means are provided in the CPU to store a main memory address of the next unit of data to be transferred and a count of the remaining number of units of data in the input buffer. Means are provided within the CPU to decrement the memory address and increment the remaining number of units counter as each backspace signal is transferred between the IOC and the CPU. Still further means are provided within the system to allow the backspace operation to be used by the IOC during an output transfer to have the last unit of data retransmitted from an output buffer in main memory to the IOC. This invention is pointed out with particularity in the appended claims. An understanding of the above and further objects and advantages of this invention may be obtained by referring to the following description taken in conjunction with the drawings. BRIEF DESCRIPTION OF THE DRAWINGS The manner in which the apparatus of the present invention is constructed and its mode of operation can best be understood in light of the following detailed description together with the accompanying drawings in which like reference numerals identify like elements in the several figures and in which: FIG. 1 is a general block diagram illustration of the system configuration of the present invention; FIG. 2 is a block diagram illustration of an example configuration of the present invention; FIG. 3 is a general block diagram of the central processor unit of the present invention; FIG. 4 illustrates the format of the CPU registers of the present invention; FIG. 5 illustrates the word and address formats of the present invention; FIG. 6 illustrates the system bus interface signals of the present invention; FIG. 7 is a general block diagram of the system bus signals shown in FIG. 6; FIG. 8 is a more detailed block diagram of the CPU shown in FIG. 3; FIG. 9 is a more detailed block diagram of the control store of the CPU shown in FIG. 8; FIG. 10 illustrates the CPU scratch pad memory layout of the present invention; FIG. 11 illustrates the place where the CPU registers are maintained in the CPU of the present invention; FIG. 12 is a more detailed block diagram of the system bus data control shown in FIG. 8; FIG. 13 is a system bus timing diagram of the present invention; FIG. 14 is a logic diagram of the basic system timing logic of the present invention; FIG. 15 is a timing diagram of the basic system timing logic shown in FIG. 14; FIG. 16 illustrates a flow chart of the CPU firmware for system start up/initialization sequence of the present invention; FIG. 17 illustrates the format of the address and data transfers on the address/data lines of the system bus of the present invention; FIG. 18 illustrates the input/output commands encoded on the RDDT lines of the system bus of the present invention; FIG. 19 illustrates a timing diagram of a memory access sequence on the system bus of the present invention; FIG. 20 illustrates a timing diagram of the CPU command to input/output controller sequence on the system bus of the present invention; FIG. 21A through FIG. 21D illustrate timing diagrams of the DMC data transfer sequence on the system bus of the present invention; FIG. 22 illustrates a timing diagram of the DMA data transfer sequence on the system bus of the present invention; FIG. 23 illustrates a timing diagram of the input/output interrupt sequence on the system bus of the present invention; FIG. 24 illustrates the format of the control word transferred on the system bus in response to an input/output software instruction of the present invention; FIG. 25 illustrates the input/output function codes of input/output software instructions of the present invention; FIG. 26A and FIG. 26B illustrate the formats of the IO and IOH software instructions of the present invention; FIG. 27A and FIG. 27B illustrate the formats of the IOLD software instructions of the present invention; FIG. 28 illustrates a flow chart of the CPU firmware which implements the IO software instruction shown in FIG. 26A and FIG. 26B; FIG. 29 illustrates a flow chart of the CPU firmware which implements the IOLD software instruction shown in FIG. 27A and FIG. 27B; FIG. 30 illustrates the interaction between the IOLD software instruction and the program channel table contained in the CPU scratch pad memory of the present invention; FIG. 31 illustrates the linkage between traps and software interrupts of the present invention; FIG. 32 illustrates the main memory locations dedicated to various functions in the system of the present invention; FIG. 33 is a general flow chart of the CPU firmware of the present invention; FIG. 34 illustrates a flow chart of the CPU firmware and shows the interaction between software interrupts, traps, and hardware interrupts of the present invention; FIG. 35 illustrates the format of the CPU firmware microinstruction word of the present invention; FIG. 35A through FIG. 35D illustrate in greater detail the various control fields of the CPU firmware microinstruction word of the present invention; FIG. 36 illustrates the operations performed by the microprocessor of the CPU of the present invention; FIG. 37A through FIG. 37G illustrate in greater detail the functions performed by the subcommands and control field of the CPU firmware microinstruction word shown in FIG. 35C; FIG. 38 is a block diagram of an input/output controller of the present invention; FIG. 39 illustrates the timing, request and reset logic of an I/O controller shown in FIG. 38; FIG. 40 illustrates a timing diagram of the timing signals found on the system bus and in an I/O controller of the present invention; FIG. 41 is a block diagram of a main memory module of the present invention; FIG. 42 illustrates the logic of the control store shown in FIG. 9; FIG. 43 illustrates the logic of the CPU shown in FIG. 8; FIG. 44 illustrates a flow chart of the logic of a DMC I/O controller for processing a backspace character; and FIG. 45 illustrates a flow chart of the CPU firmware for processing a backspace interrupt from a DMC I/O controller. TABLE OF CONTENTS DESCRIPTION OF THE PREFERRED EMBODIMENTS DESCRIPTION CONVENTIONS SYSTEM BUS OVERVIEW CENTRAL PROCESSOR DESCRIPTION CPU MAJOR COMPONENTS PROGRAMMING CONSIDERATIONS Software Visible Registers Word and Address Formats Main Memory CPU AND SYSTEM BUS INTERFACES SYSTEM BUS A SYSTEM BUS B CPU HARDWARE DESCRIPTION MICROPROCESSOR SYSTEM BUS CONTROL CONTROL PANEL BASIC SYSTEM TIMING SYSTEM INITIALIZATION SYSTEM BUS OPERATIONS MEMORY ACCESS MEMORY REFRESH FUNCTION CODE TO I/O CONTROLLER DMC DATA TRANSFER REQUEST DMA DATA TRANSFER REQUEST I/O CONTROLLER INTERRUPT EXECUTION OF INPUT/OUTPUT INSTRUCTIONS Channel Numbers I/O Function Codes Output Function Code Commands Input Function Code Commands Software Input/Output Instructions I/O Instruction IOLD Instruction IOH Instruction Traps and Software Interrupts Software Interrupts Traps FIRMWARE OVERVIEW GENERAL DESCRIPTION OF FIRMWARE FLOW SOFTWARE INTERRUPT, TRAP, HARDWARE INTERRUPT INTERACTION Software Program Firmware Microprograms Software Interrupts, Hardware Interrupts and Traps Software Interrupts Hardware Interrupts Traps Interrupts and Traps CPU FIRMWARE WORD DESCRIPTION SCRATCH PAD MEMORY CONTROL ARITHMETIC LOGIC UNIT CONTROL SUBCOMMANDS AND CONTROL READ ONLY STORAGE ADDRESSING I/O CONTROLLER LOGIC DETAILS I/O CONTROLLER DEVICE LOGIC Command Logic Task and Configuration Logic Interrupt Logic Status and Device Identification Logic Data Transfer Logic Address and Range Logic I/O CONTROLLER TIMING LOGIC I/O CONTROLLER REQUEST LOGIC I/O CONTROLLER INTERRUPT REQUEST LOGIC I/O CONTROLLER REQUEST RESET LOGIC DMA IOC REQUEST AND RESET LOGIC I/O CONTROLLER SYSTEM BUS REQUEST AND LINK LOGIC SUMMARY CPU LOGIC DETAILS CONTROL STORE LOGIC DETAILS ROS Address Generation Logic Hardware Interrupt Logic Main Memory Refresh Timeout Logic Main Memory Parity Error Logic Nonexistent Memory Detection Logic Software Interrupt Logic Boot PROM Logic CPU LOGIC DETAILS Data Transceiver Logic Scratch Pad Memory Logic Byte Swapping Logic Microprocessor and Data Selection Logic I, M1 and F Register Logic Bus Command Logic I/O Command Logic Proceed and Busy Logic Read/Write Byte Logic Memory Go Logic MAIN MEMORY DESCRIPTION SYSTEM BUS INTERFACE Data Word Address Word MAIN MEMORY ORGANIZATIONAL OVERVIEW MODULE PHYSICAL/ORGANIZATIONAL CHARACTERISTICS Module Addressing MEMORY SAVE UNIT MAIN MEMORY FUNCTIONAL OVERVIEW Main Memory Timing Main Memory Modules Timing Generator Negative 5 Volt Generator Power Failure Logic RAM Address Control and Distribution Logic Segment Select Logic Data In/Data Out Registers Parity Generator and Check Logic Read/Write Control Logic Refresh Logic Chip Select Logic MAIN MEMORY SUMMARY BACKSPACE INTERRUPT DMC IOC BACKSPACE LOGIC CPU BACKSPACE INTERRUPT FIRMWARE BACKSPACE INTERRUPT SUMMARY DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT DESCRIPTION CONVENTIONS In the system of the invention, electrical signals indicative of binary digits (bits) are applied to and obtained from various logic gates or other circuit elements. For the sake of brevity in the discussion which follows, the bits themselves are sometimes referred to rather than the signals manifesting the bits. In addition, for the sake of brevity, the signal names are sometimes used to label the lines connecting the various logic gates and circuit elements. These signals are sometimes referred to by a group of letters or numbers. For example, in FIG. 14, BCYCOT- at the upper right identifies a signal output by NAND gate 295. Sometimes a group of letters is followed by a plus sign or a minus sign. The plus sign means that when the signal represents a binary ONE (or true), it is a high level signal and the minus sign means that when the signal represents a binary ZERO (or false), it is a low level signal. In some cases the plus sign or minus sign may be followed by a couple of letters or numbers to distinguish that signal name from similar signal names with identical name beginnings. For example, in FIG. 43, signal PROCED- is output by decoder 244-3, signal PROCED-2A is output by inverter 546 and signal PROCED-20 is output by NOR gate 550. When the meaning is clear, sometimes the plus sign or the minus sign or other qualifying suffixes (letters or numbers) are omitted. For example, in FIG. 39 sheet 1, the suffix BA and BB are omitted from the signal RDDT29+ meaning that the signal would be RDDT29+BA if the I/O controller is connected to system bus A and the signal would be RDDT29+BB if the I/O controller is connected to system bus B. In other cases, when the meaning is clear, the letter "X" is used in signal name to indicate one of several signals. For example, in FIG. 39 sheet 1, the signal names PINTRX- and PIOCTX- refer to signal PINTR1 and PIOCTA- if the I/O controller is connected to system bus A and they refer to signals PINTR2- and PIOCTB- if the I/O controller is connected to system bus B. In some cases, a series of signals is indicated by using a hyphen after the first signal name followed by the suffix of the last signal name. For example, in FIG. 42 sheet 2, the output of register 242 is 48 signals named RDDT00+ through RDDT47+. For the sake of simplicity, logic gates are referred to as AND, OR, NAND and NOR gates, the difference between an AND gate and a NAND gate being that the NAND gate has an inverter, designated by a little circle in the drawing, on its output line. The presence of an inverter on the output line is also used to distinguish between a NOR gate and an OR gate. Inverters on the input lines of gates do not affect the name given to the logic gate. For example, in FIG. 42 sheet 1, gate 591 is referred to as an AND gate, gate 594 as a NAND gate (inverted output) and gates 584 and 595 as NOR gates (both with inverted outputs with the inverters on gate 584 inputs ignored for reference purposes). It is also assumed, for purposes of illustration, that logic requiring positive inputs for a positive output is employed unless indicated otherwise. That is, the logic circuits such as AND and OR circuits, for example, are operated by high signal levels at the input to produce a high level signal at the output. Logic levels which are not high will be termed low. SYSTEM BUS OVERVIEW A block diagram of the system is shown in FIG. 1. The central processor unit (CPU) 200 controls the system bus. The system bus is composed of two buses named system bus A, 202 and system bus B, 204. System buses A and B, 202 and 204, are used to interconnect the CPU 200, input/output (I/O) controllers 206, 208, 210 and 212, main memories or I/O controllers 214, 216, 218 and 220 and the memory save unit 222. For simplicity, FIG. 1 shows only four main memory or I/O controllers connected to each system bus. In the preferred embodiment, up to eight I/O controllers can be connected to each system bus if the physical packaging (available printed circuit board slots) of the system permits. As will be seen later, the limitation of eight I/O controllers per system bus is due to timing consideration and a change in the system timing could permit more or less I/O controllers per system bus. The control panel 201 connects directly to the CPU 200. System bus B 204 is similar to system bus A 202; however, system bus B contains additional memory control signals which are not present on system bus A. Therefore, only I/O controllers may be installed on system bus A whereas main memory or I/O controllers may be connected to system bus B. The I/O controllers connected to the system buses are used to control the operation of peripheral devices connected to the I/O controllers. The main memory, which can connect only to system bus B, is used to store the software programs which are processed by the CPU. The control panel 201 connected directly to CPU 200 is used by the system operator to initiate, monitor and direct the operation of the system. The optional memory save units 222 provide the DC voltages to the system's volatile semiconductor random access main memories. During normal power up conditions, the memory save unit 222 operates from DC voltages supplied by a local system power supply (not shown) generating the required memory voltages while keeping its rechargeable batteries at full charge. During power outages, the memory save unit 222 provides an emergency capability for retaining the volatile semiconductor main memory contents by providing battery back-up for a period of time, for example, 5 to 10 minutes, depending upon the amount of main memory being powered. The system shown in FIG. 1 can be configured into a variety of particular configurations by choosing various combinations of main memory, I/O controllers and peripheral devices. One such example system configuration is shown in FIG. 2. Now referring to FIG. 2, an example system configuration having a CPU 200 connected to system bus A 202 and system bus B 204 is shown. FIG. 2 shows a central processor unit with 64K words (1K=1024) of main memory, four diskette peripheral drives, a line printer, four communication lines, a console device and a printer connected as follows. Main memory 1, 214-1, containing 48K words and main memory 2, 216-1 containing 16K words, are connected to system bus B 204. Memory save unit 222 is also connected to system bus B 204. System bus A 202 and system bus B 204 are connected to CPU 200, control panel 201 is directly connected to CPU 200. Diskette peripheral devices 1 and 2, 207-1 and 207-2, are connected to system bus A 202 via diskette controller 1, 206-1. Diskette peripheral devices 3 and 4, 221-1 and 221-2, are connected to system bus B 204 via diskette controller 220-1. Communication lines 1 and 2 are connected to system bus A 202 via communications controller 210-1. Printer peripheral device 209 is connected to system bus A via printer controller 208-1. The console peripheral device 213 is connected to system bus A 202 via console controller 212-1. It should be noted that a like numbered element in one figure refers to the same numbered element in another figure; for example, control panel 201 in FIG. 2 refers to the same element as shown as control panel 201 in FIG. 1. CENTRAL PROCESSOR DESCRIPTION The Central Processor Unit (CPU) is a firmware directed processor designed as the controlling element within the system. The CPU contains an internal bus with two ports: system bus A and system bus B which interconnect the CPU, I/O controllers and main memory (shown in FIGS. 1 and 2). CPU firmware combined with system bus hardware provides control for I/O controller and main memory transfers. Data from any source is placed on a system bus by CPU firmware command and a main memory access can only be initiated by the CPU whether the main memory access is being performed on behalf of the CPU or an I/O controller. Thus, the need for priority resolution logic within each controller and main memory to resolve conflicting requests to use the system bus is eliminated. The CPU I/O structure supports dialog between main memory and I/O controllers on two types of I/O channels: Data Multiplex Control (DMC) channels and Direct Memory Access (DMA) channels. For channel of either type DMC or DMA, the system maintains a next data address (i.e., the address of the location in main memory where the next unit of information transferred to or from a peripheral device, via an I/O controller is to be read from or written into main memory) and a range. The range is the count of the number of units of information to be transferred between main memory via the CPU and the I/O controller (peripheral device). In the preferred embodiment the main memory is organized into words containing two 8-bit bytes. The next data addresses are specified as byte addresses and the range is specified as the number of bytes to be transferred. For DMC channels, the CPU retains and manages the range and next data address information within the CPU resident Scratch Pad Memory (SPM). For DMA channels, the range and next data address is maintained locally within the I/O controller. I/O controllers are designed exclusively for the system and are either a DMC type or a DMA type. Channel assignment is by the channel number in the software I/O instruction. The CPU supports a predetermined number of DMC input/output channel pairs, where each input/output channel pair contains one input channel and one output channel. For example, there are 64 input/output channel pairs in the preferred embodiment and they can only be used by DMC I/O controllers. However the DMC channel numbers may be assigned to a DMA or DMC I/O controller, but not both in the same system. The CPU supports operating software which includes visible registers, data formats, instruction sets, and trap and interrupt operations. Operator interface is via the control panel and the console peripheral device. The control panel permits operator access to initialize the system. CPU MAJOR COMPONENTS A major block diagram of the CPU functional areas is illustrated in FIG. 3 and is described in the following paragraphs. Control store 230 is the controller element of the CPU. It contains a read only memory which stores firmware microprograms. These firmware microprograms contain the functionality necessary to control CPU operations. Also contained within this area is all of the addressing and decoding logic necessary to sequence through firmware microprograms and issue commands to the hardware in a step-by-step manner. Microprocessor 232 is the primary processing element within the CPU. It performs all the arithmetic, compare, and logical product operations and is exclusively controlled by firmware microinstruction commands. The I/O system bus area 234 contains all the drivers/receivers and control circuits necessary for the CPU to communicate with the I/O controllers. Two buses are available: system bus A and system bus B. Main memory can only be connected to system bus B 204. The system bus area 234 is controlled by hardware and firmware microinstruction commands. Scratch pad memory 236 is a read/write memory which provides temporary storage for the CPU data. Maintained in this memory is the range and address information for DMC channels and various working registers necessary for CPU operation. This scratch pad memory 236 is controlled by firmware microinstruction commands. PROGRAMMING CONSIDERATIONS This section describes the various CPU registers that are software visible and defines the various data and address formats used by the central processor unit. Program Visible Registers There are 18 central processor registers visible to the programmer using the software instruction set. The format and significant bits of each register are shown in FIG. 4. These registers are as follows: Software Visible Registers Seven word operand registers (R1-R7). Three of these are also index registers (R1-R3). These registers are 16-bits each. Eight address registers (B1-B7 and P). These registers are 16-bits each. Mask (M1) register (eight bits controlling trace and overflow trap enable). Indicator (I) register (eight bits; overflow, reserved for future use (RFU-not used), carry-out, bit test, I/O, greater than, less than and unlike signs). Status (S) register (16 bits; privileged mode bit, processor ID (four bits), priority level number (six bits)). Word and Address Formats This section defines the various word and address formats that are used by the central processor unit and shown in FIG. 5. All data word elements, such as a bit or a byte, are based on 16-bit main memory words. The format of each word is defined from left to right with the first bit numbered 0 and the last bit numbered 15. Main memory data elements may be accessed by instructions to the bit, byte, word or multiword data item level. In all cases, the leftmost element is the most significant element of the word; e.g., bit 0 is the first bit, bit 1 is the second bit, bits 0 through 7 are the first byte, bits 8 through 15 are the second byte, etc. Multiword items require successive word locations; the lowest address is defined as the leftmost or most significant part of the data item. An address pointer is used to point to bit, byte, word or multiword data items. This address indicates the leftmost and most significant elements of the data item. Within an array, data items are numbered left to right. CPU addresses, address registers and program counters contain 16-bits and store word addresses. The rightmost bit (bit 15) of any address field is the least significant bit of the word address and all address fields are unsigned. The system can be configured for addressing up to 128K bytes (1K=1024). Byte dependent addresses for DMC data requests are stored in CPU scratch pad memory as a 17-bit address. The least significant bit (bit 16) is set when byte one is addressed. The address formats for a memory word and a memory byte are shown in FIG. 5. MAIN MEMORY Main memory can be configured from a minimum of 4 KW (kilowords) to a maximum of 64 KW. Memory consists of a read/write random access memory. The main memory is contained on memory boards installed on system bus B. Main memory size can be increased in 4 KW increments with a minimum of 4 KW of main memory configured in the lowest 4 KW address space. The memory size switch on the CPU must be set to correspond to the size of the main memory configured in the system so that the CPU can check for memory addresses that attempt to reference nonexistent main memory. As will be discussed in detail later, the CPU checks for references to nonexistent main memory for all memory access whether the access is being done on behalf of the CPU (for software instructions or data), or on behalf of a DMA or DMC I/O controller (for data from or to a peripheral device). CPU AND SYSTEM BUS INTERFACES There are two external interfaces for the central processor with the system bus: system bus A interface and system bus B interface. The system buses A and B are part of the system chassis and provide a communications path between the CPU, main memory or the I/O controllers. These system buses also distribute power to the controllers and main memory. The system buses A and B are nearly identical and contain approximately 50 wires, or signals, each, the difference being that system bus B has a main memory interface in addition to the set of signals on system bus A. Refer to FIG. 6 for a list of signals. SYSTEM BUS A System bus A distributes power and provides a communications path for data transfers and interrupts between the CPU and each I/O controller (IOC) inserted in the bus connectors on the system bus A side of the system chassis. The CPU controls system bus usage and allocates service request cycles on a separate time basis. Each IOC on system bus A is only allowed to request service (for data transfer or interrupt purposes) at a time that is unique to that I/O controller and is a function of the position (relative to the CPU) of the I/O controller on system bus A. The operation of system buses A and B is described hereinafter. FIG. 7 shows the signals on the system bus A. System bus A contains two signals (MEMVAL, BWAC60) which are unique to the CPU. These signals are only present on the CPU chassis slot connector of system bus A. All other signals on this bus are on identical pins of each bus connector with the exception of two positions. The BCYCOT-BA signal (system bus A cycle out time) pin of one bus connector is wired to the next bus connector's BCYCIN-BA signal (system bus A cycle in time) pin. In this way a priority timing signal is passed from one IOC to the next IOC on the bus. FIG. 6 indicates the functionality and source of each signal on system buses A and B. SYSTEM BUS B System bus B distributes power and provides a communications path for data transfers and interrupts between the CPU and each main memory board or I/O controller inserted in bus connectors on the system bus B side of the system. System bus B is similar to system bus A. However, it contains three additional main memory control signals, PMEMGO, PMFRSH, PBSFMD, which are not present on the system bus A. Therefore, main memory boards can only be installed in chassis slots on the system bus B side of the system. All other system bus B signals are similar to the system bus A but are driven by a separate set of drivers. No signals unique to the CPU chassis slot connector are present on system bus B, each signal feeds all chassis slot connectors on system bus B. The operation and control of the system buses A and B are described hereinafter. FIG. 6 gives the functionality and source of each system bus signal. As in the case of system bus A, each I/O controller on system bus B is only allowed to request service (for data transfer or interrupt purposes) at the time that is unique to that IOC and is a function of the position (relative to the CPU) of the IOC on system bus B. Main memory, although located on system bus B, does not make service requests but must still pass on the priority timing signal (BCYCOT-BB and BCYCIN-BB) for use by I/O controllers on system bus B. Although only one I/O controller on a given system bus (A or B) can make a service request at a time, two service requests can be made simultaneously by I/O controllers in the same relative (time slot) position, one on system bus A and one on system bus B. For example, referring to FIG. 2, diskette controller 2, 220-1, on system bus B can make an interrupt request at the same time that printer controller, 208-1, on system bus A makes a DMC data request. Priority between these simultaneous system bus requests, as well as other outstanding but unresponded to earlier system bus requests, are resolved by the CPU as described hereinafter. It should be noted that printer controller 208-1 on system bus A is in the second physical bus connector slot, relative to the CPU, and second bus request time slot whereas diskette controller 2, 220-1, is in the fourth physical bus connector slot, relative to the CPU, but in the second bus request time slot on system bus B. The difference between the physical bus connector slot and the bus request time slot on system bus B being due to the fact that each main memory board occupies one physical bus connector slot but does not occupy a bus request time slot because main memory never requests the system bus (i.e., main memory does not initiate any data transfers on the system bus and therefore the priority timing signals BCYCOT-BB and BCYCIN-BB need not be delayed by the main memory board). CPU HARDWARE DESCRIPTION A block diagram of the central processor unit hardware is illustrated in FIG. 8. Major CPU Functional Areas The central processor hardware is divided into four major areas: control store, scratch pad memory, microprocessor and I/O system buses as shown in FIG. 3. The following paragraphs describe at a block diagram level the components that are in each area. Control Store Now referring to FIG. 9, the control store 230 is the primary controlling element in the system. It is comprised of a read only storage (ROS) memory containing firmware microprograms and associated addressing and decoding logic necessary to interpret these microprograms. Firmware is the link between software-controlled programming and system hardware operations. Firmware contains all the functionality to control all control store, scratch pad memory, microprocessor and I/O system bus operations. These microprograms are made up of firmware words (microinstructions) arranged in a logical order. Each firmware microinstruction word contains 48 bits of encoded data, which when decoded, causes specific hardware operations. Every 500 nanoseconds, a firmware word is cycled out of ROS memory and decoded to determine the next firmware address, and to generate specific commands to the microprocessor, scratch pad memory and I/O system buses. By executing firmware microprograms in a sequential manner, hardware operations are performed in the proper order to accomplish the desired central processor action. Many firmware microprograms may be executed for one hardware activity (i.e., control panel operation, servicing an interrupt) or the execution of one software instruction. An overview of firmware flow and a description of the firmware word is provided hereinafter. An intermediate block diagram of control store is illustrated in FIG. 9 to assist in the description of CPU hardware and each block is explained in the following paragraphs. Referring now to FIG. 9, firmware is stored in a 1K location by 48-bit read only store (ROS) memory 238. Each location stores one firmware word which is permanently written in the ROS memory at the factory and cannot be altered. When an address is applied to this ROS memory the corresponding firmware word is read out. Boot PROM 240 is a 1K by 8-bit ROS memory which is only used during bootstrap operations. It contains software instructions which are loaded into main memory during initialization. The output of boot PROM 240 is wired-ORed to bits 24 through 31 of the output of normal firmware ROS memory 238. During a bootstrap operation this boot PROM is enabled and bits 24 through 31 of the normal ROS are disabled. Local register 242 is a 48-bit register that receives the addressed firmware word from ROS memory. This data is strobed in at time PTIME0 and denotes the beginning of a 500-nanosecond CPU cycle. Decoders 244 is a network of multiplexers and decoding logic which generates specific hardware commands according to the firmware word currently stored in the local register 242. The output of command decoders 244 is distributed to control panel 201, control flops 258, miscellaneous flops 264 and to other CPU Logic (see FIG. 8). Decoders 244 control various indicator lights on control panel 201. Control flops 258 consists of four flip-flops (CF1 through CF4) which can be set and tested directly by the CPU firmware under microinstruction control. They are used to remember and test for certain conditions between firmware steps. For example, control flop 3 (CF3) is used during a DMC data transfer sequence by the CPU firmware to remember on which system bus (A or B) the I/O controller requesting the data transfer is located. Miscellaneous flops 264 consists of other flip-flops which are directly settable and/or testable by the CPU firmware. Included in the group of flip-flops are the firmware watchdog timer (WDT) flop, firmware real time clock (RTC) flop and the power failure flop. Also included in this group of miscellaneous flip-flops 264 is the PCLEAR flop and the PDMCIO flop which are used by the CPU firmware to remember the state of system bus signal PBYTEX set by the responding I/O controller during proceed time to inform the CPU of the I/O controller type (DMA or DMC) during a CPU command sequence (see FIG. 20). The CPU uses the IOC type stored in the PDMCIO flop during an input address or input range CPU command to determine whether the IOC's address and range will be found within the CPU's SPM program channel table, as is the case for a DMC IOC, or received from the system bus after being placed there by a DMA IOC. Address register 246 is a 10-bit register which stores the current firmware word address. Its output is used to address ROS memory 238. The next firmware word address is clocked into this register at time PTIME2 (primary time 2) of each CPU cycle. Control store address generator 248 selects the address of the next firmware word to be read out of ROS memory 238. All addresses are branch addresses and can be either decoded directly from the current firmware word (microinstruction) or can be forced by hardware interrupts. Four types of firmware addresses are decoded directly from the firmware word and CPU test conditions (see FIG. 35D): (1) unconditional branch (UCB) to the firmware address in bits 38 through 47 of the current firmware word; (2) branch on test (BOT) condition (2 way test branch) selects one of 32 firmware testable conditions and causes a branch address to one of two firmware locations depending on the true or false state of the selected conditions; (3) branch on major test (BMT) (multiple test branch) is used by the firmware to decode software instruction operation codes and address syllables, stored constants and software interrupts by performing a 16-way branch on the selected test condition; and (4) return to normal (RTN) (hardware interrupt return branch) causes a branch to the firmware address stored in the hardware interrupt return register and is used to return to the normal firmware flow at the completion of a hardware interrupt firmware sequence. Hardware interrupt network 250 forces a branch address in the control store address generator 248 whenever immediate action by the CPU is required. A hardware interrupt address can be generated on each CPU cycle and a separate address is generated for each hardware interrupt condition. The hardware interrupt condition and priorities are shown in FIG. 9. Firmware can inhibit the detection of any or all hardware interrupt conditions. If a hardware interrupt occurs, the normal next firmware address is stored in the hardware interrupt return register 252. Hardware interrupt return register 252 is 10-bits wide and stores the next normal firmware word address when a hardware interrupt occurs. This address is then used to reenter normal firmware flow at the completion of the hardware interrupt sequence. Branch on test network 254 uses the current firmware word to select one of 32 firmware testable conditions and inform the control store address generator 248 of the true or false state of the selected condition. Major branch network 256 generates the next firmware address when a BMT (16-way) branch is performed. The current firmware word (bits 40, 41, 42 and 43) indicates if either an op-code, address syllable, constant or software interrupt condition is used to form the next firmware address. Software interrupt network 257 detects conditions that can interrupt software processing and generates a unique firmware address for each condition on a priority basis. Firmware uses these addresses to branch to the correct firmware routine to service the interrupt condition. It should be noted that BMT branch for testing software interrupt conditions is only performed at the beginning of a software instruction fetch from main memory sequence. The following listing contains the software interrupt conditions in the highest to lowest priority order: (1) register overflow trap when an overflow occurs in a CPU register (R1-R7) during data manipulation and that register has its corresponding bit set in the trap enable mask register (M1); (2) power failure when the power supply detects that a power loss will occur in a minimum of two milliseconds; (3) I/O interrupt system bus A when an I/O controller attached to the system bus A has requested an interrupt cycle; (4) I/O interrupt system bus B when an I/O controller attached to the system bus B has requested an interrupt cycle; and (5) timer interrupt when a fixed timed interrupt derived from the ac line signal used to update a real time clock. Returning now to FIG. 8, scratch pad memory (SPM) 236 is a 256 location by 17-bit random access memory used to store CPU status, I/O range and buffer addresses for DMC channels. It also provides temporary storage for data, addresses, constants and I/O byte transfers. Maintained in SPM are: 15 work locations, CPU status register and program channel table (PCT). Not all locations of the SPM are used. Refer to FIG. 10 for the scratch pad memory layout. The 15 work locations (locations 00 through 06 and 08 through 0F, hexadecimal) are used for temporary storage. Some of the uses of these work locations are temporary storage of I/O data before transfer to memory, maintaining previous program address and intermediate storage for byte swapping during DMC data transfers. The CPU status register is location 07 (hexadecimal) of SPM. This location is directly accessible by software. This location always contains the current CPU status. See FIG. 4 for bit definitions. The program channel table (PCT) occupies the upper (higher address) 128 locations of SPM. It is used exclusively by the CPU to manage DMC channel operations. The attributes of the program channel table are: (1) it consists of 64 entries, where each entry can be used as either an input or output channel because the input/output channels are half duplex (i.e., either in the input mode or output mode at any instant in time), therefore only one entry is needed per input/output channel pair; and (2) each entry consists of a 17-bit byte address and a 16-bit range and occupies two consecutive SPM locations. A PCT entry is loaded whenever an I/O load (IOLD) software instruction is directed to its associated DMC channel. Each time a DMC data transfer occurs the appropriate PCT entry is updated. Information can be read from a PCT entry via a software I/O instruction to a DMC channel specifying in its function code field one of the following I/O commands: (1) input address; (2) input range; and (3) input module. Scratch pad memory is directly controlled by the current firmware word (see firmware word description below). SPM write occurs at PTIME4 if bit 0 of the firmware word is a binary ONE. Data input to SPM 236 is from the internal bus 260 via a byte swapping multiplexer 262 (see FIG. 8). In byte operations multiplexer 262 swaps the left and right byte of the SPM input data if the left byte of the word on the internal bus 260 is to be manipulated. For DMC channels, the firmware resets bit 16 of the PCT entry address pointer in the SPM to identify that the left byte of a memory word is being manipulated. Addressing of location within the SPM is also controlled by firmware. The SPM access address comes directly from the firmware word when accessing work locations and the status register from decoders 244 in FIG. 9 via SPM address multiplexer 294 in FIG. 8. Otherwise, the DMC channel number is used when access to PCT is required in which case the SPM address comes from channel number register 296 via SPM address multiplexer 294 in FIG. 8. When performing a DMC data transfer operation, the CPU firmware uses the low order bit of the channel number (bit 9 in FIG. 24) to determine whether an input or output operation is to be performed using the address and range stored in the PCT entry for the associated input/output channel pair. MICROPROCESSOR Again referring to FIG. 8, all activity in the central processor centers around the processing capabilities of the firmware controlled microprocessor 232. All arithmetic, compare and logical product operations within the CPU are performed by the microprocessor 232 which is composed of four cascaded 4-bit sliced microprocessors to form a 16-bit microprocessor. In the preferred embodiment, microprocessor 232 is composed of four type Am2901 microprocessors produced by Advance Micro Devices Inc., of Sunnyvale, Calif. Within the microprocessor 232 is a 16-location by 16-bit register file 268, an eight function 16-bit wide arithmetic logic unit (ALU) 266, shift logic and miscellaneous logic necessary to support the microprocessor capabilities. Data input to the microprocessor 232 is the 16-bit output from the data selector multiplexer 269. The multiplexer 269 can select data from either SPM 236 output, the internal bus 260, the contents of the indicator register 270 plus the M1 register 272 or, a constant from the current firmware word from local register 242 (see FIG. 9). Input data to the microprocessor 232 can be stored in the register file 268 or work registers within the microprocessor or it can be delivered via the ALU 266 to the internal bus 260 as microprocessor output data. This is determined by the firmware input to the microprocessor. Bits 8 through 19 of the current firmware word control the microprocessor (see firmware word description below). These bits control data inputs to the ALU, the function which the ALU is to perform, and the destination of the results of the ALU. The microprocessor performs a new operation according to the firmware word at each CPU cycle (500 nanoseconds in the preferred embodiment). Maintained in the microprocessor 232 are 16 registers in register file 268, of which 15 are visible to software (see FIG. 11). A four bit address supplied to the microprocessor is used to address the register file. This address can be selected from the function register (FR) 274 or directly from the firmware word. The FR register 274 initially stores the operation code and then contains various address syllables and constants or can be incremented or decremented as determined by firmware flow. For file addressing, the FR register 274 is divided into three sections, (FR0, FR2 and FR3) and any one of these sections can be selected by file address multiplexer 276 to be used to address the microprocessor register file 268. Data input to the register file 268 is via the ALU 266. Register file 268 output data can be delivered to the ALU 266, an internal work register (Q), or the internal bus 260 as determined by the current firmware word. Data output from the microprocessor 232 is wired ORed with data input receivers from the system buses A and B at the internal bus 260. Therefore, if either of the system buses A or B receivers are enabled, the output of the microprocessor is disabled. However, firmware testable signals (ALU equals zero, SIGN, overflow, carry) are always outputted from the microprocessor 232. In addition to providing input data to microprocessor 232, the output of data selection multiplex 269 can be gated into the M1 register 272 and indicator register 270 under firmware control. Four bits of the output of data selector 269 can also be gated into quality logic test (QLT) register 278 under firmware control. The output of QLT register 278 controls the lighting of four LED indicators located on the CPU board which are used to give the data processing system operator a visual indication of the success or failure of the quality logic tests performed during system initialization. Clock 281 provides the various timing signals (PTIME0 through PTIME4 and BCYCOT) used throughout the system (see FIGS. 14 and 15). SYSTEM BUS CONTROL FIG. 12 illustrates both system buses (A and B), data paths and control signal development. The principle elements are bus subcommand decoders 244, CPU internal bus 260, separate receivers 284 and 288 and drivers 282 and 286 for each I/O system interface data/address lines, and CPU cycle out time generator 280. Firmware controls data flow over both system buses A and B and any transfer that occurs through the 16-bit CPU internal bus 260. During each CPU cycle the subcommand decoders 244 interprets the current firmware word and generates bus control subcommands which are valid from time PTIME1 through PTIME4 of the cycle. These decoded subcommands enable specific data paths and cause data transfers as required by firmware. The dialogs which can be performed over the system buses are described in the systems bus operation section below. Basic system bus control is described in the following paragraphs. Separate subcommands determine if either system bus receivers 284 or 288 are enabled to place data on the internal bus 260. If both A and B bus receivers 284 and 288 are disabled, the output of the microprocessor 232 is transferred to the internal bus 260. If data is to be sent to an I/O controller, the appropriate CPU to system bus drivers 282 or 286 are enabled causing data at the internal bus 260 to be transferred to the enabled system bus data/address lines. If data is to be transferred from an IOC to the CPU, the appropriate enable I/O controller data driver signal (PENBSA- or PENBSB-) is decoded and sent via the I/O interface to all I/O controllers on the specific system bus. However, only the IOC that requested the bus access places data on the system bus. A separate subcommand is generated when main memory is to transfer data to the CPU. The appropriate CPU receiver path must also be enabled to transfer main memory data to the internal bus. As mentioned before, all transfers are via the internal bus 260. For example, if firmware determines data is to be transferred from an IOC on system bus A to main memory on system bus B, it enables the data drivers in the IOC on system bus A (via signal PENBSA-) and system bus A receivers 288 causing data to be transferred from the controller to the internal bus 260. If it is a Direct Memory Access (DMA) transfer, firmware simultaneously enables system bus B drivers 282 causing the data at the internal bus 260 to be transferred to main memory. If it is a DMC transfer, internal bus data is first sent to SPM 236 (FIG. 8) for possible byte swapping. During a later CPU cycle, the data is retrieved from SPM 236 via the microprocessor 232 and system bus B drivers 282 are enabled, causing data to be transferred from the internal bus 260 to main memory on system bus B. The CPU cycle out time signal (BCYCOT) is used to permit the requesting of a system bus for a data transfer or interrupt by an IOC. It ensures that only one I/O controller communicates with the CPU at one time. This signal is generated every four microseconds and is propagated from controller to controller down each system bus. Each I/O controller accepts the pulse and delays it for 500 nanoseconds before passing it on to the next controller (see FIG. 13). The time in which an I/O controller delays the signal is called cycle in time for that I/O controller. As discussed hereinbefore, because main memory never makes a data transfer or interrupt request, main memory does not delay the cycle out time signal on the system bus. Instead main memory passes signal BCYCOT to the next main memory or IOC on system bus B without delay. During cycle in time is the only interval in which an I/O controller can request system bus access. If CPU firmware grants access, a link between the CPU and the I/O controller is formed, preventing any other I/O controller from access to the system bus. During this period in which the CPU and IOC are linked, other I/O controllers on the same or alternate system bus can make system bus request during their cycle in time but the CPU will not grant access to the system bus. This CPU-IOC link is done under firmware control by inhibiting software and hardware interrupts until the link is released. The CPU-IOC link is established and maintained by each firmware microinstruction word of the microprograms used to process the data transfer or interrupt request having a bit reset to inhibit hardware (and also software) interrupts. The first microinstruction with the hardware interrupt bit reset establishes the CPU-IOC link, and after establishment, the first microinstruction word with the bit set releases the link. CONTROL PANEL The control panel (201 in FIG. 9) connects directly to the CPU and allows the operator to manually initialize, bootload and start the system. The control panel includes a pushbutton (momentary) switch used to start the initialize (bootload) sequence. Depressing the initialize pushbutton switch resets the ROS address register (246 in FIG. 9 via control store address generator 248) causing a branch to the initialize firmware routine. It also momentarily grounds signal PCLEAR- on both system buses causing the I/O controllers to initiate quality logic tests (QLTs). BASIC SYSTEM TIMING Now referring to FIG. 14, the basic system timing is developed from a 10-megahertz oscillator 290, the output of which, signal PCLOCK-, is connected to the clock (C) input 5-bit shift register 291. Shift register 291 is the type SN7496 manufactured by Texas Instruments Inc. of Dallas, Tex. and described in their publication entitled "The TTL Data Book for Design Engineers", Second Edition and incorporated by reference herein. Shift register 291 has a binary ZERO at the preset enable (PE) input, a binary ONE at the clear (R) input and a binary ZERO at the preset inputs (S1 through S5). The output of AND gate 293 (signal PTIMIN+) is connected to the serial (D) input of shift register 291. The outputs of shift register 291, signals PTIME0+ through PTIME4+, are used to produce a basic 500 nanosecond CPU cycle which is divided into 5 equal 100 nanosecond time periods and is shown in FIG. 15. These times are used throughout the system to strobe and gate specific events, specifically: PTIME0 denotes the beginning of a CPU cycle. The addressed firmware word is gated into the control store local register 242 and the decoders 244 are enabled (see FIG. 9). The beginning of PTIME1 enables all system bus control signals which remain enabled through the end of PTIME4. The signal PTIME0+, which when inverted is a binary ONE from PTIME1 through PTIME4, enables the specific data paths within the system buses and internal buses via subcommand decoders 244 (see FIG. 12). PTIME2 is used to gate the next firmware address which is valid at this time into the control store address register 246 (see FIG. 9). PTIME3 is sent to all I/O controllers on the system buses and synchronizes the CPU and I/O controllers. Bus data is valid at this time. PTIME4 is primarily used by the CPU microprocessor. Any writing or storing of information within the microprocessor 232 and scratch pad memory 236 occurs at this time (see FIG. 8). Returning now to FIG. 14, the operation of the basic system timing logic will be briefly explained. Assuming initially that the outputs of shift register 291, signals PTIME0+ through PTIME4+, are a binary ZERO and that the clock stall signal PFREEZ+ is a binary ZERO indicating that the clock is not to be stalled, the output of AND gate 293 (signal PTIMIN+) will be a binary ONE. With a binary ONE at the serial (D) input of shift register 291, the occurrence of the transition from a binary ZERO to the binary ONE state of the clocking signal PCLOCK- from oscillator 290 will cause the output signal PTIME1+ to become a binary ONE which will in turn cause the output of AND gate 293 (signal PTIMIN+) to become a binary ZERO as shown in FIG. 15. With each succeeding clock pulse from oscillator 290, one of the outputs of shift register 291 becomes a binary ONE and the other four outputs become (or remain) a binary ZERO as shown in FIG. 15. Each of the outputs of shift register 291 is fed to an inverter to provide the inverse of the timing signals (i.e., signals PTIME0- through PTIME4-). For simplicity, only inverter 297 for signal PTIME0+ is shown in FIG. 14. Signal PTIME0+ is also used as the clocking (C) input to synchronous up/down binary counter 292. Counter 292 is of the type SN74LS169A manufactured by Texas Instruments Inc., of Dallas, Tex., and described in their heretofore mentioned publication. Counter 292 in conjunction with NAND gate 295 is used to produce the CPU cycle out time signal BCYCOT- which is fed down both system buses (A and B) for use by I/O controllers on the system buses to insure that only one I/O controller per system bus makes a request for that system bus at a given time. By counting down eight PTIME0+ signal transitions from the binary ZERO to the binary ONE state, counter 292 in conjunction with NAND gate 295 causes signal BCYCOT- to a binary ZERO for one CPU cycle time (500 nanoseconds) followed by a binary ONE for seven CPU cycle times. Specifically: the load (L) input of counter 292 is set to a binary ONE so that data inputs D1 through D8 are ignored (i.e., not used to preload the counter), both count enable inputs (P and T) are set to a binary ZERO enabling counting, and the up/down (U/D) input is set to a binary ZERO setting the counter to the count down mode. Thus, upon the occurrence of the first transition of the clocking signal PTIME0+ from the binary ZERO to the binary ONE state the four outputs of counter 292 (signals BCNTL1+ through BCNTL8+) become a binary ONE (counting down from zero to a binary fifteen) and the output of NAND gate 295 (signal BCYCOT-) becomes a binary ZERO. Upon the second occurrence of the transition of the signal PTIME0+ from the binary ZERO to the binary ONE state, the signal BCNTL1+ will become a binary ZERO and the output of NAND gate 295 will become a binary ONE. Signal BCYCOT- will stay a binary ONE until the 9th occurrence of signal PTIME0+ transitioning from the binary ZERO to the binary ONE state at which time the signals BCNTL1+, BCNTL2+ and signals BCNTL4+ will once again all be a binary ONE resulting in the output of NAND gate 295 becoming a binary ZERO. The relationship between the CPU primary time signals PTIME0 through PTIME4 and the CPU cycle out time signal BCYCOT- is shown in FIG. 13. Now referring to FIG. 13, it can be seen that the CPU cycle out time signal BCYCOT- (first controller cycle in) transitions from the binary ONE to the binary ZERO state at the leading edge of PTIME0 of the second CPU cycle and transitions from the binary ZERO to the binary ONE state at the leading edge of PTIME0 of the third CPU cycle. This is contrasted with the second and subsequent controller's cycle in (BCYCOT-) signals which transition from the binary ONE to the binary ZERO state upon the occurrence of the trailing edge of the PTIME3- signal and transitions from the binary ZERO to the binary ONE state upon the next occurrence of the trailing edge of the PTIME3- signal. This difference results from deriving the CPU cycle out signal by counting every eighth PTIME0, as explained hereinbefore, whereas each controller's cycle out signal is derived by receiving the trailing edge of PTIME3 signal while the cycle out signal from the previous (neighbor toward the CPU) I/O controller is a binary ZERO, as will be explained hereinafter with respect to FIG. 40. The necessary condition met by the system as embodied to function properly is that only one IOC on a system bus sees the trailing edge of PTIME3 while the cycle out signal from the neighboring IOC (or CPU) is a binary ZERO. It should be noted that at each point in time the BCYCOT- signal received by (for example) a second IOC on system bus A from the first IOC on system bus A is in the same state as the BCYCOT- signal received by a second IOC on system bus B from the first IOC on system bus B. SYSTEM INITIALIZATION The CPU will react to power-up or initialize signal as shown in FIG. 16. Now referring to FIG. 16, entry is made to the CPU initialization sequence at block 300 if the occurrence of the power on signal from the power supply is detected. Entry is also made from block 302 if the power is already on and the initialize pushbutton on the CPU control panel is pushed. In block 304 a master clear signal is sent to the I/O controller causing the IOC to initialize their logic thereby clearing the system buses A and B to invoke any self contained IOC quality logic tests (QLTs). Master clear also initializes the CPU logic and block 306 is entered. Block 306 initiates CPU firmware sequencing at control store ROS (238 in FIG. 9) location 0. In block 307 the CPU firmware tests to determine if sequence entry was initiated by depression of the initialize pushbutton (i.e., via block 302) and if so a full initialization is to be performed and block 312 entered. If sequence entry was made upon the detection of power on via block 300, block 307 exits to block 308 and less than a full initialization may be made. Block 308 tests if the content of main memory is valid (i.e., signal MEMVAL- is a binary ONE indicating that the memory save unit has a charged battery so that main memory refresh voltage has been maintained during any power off period). If main memory is valid, only a limited initialization need be performed and block 310 is entered executing a branch to main memory location 0 and software execution is begun. Main memory location 0 contains the first word of the software start up procedure. Block 310 then exits to block 324 with the software executing. If main memory is not valid, or if sequence entry was made from the initialize pushbutton, a full initialization is to be performed and block 312 is entered. The CPU firmware QLTs (resident in ROS memory 238 in FIG. 9) are executed in block 312. When the CPU firmware QLTs are completed, block 314 is entered and the software program in the boot PROM (240 in FIG. 9) is transferred to main memory (locations 100 through 2FF hexadecimal) and is executed. In block 316, execution of the software program loaded from the boot PROM results in the sizing of main memory, performance of a parity test on all available main memory and the performance of an extended CPU QLT and I/O test. In block 318, the results of the extended CPU software QLT tests are checked. If no error was detected by the extended CPU QLTs, block 320 is entered and the software boot program loads the first record off the boot load device into main memory location 100 (hexadecimal). In block 322, once the first record is loaded into main memory, a branch to main memory location 100 is executed and the CPU is running with the initialization sequence complete at block 324. If the extended CPU software QLT results in the detection of an error, block 326 is entered from block 318 and the control panel check indicator on the control panel remains illuminated and the CPU QLT indicators (LED light on the CPU board) indicate the error. Block 328 is then entered and the CPU halts. If during software execution in block 324 an impending power failure is detected by the power supply, block 330, software execution is interrupted and block 332 is entered. In block 332, the CPU attempts to perform a power failure interrupt sequence including the context save of the software program executing at the time of the power failure. Before the context save, the CPU clears the system buses to get them free for use by CPU to main memory data transfers. The context save results in the volatile CPU registers, which will lose their information if power is not maintained, being stored into main memory for preservation during the power off period. Approximately 2 milliseconds after the detection of the impending power failure main memory will stop responding to CPU requests causing the halting of software execution in block 334. CPU firmware execution will also halt in block 334 when there is no longer sufficient power. The later detection of power on by the power supply in block 300 will cause the CPU to exit block 334 and perform a partial or complete initialization depending upon whether main memory has remained valid during the power off period. SYSTEM BUS OPERATIONS System bus operations transfers addresses, data, and control information between the CPU and the I/O controller and main memory attached to the system (see FIG. 17 for data formats). All system bus operations are controlled by CPU timing and firmware sequences. This section describes the sequence of events on the system buses (A and B) that occur when the CPU communicates with an I/O controller or main memory. System bus operations can be initiated by either the CPU or an I/O controller. The CPU initiates system bus dialog for the following reasons: (1) all main memory accesses; (2) main memory refresh; and (3) function codes to I/O controllers. An I/O controller initiates system bus dialog for the following: (1) direct memory access (DMA) data transfers; (2) data multiplex control (DMC) data transfers; and (3) I/O controller interrupts. The main memory does not initiate any system bus dialog. All I/O controller initiated bus activity is on a separate time basis. Controller logic only permits an IOC to initially request a bus cycle during that I/O controller's unique cycle in time (see FIG. 13) and if no other IOC on that particular bus has already made the same type of bus cycle request (e.g., an IOC on system bus B can not make a DMC request if another IOC on system bus B has already set the line PDMCR2 to a binary ZERO but the fact that another DMC IOC on system bus A has already made a DMC request by setting line PDMCR1 to a binary ZERO will not inhibit the DMC request on system bus B). Since I/O controllers can only request the system bus during its unique cycle in time no priority circuits are required in the I/O controllers. Since two I/O buses are available and I/O controllers can request the bus for different purposes, CPU firmware reacts in the following highest to lowest priority: (1) B bus requests a DMA transfer; (2) A bus requests a DMA transfer; (3) A bus requests a DMC transfer; (4) B bus requests a DMC transfer; (5) A bus requests an interrupt; and (6) B bus requests an interrupt. By referring to FIG. 9 it can be seen that the four highest priority bus requests (DMA/DMC transfers) are treated as hardware interrupts and handled by hardware interrupt network 250. The two lowest priority bus requests (interrupts) are treated as software interrupts and handled by software interrupt network 258. Each system bus operation is controlled by CPU firmware sequences. Specific firmware commands informing the I/O controllers that the actions required are issued over the system bus. These I/O controller commands are issued on the RDDT lines (RDDT29, RDDT30, RDDT31 of FIG. 6) of the system bus and come directly from the current CPU firmware word. When firmware issues a command to an IOC, the encoded command is placed on the system bus RDDT lines and the command strobe line (PIOCTA on system bus A or PIOCTB on system bus B or both PIOCTA and PIOCTB, see FIG. 7) is forced to a binary ZERO. This causes the IOCs on the system buses to decode the command and the desired action is performed. FIG. 18 lists all the CPU firmware I/O commands that can be issued to an I/O controller. As will be discussed hereinafter in greater detail, the I/O commands listed in FIG. 18 are broadcast on the RDDT lines of both system bus A and B independent of whether the I/O controller to which a command is directed is on system bus A or B. In those cases in which the command must be directed to only one system bus, for example when answering a DMA request of an IOC on system bus B, only one command strobe line (PIOCTA on system bus A or PIOCTB on system bus B) is set to the binary ZERO state so that I/O controllers on only that system bus will see the I/O command. In other cases when the CPU is directing an I/O command to an IOC which may be on either system bus, for example, when initiating a CPU command (CPCMD) to an IOC, both command strobe lines (PIOCTA and PIOCTB) are set to a binary ZERO so that all I/O controllers will see the I/O command. MEMORY ACCESS All memory accesses are generated by CPU firmware. It requires two CPU cycles (one microsecond total) to access memory. FIG. 19 shows the sequence of events and signals required to transfer data to/from memory. During the first CPU (500 nanosecond) cycle, the write byte signals are generated (PWRTB1, PWRTB0). Signal PWRTB0 is a binary ONE if the left byte (zero) of the data is to be written into memory. Signal PWRTB1 is a binary ONE if the right byte (one) of the data is to be written into memory. These signals can come from a DMA controller or CPU firmware. In either case they are valid from primary time one through time four of the initial CPU cycle. These signals inform memory to either read a word or write the associated byte(s). At primary time three of the first CPU cycle the memory go pulse (PMEMG0) is generated. Along with the memory go pulse, the word address (16 bits) is placed on the address/data lines (BUSB00 through BUSB15) of system bus B. This address can come from either a DMA I/O controller or the CPU. In all cases it passes through the internal bus from one system bus (A or B) to the other system bus (B or A). The address (during the first cycle) and the data (during the second cycle) is placed on both system buses A and B via the internal bus. The placement of the address or data on both system buses occurs even when the address (or data) originates from a DMA I/O controller on system bus B or from the CPU as a matter of convenience to allow either system bus to be monitored for addresses or data and is not otherwise required in these cases for proper system operation. The memory go pulse causes the memory to accept the address and start its access sequence. If the access is due to DMA I/O controller request, the CPU examines the address against the maximum address allowed by the setting of the main memory configuration switch on the CPU. If the address is greater than the switch settings, it forces the memory error signals (PEMPAR and MEMPER) informing the I/O controller of the detection of a nonexistent address. The I/O controller then sets the correct bit in its status register. CPU initiated memory requests are checked for nonexistent memory addresses prior to memory go and a trap 15 results. During the second CPU cycle, data transfer occurs. If the CPU or I/O controller is to receive data, the CPU enables the memory board data drivers (PBSFMD) and at primary time 3, memory places the data on system bus B and via the CPU internal bus on system bus A. If memory was performing a full word read and detects a parity error, it forces the memory error signal (MEMPER). The CPU passes the error to system bus A with a parity check error signal (PMMPAR). If the access was due to an I/O controller request, the controller sets an error bit in its status. Parity error detected on CPU requested main memory accesses cause a trap 17. Any main memory error signals are reset at the next memory go of the next main memory operation. If data is to be written into memory the CPU or I/O controller places the data on the system bus during the second cycle and memory writes the data according to the write byte signals into the addressed location at primary time three. MEMORY REFRESH A main memory refresh cycle occurs if the CPU issues a memory go (PMEMGO) along with the memory refresh signal (PMFRSH) on system bus B. No other system bus dialog is required. The CPU issues a main memory refresh signal at least every 15 microseconds. If CPU firmware determines main memory is not being used, it can issue the memory refresh signal at anytime, thus preventing the interruption of the CPU processing to issue a memory refresh. FUNCTION CODE TO I/O CONTROLLER The CPU transfer function codes to an I/O controller during the execution of IO, IOH, IOLD software instructions, resulting in a 16-bit word being transferred to or received from the I/O controller. FIG. 20 shows the sequence of events and signals required to perform this system bus operation. The sequence is initiated by the CPU issuing a CPU command (CPCMD) on the RDDT lines and placing the channel number and function code on the address/data lines (BUSX00 through BUSX15) of both system buses A and B. The CPU will wait a maximum of 1.2 milliseconds for a response from the I/O controller identified by the channel number. During this time the CPU effectively stalls, no software interrupt can be honored but data transfer requests are serviced. The CPU stall results from firmware looping within the CPU microprogram processing the software instruction (IO, IOH, IOLD) that caused the CPU command to be issued to the I/O controller. This looping within the I/O software instruction prohibits the processing of other software instructions or responding to software interrupts. During this looping, the CPU firmware is waiting for the proceed or busy signal (PROCED or PBUSY) from the I/O controller to occur before the firmware counts down a time out counter stored in a SPM work location. The following responses are possible. No response is received if the CPU has attempted to access a nonexistent or defective resource. A CPU firmware timer detects this condition and trap 15 results. The addressed I/O controller is busy and it cannot presently accept a command. In this case the I/O controller forces the busy line (PBUSY) to a binary ZERO causing the instruction to terminate. The retry (wait) response is received if the addressed I/O controller cannot accept the new command because of a temporary condition within the I/O controller which is not related to the addressed channel number. The controller forces both the proceed (PROCED) and busy (PBUSY) lines to a binary ZERO causing the CPU to re-extract the current instruction and reinitiate the dialog. The normal response is for the I/O controller to force the proceed (PROCED) line to a binary ZERO, signalling that the I/O controller is not busy and that the CPU should complete the sequence. If the addressed I/O controller is a DMA type, it also forces signal PBYTEX low (a binary ZERO) to inform the CPU of the type of I/O controller responding. On detecting a response from the I/O controller, the CPU will issue an answer-command (ASCMD) command on the RDDT lines causing the I/O controller to reset the busy/proceed lines. When the answer command is issued, the CPU and I/O controller are linked and the CPU firmware is devoted to the CPU-I/O controller transfer. During link time the CPU examines the range value if it is a DMC controller. If the range value equals zero, the CPU informs the IOC of this condition by issuing an end-of-range (EOFRG) command on the RDDT lines. Some DMC I/O controllers require this information, others ignore it. Approximately six microseconds after the CPU issues the answer command (ASCMD), it issues an end-of-link (EOFLK) command on the RDDT lines. The time interval between when the CPU issues the ASCMD command the EOFLK command depends on the number of CPU firmware steps (microinstruction words) which must be executed for the particular function code sent in the CPCMD command. Because the CPU and IOC are linked during this time, with the CPU firmware and system buses dedicated to the IOC sequence, and hardware interrupts inhibited, as a design parameter this time is limited to approximately six microseconds to guarantee system responsiveness to hardware interrupts and system bus requests. At the beginning of the end-of-link time, if the function code was an input type, the CPU enables the IOC data drivers (PENBSX) and the data word is transferred over the address/data lines to the CPU. If the function code was an output type, the CPU places the data on the system bus address/data lines and the IOC strobes the data off the bus at primary time 3 of the end-of-link time. If the CPU is transferring a 17-bit address to a DMA controller, line PBYTEX reflects the low order address bit (byte offset) during end-of-link time. The CPU-IOC link is reset as a result of end-of-link being detected. DMC DATA TRANSFER REQUEST A DMC I/O controller initiates the DMC data transfer request sequence when the I/O controller requires a byte of data to be transferred to/from an I/O buffer in main memory. This request can only occur after a software IOLD instruction has been issued to the DMC IOC initiating an input/output operation. FIGS. 21A through 21D show the system bus dialog for the DMC data transfer sequence. Now referring to FIG. 21A, when a data transfer is required, the DMC I/O controller informs the CPU firmware by forcing the DMC data request line (PDMCRX) to a binary ZERO on the system bus on which the requesting I/O controller is located. The IOC is only permitted to force this line to a binary ZERO if the following two conditions are met: (1) the line is not already activated by some other IOC on that particular system bus and (2) at primary time 3 of cycle in time for this IOC. Cycle in time (BCYCIN signal) ensures that only one IOC at a time on a particular system bus can start a data transfer sequence. The DMC request line (PDMCRX) remains set until the CPU responds. Activation of the DMC request line causes a hardware interrupt of the CPU to the DMC request CPU firmware microprogram. When the hardware interrupt occurs, which is a function of other higher priority hardware interrupts and whether or not the CPU firmware is inhibiting hardware interrupts, the CPU acknowledges the DMC request by issuing an answer-DMC request (ASDMC) command on the RDDT lines (RDDT29 through RDDT31). At this time the CPU and IOC become linked. For approximately the next six microseconds, depending upon the number of CPU firmware steps involved in the DMC transfer, the CPU is dedicated to this DMC data transfer and no other traffic will be allowed on either system bus A or B except that associated with the DMC data transfer. At the next cycle after ANSDMC, the CPU enables the I/O controller drivers (via signal PENBSX), thus informing the IOC to place its channel number on the address/data lines (BUSX00 through BUSX15). The channel number is used by the CPU firmware to access the program channel table in scratch pad memory and also determines the direction of transfer. During the next six to seven CPU cycles, the CPU obtains the memory address and range information for this channel from the program channel table. The range is decremented and the memory address incremented and stored in the program channel table. If the range is depleted by this request, the CPU issues an end-of-range (EOFRG) command on the RDDT lines, informing the IOC that this is the last transfer (FIGS. 21A through 21D). If data is to be read from memory (FIGS. 21B through 21D) the CPU accesses memory, performs any byte swapping necessary and positions the data on the system bus address/data lines in byte position one (i.e., bits 8-15). The CPU then issues an end-of-link (EOFLK) command on the RDDT lines. This indicates to the I/O controller that data from main memory is on the data/address lines if reading from memory. The I/O controller takes this data at primary time 3 of EOFLK if a memory read is being performed. If writing in main memory, the CPU enables the I/O controller drivers via signal PENBSX, the I/O controller places the data in byte position one (i.e., bits 8-15) and the byte is transferred to SPM for possible byte swapping and then the CPU performs a memory access to write the data in main memory. End-of-link (EOFLK) causes the link between the CPU and I/O controller to be terminated and resetting of the I/O controller so that it will no longer respond to certain system bus commands until another link is established between the CPU and the I/O controller. The completion of the CPU firmware microprogram for the DMC data transfer results in the enabling of hardware interrupts (DMA and DMC data transfer requests and main memory refresh time out) each of which if pending will result in system bus traffic. It should be noted that since all system bus traffic is under the control of CPU firmware, the termination of the CPU-IOC link is not sufficient to establish other system bus traffic without the CPU firmware also allowing hardware interrupts. For example, in FIG. 21A, during CPU cycles 8 and 9 no system bus traffic can occur on either system bus because the CPU is still occupied executing the firmware microprogram for DMC input transfer from the IOC to memory. DMA DATA TRANSFER REQUEST A DMA I/O controller initiates a DMA data transfer sequence when the I/O controller requires either a byte or word of data to be transferred to/from the I/O buffer in main memory. This request can only occur after a software IOLD instruction has been issued to the I/O controller. FIG. 22 shows the system bus dialog for this sequence. The DMA I/O controller informs the CPU it requires a DMA data request by forcing the DMA request line (PDMARX) on the system bus on which the requesting I/O controller is located to a binary ZERO. This line (PDMARX) remains activated until a response is received from the CPU. The I/O controller is only permitted to set this line (at primary time three) if the following two conditions are met: (1) the line is not already activated by some other I/O controller on that particular system bus; and (2) at primary time 3 (PTIME3) of cycle in time (BCYCIN- a binary ZERO) for this I/O controller. Activation of the DMA request line causes a hardware interrupt of the CPU to the DMA request microprogram. When this occurs, the CPU acknowledges the request by issuing an answer-DMA-request (ASDMA) command on the RDDT lines (RDDT29 through RDDT31) and enables the I/O controller drivers by setting the (PENBX) line on the appropriate system bus. The CPU and I/O controller are linked and all system bus activity is dedicated to this DMA transfer only. When the I/O controller detects the answer-DMA-request (ASDMA) command it immediately does the following: (1) resets the request line (PDMARX); (2) places the memory word address on the address/data lines (BUSX00 through BUSX15); and (3) gates the write byte signals on the bus lines PWRTB1 and PWRTB0. Note, if the controller is on system bus A, the CPU enables the address and write byte signals to system bus B for main memory use. At primary time three of the answer-DMA-request (ASDMA) command cycle, the CPU issues a memory go signal (PMEMGO) and the main memory strobes using the memory go signal. If the CPU detects the address is greater than that permitted by the memory configuration switch, located on the CPU board, it informs the I/O controller by setting the memory error line (PMMPAR on system bus A and MEMPER on system bus B), causing an error bit to be set in the I/O controller's status register. In the CPU cycle following the answer command (ASDMA), the CPU issues an end-of-link command (EOFLK) on the RDDT lines specifying that the data transfer is to take place. If it is a write operation, the CPU enables the controller drivers PENSBX and the I/O controller places the data word on the address/data lines. If the I/O controller is on system bus A, the CPU enables the data transfer to system bus B and main memory. If the operation is a memory read, memory drivers are enabled by the CPU and main memory places the data on the bus (the CPU enables the data to system bus A if required) and the I/O controller takes the data at primary time 3 of the end-of-link (EOFLK) cycle. If main memory detected a parity error, it informs the I/O controller by setting main memory parity error (MEMPER) line. If required, this error is passed to system bus A by the CPU on line PMMPAR. During the CPU cycle immediately following the end-of-link signal, the CPU I/O controller link is terminated and the memory error signals (MEMBER and PMMPAR) are reset. I/O CONTROLLER INTERRUPT An I/O controller initiates a system bus I/O interrupt sequence when some data transfer is complete or some device status changes. FIG. 23 shows the dialog performed over the system bus. It should be noted that the I/O interrupt is a software interrupt and not a hardware interrupt. That is, an I/O interrupt, if accepted by the CPU, interrupts the execution of the current software program by forcing the CPU to save the current state of the software. The CPU then initiates the execution of other software dedicated to servicing the I/O interrupt. Upon completion of the I/O interrupt software, the state of the interrupted software is restored and the CPU continues executing the original interrupted software program. When an interrupt is required the I/O controller informs the CPU firmware by forcing the interrupt request line (PINTRX) to a binary ZERO. This line remains set until the CPU responds. The IOC is only permitted to activate this line at primary time 3 of that I/O controller's cycle in time and if that line is not already activated by some other IOC on the same system bus (A or B). The activation of an I/O interrupt request line (PINTRX) on either system bus causes the CPU to branch to the I/O interrupt firmware when the CPU firmware begins processing the next software instruction. Software interrupts can only occur between the execution of software instructions (i.e., the presence of a software interrupt will not be acted upon by the CPU during the execution of a software instruction but only at the beginning of the next software instruction). This is accomplished by microprogramming the CPU firmware used to implement the CPU software instructions to only branch on pending software interrupts only at the beginning of the CPU firmware microprogram which fetches and decodes the next software instruction from main memory. If an I/O interrupt is pending at the beginning of the execution of a software instruction, the CPU firmware will abort the execution of the next software instruction and branch to the CPU firmware microprogram which handles the I/O interrupt processing. During the processing of the I/O interrupt the sequence shown in FIG. 23 occurs on the system bus. If the I/O interrupt is accepted, (i.e, the priority level of the IOC is higher than the priority level of the currently executing software program) by the CPU, the CPU firmware saves the current software state and begins executing the software program associated with the I/O interrupt. If the I/O interrupt is rejected, the CPU firmware continues the execution of the software instruction without interruption. Now, referring to FIG. 23, when the CPU branches to the I/O interrupt firmware, the CPU acknowledges the request by issuing an answer-interrupt (ASINT) command on the RDDT lines. This causes the IOC to reset the interrupt request line. The CPU and I/O controller are linked and all system bus, main memory and CPU activity is dedicated to servicing the system bus I/O interrupt request. Immediately after the answer-interrupt (ASINT) command, the CPU activates the enable controller driver line PENSBX and the IOC places its channel and interrupt level on the address/data lines. If the IOC is a DMC type and the interrupt is due to a backspace, the IOC informs the CPU by setting the PBYTEX- line to a binary ZERO when transmitting the channel number and the interrupt level to the CPU on the system bus address/data lines (BUSX00 through BUSX15). In the case of a backspace interrupt, the level is ignored and the interrupt is always accepted. A backspace interrupt causes the memory address and range count in the PCT for the associated DMC channel to be altered by the CPU firmware to ignore the previous character. If not a backspace, when the CPU receives the interrupt level it determines if the level presented by the IOC is of higher priority than the current level running in the CPU. If the IOC interrupt is of high priority, the CPU will set the proceed line (PROCED) in conjunction with issuing an end-of-link (EOFLK) command on the RDDT lines and the link is terminated. If the controller interrupt is of lower priority (or equal), the CPU sets the busy line (PBUSY) in conjunction with issuing an EOFLK. In this case, the link is terminated and the IOC stacks the I/O interrupt and must wait until the CPU issues a resume-interrupt (RESUM) command on the RDDT lines. The CPU issues a resume-interrupt (RESUM) command whenever a level change occurs. The RESUM command is broadcast on both system buses A and B and monitored by each I/O controller on the system buses. When an IOC with stacked interrupts decodes a RESUM command, it sets an indicator within the I/O controller so that during that IOC's cycle in time (BCYCIN time) the IOC reissues the I/O interrupt request and the interrupt sequence starts again. The reissued I/O interrupt request will then either be accepted or rejected. If the interrupt request is rejected (PBUSY is ZERO), the IOC will once again stack the I/O interrupt and wait for a RESUM command from the CPU. Whenever a RESUM command is issued, each IOC with stacked interrupts on each system bus will make an I/O interrupt request during its cycle in time if the interrupt request line (PINTRX) is not already set by another IOC on that particular system bus. Because the I/O interrupt request line is reset by the IOC in response to the ASINT command f | ||||||