Input/Output Processor

The Input/Output Processor acts as an intermediary between the processor and a DLP.

Revision A of the V-Series specification, and prior Medium systems translated the following I/O descriptors into MLI opcodes which were then delivered to the DLP. The following table documents the general form of such I/O descriptors in which the opcode encodes the number of bytes sent via MLI to the DLP, the smallest transfer being 2 bytes (the single digit MLI opcode and the VVV variant digits).

With Revision B of the V-Series specification, the MLI op would be specified by the MCP in the I/O Control Block and no translation would occur in the IOP.

I/O Descriptors

Operation OPCode Variants A Address B Address C Address
Forward (2-byte) 40 IVVV AAAAAA BBBBBB
Forward (2-byte) 42 IVVV AAAAAA BBBBBB
(Maint)(2-address) 48 IVVV AAAAAA BBBBBB
Read Extended R/D 70 0000
Conditional Cancel 71 uvcc Generate MLI 28uv
Unconditional Cancel 72 00cc Generate Selective Clear
Test Discontinue 73 uvcc Generate MLI 2Auv


I describes the IOP variant digit (interpreted only by the IOP and not passed to the DLP).

BIT Purpose
8 Inhibit Data Transfer.
4 0
2 Translate EBCDIC characters to ASCII during Write data transfer phase
Translate ASCII characters to EBCDIC during Read transfer phase
1 Raise Real-time Interrupt upon operation completion

VVV are DLP variants sent unmodified to the DLP.

cc is the channel designation in the range 00 to 77.

u is the unit number in the range 0 to F.

v is the variant digit for the TEST/DISCONTINUE or TEST/CANCEL operations.

80-series opcodes are used by SMD DLPs.

A and B adresses are 6 or 8 digits.

MLI Opcodes

The IOP translates the opcode and VVV variant digits into a two-byte MLI operation using the following translation:

MLI Opcode Function

IOP Result Descriptor

Bit Description
A8 This bit is set to TRUE at the completion of an operation on the channel.
A4 This bit is set to TRUE if any condition bits are set in the IOP or DLP portion of the channel Result Descriptor.
A2 A DLP response to an IOP strobe was not received within 56 microseconds.
A1 The connected DLP generated an illegal sequence of Status as defined by the general MLI flow.
B8 When attempting to connect to the specified DLP, this bit indicates that the Base or the DLP is not present or is off-line.
B4 A memory parity error was detected during data transfer.
B2 There was not room in the buffer to hold the operation initiated on this Channel (not used for B49xx/V3x0/V4x0/V5/x0).
B1 A poll test was denied because the Base requested was busy (being used by another system).
C8 The DLP presented more than one word of Result Descriptor and words other than the first word were non-zero.
C4 A Poll Test was denied because the address presented to the Distribution Card contained even parity and odd is required.
C2 This bit is set of the I/O descriptor OP code is invalid. This bit is also set in the channel 8 Result Descriptor if the IOP could not successfully conclude a cancel operation (Conditional or Unconditional).
C1 Data sent to the IOP over the Message Level Interface contained even parity (Odd is required).
D8 The longitudinal check word received by the IOP at the end of the block of data did not compare equal to the one generated by the IOP.
D4 The Result Descriptor received from the DLP contained incorrect vertical and/or longitudinal parity, as inidicated by bit C1 and D8 of the Result Descriptor.
D2 A word oriented DLP was given a modulo 2 buffer (modulo 4 is required) and the DLP attempted to read or write one character past the ending address. When this error terminates an operation, the A address may be greater than the B address.
D1 The DLP requested additional C address descriptor information that was not supplied in the I/O descriptor.


Command Descriptor Formats

The V Series architecture is an extension of the earlier Burroughs Medium Systems architecture. Processor instructions have an opcode/variant field for a total of 6 digits, then zero to three memory addresses. Originally these addresses were 6 digits long, but later extended (in the B4700) to be 6 or 8 digits long.

The Medium Systems I/O Subsystem followed the same format. An I/O command consisted of 6 digits of opcode and variants (2 digit opcode, 4 digits of variants) then two memory addresses pointing to a buffer in memory, and for some command descriptors, a C address. The C address was commonly referred to as the “disk address” field, but in reality it was merely an additional 6 digits that was passed to the I/O control, and could be used for any purpose.

Originally each type of Medium Systems I/O control had its own unique set of command descriptor opcodes. For instance tape opcodes were in the 01 to 09 range, card reader opcodes were in the 20 to 29 range, and disk opcodes were in the 50 to 59 range.

When DLPs were introduced with the B4800 the decision was made to have all of the DLPs use relatively common opcodes. The DLPs resided in a separate cabinet, and the cable connecting to the processor was known as the Message Level Interface, or MLI. The DLP commands thus became known as MLI commands. MLI data is transferred on a 16-bit wide bus. The MLI command thus became a single digit command and 3 variant digits, making one 16 bit bus transfer. Additional command word transfers could follow if necessary.

Because old style I/O controls were still supported on the B4800, and to reduce the effort of software change, the IOT (I/O Translator, subsequently called IOP or I/O Processor on later systems) converted the new MLI opcodes back into a format similar to the old I/O descriptor format.

MLI only had four possible commands: READ, WRITE, TEST, ECHO. All functionality would have to be encoded in one of these four commands. Some DLPs only required a single word of command descriptor. Others, notably disk controls, required an additional two words of disk address. So that the IOP would not have to know what kind of DLP it was talking to, and from that how much data to send, different command descriptor opcodes were selected, based on the amount of command descriptor to transfer.

Command Descriptor MLI Opcode Command Words
40 (Read) 8 1 (2)
41 (Read Backward) 8 1 (2)
42 (Write) 4 1 (2)
44 (Test) 2 1 (2)
48 (Echo) 1 1 (2)
50 (Read) 8 2.5 (2+3)
52 (Write) 4 2.5 (2+3)
54 (Test) 2 2.5 (2+3)
C Address Sizes

It can be seen that command descriptor codes of 40 and 50 were both a Read command, and both generated an MLI opcode of 8. The difference was that the 50 command would send a 6-digit “disk address” field in the following two words. (I believe the 6 digits were right-justified in the 8 digit field, but I no longer recall for sure.) The same differentiation exists with all corresponding 4X and 5X series command descriptors.

The initial DLPs that required a “disk address” only required (or accepted) a 6-digit address field. In most cases this field was a decimal disk sector number, but for some disk drives the value could be a 6-digit binary number. Some other DLPs made rare use of a few digits in this 6-digit field for other purposes.

As disk sizes increased, it became very obvious that a 6 digit decimal sector address was insufficient, and even a 6 digit binary address was becoming strained. The SCSI specification was defining CDBs (Command Descriptor Blocks) in various sizes, where the main difference in CDB size was the length of the disk address field. The SCSI DLP implmented in Mission Viejo allowed an 8-digit address field in it's first release, and would in theory permit larger address fields later. Certain Large Systems Datacomm DLPS used many words of command descriptor. (These were not used by Medium Systems or V Series, but there was constant political pressure to adopt them, and that had an effect on I/O subsystem design at the hardware level.)

The size of the address field was determined by the size of the C field of the I/O Descriptor, and this in turn was determined by the I/O Descriptor opcode leading digit. 4X defined no C address, and 5X defined a 6 digit address. The only way to get a larger address was to define a new leading digit. This was finally done in Revision A of the V Series specification (or possibly in a late revision of the B4900/V300 Medium Systems specifications). As shown above, 6X opcodes have an 8-digit C address field, and 8X opcodes have a 10-digit C field. The 7X opcodes were skipped as they had previously been assigned to IOP-direct opcodes which are only issued to channel 08.

Data Transfer

A Write command trannsferred data from host memory to the IOP and DLP, and then to the device connected tohe DLP. A Read command read data from the device, through the DLP and IOP, and into host memory.

The A and B addresses on the I/O Descriptor designate the host memory buffer area. In most cases the IOP will transfer data beginning at the A address, and increment that address (in an internal register) until the DLP terminates the transfer or until the A address reaches the B address. In the later case the IOP would terminate the transfer with the DLP.

The 41 (Read Backward) opcode was a special case of the 40 (Read Forward) opcode. It was only used with tape drives, though could have been used on any device that would have accepted a 40 command. Only the IOP knew the difference between the 40 and 41 commands, the DLP saw an MLI command of 8 in either case.

A non-streaming reel-to-reel tape drive (7 track through GCR) could read either forward or backward. When reading the tape in a forward direction data was placed in memory normally, using the Read Forward opcode. When the tape was read backward, the data would be presented to the host in reverse byte order. If the data was stored normally in memory, it would be byte reversed, and unusable by most programs. To get around this problem, the Read Backward opcode told the IOP to begin storing data just below the B address, decrementing the B address until the transfer terminated or it reached the A address. As Read Backward was almost universally used with fixed-size tape blocks, the final B address would equal the A address, and it was generally an I/O error if this was not the case.

The 41 opcode did not tell the Tape DLP to read the data backwards. A variant bit in the three variant digits of the MLI command did this. It was therefore possible to issue a read backward command but have the DLP read in a forward direction, which would produce reversed data in memory. Or alternately to tell the DLP to read backward but use a Read Forward command to the IOP, which again would reverse the data in memory. While this produced amusing results they were not generally useful, and the MCP was careful to match the necessary “backward” variant bit with the Read Backwards opcode.

Channel Number Ranges

Medium Systems, B2500 through B4700

In the original Medium Systems I/O subsystem, there were two banks of up to 10 I/O controls in each bank. The controls in the first bank were numbered 00 through 10, and in the second bank 10 through 19. Thus there were a maximum of 20 I/O controls on any B2500 through B4700 system. (But since a Tape control could handle up to 10 tape drives, and some Disk controls could handle – in theory – as many as 40 disk drives, it was possible to have literally hundreds of peripheral devices on one of these systems. Systems with as many as 20 tape drives and 10 disk drives were not uncommon.)

Most I/O controls were designed to control “local” peripherals located in the machine room, such as card readers, tape and disk drives, and the operator console. However, Medium Systems were also used to manage legions of remote devices connected with serial interfaces, often over a telephone line. There were two basic ways to connect these devices. A Single Line Control (SLC) could manage a single half-duplex serial connection. At the other end of the line could be something like a single teletype, or more likely as many as 20 to 40 “poll/select” polled terminals. Burroughs made a wide range of P/S type terminals for many purposes, including many automated devices. Typically a single datacomm line would not handle more than 10 to 20 P/S terminals, as only one could communicate at a time, and with a large number of active terminals the latency could become unacceptable.

To handle hundreds of terminals would require many lines, and thus many Single Line Controls, using up much of the system I/O capability. To get around this a single Multi-Line Control (MLC) could be installed in the system. This used two channel slots, either 00 and 01 or 10 and 11. Typically it was installed in channel 00.

The MLC made an additional 36 channels available, numbered 20 through 55. Each of these “channels” was actually a small adapter attached to the single MLC. The MLC was a multiplexor channel. It had the logic to manage many different host buffer ranges at the same time, and to transfer data to many different adapters. The adapters were primarily level converters and serial FIFOs to convert the byte-wide MLC data into serial bits of the appropriate form.

This a Medium System could have up to 56 channels, numbered 00 to 55 sequentially. Because controls and MLC adapters were individual items, it was possible (and common) to have “holes” in this numbering range on any given system.


The B4800 was a transistion system in many ways. It was the first system to have a DLP-based I/O subsystem, but it also retained the earlier B3500 Channel-based I/O subsystem, with some limitations.

DLP addressing was based on 8 DLPs in a “base”. The original IOT could address up to 8 bases, for a total of 64 DLPs. Because Medium Systems were decimal machines, it was decided to start each Base addressing at a multiple of 10. So channel number ranges became 00-07, 10-17, 20-27, etc, up to 70-77.

If the older channel-based I/O controls were also to be used, they retained their starting addresses of 00 and 10. However, each channel group was limited to 8 channels to fit in with the 00-07 and 10-17 channel numbering scheme. Also, the extra processor hardware required to support the Multi-Line Control did not exist in the B4800, so a B4800 could not use an MLC. In its place a number of datacomm DLPs could be used, or more commonly a DCP (DataComm Processor) connected to a single host control.

Under certian conditions (see Channel Busy below) it was necessary to send commands directly to the IOP. The IOP was given its own channel number for this, channel 08.

B2900-B4900 and V Series

The 900 series processors were completely new implementations of the Medium Systems architecture. Their two most important characteristics were that they were microprogrammed using firmware (and thus could have firmware upgrades) and they had a strictly DLP-based I/O subsystem.

The channel numbering was retained in groups of 8 starting with channel 00. The maximum number of DLP bases that could be attached to a system varied, but the maximum of 8 bases and 64 DLPs was retained; thus the highest channel remained 77. The IOP channel remained channel 08.

Channel Busy

Historically most Medium Systems I/O controls could only perform a single I/O operation at a time. To insure that this requirement was not violated, the processor (later the IOP) contained an array of “channel busy” bits. When a command was issued to a channel the Channel Busy bit was set for that channel. The bit was cleared when the channel completed the operation and stored the Result Descriptor. If an attempt was made to issue a second I/O command to the channel while Channel Busy was set for the channel, the Initiate I/O (IIO) opcode would fail, with a processor R/D indicating channel busy.

Some I/O controls (notably Datacomm controls) could have opcodes (usually some form of Read) of indeterminate or even theoretically infinite time duration. The system might wish to terminate such an operation at some point and issue a different operation. These controls implemented a Cancel operator that would (conditionally or unconditionally, depending on the I/O control implementation) terminate the current operation. These Cancel operations were unique in being able to ignore Channel Busy and be issued to a busy channel.

When the DLP I/O subsystem was defined, the possibility existed for the DLPs to be able to handle more than one operation at a time. However, the Command Descriptor format and IOT (IOP) implementation prevented this; Channel Busy still existed and only one I/O could be issued to a channel at a time. Further, the DLPs had no Cancel operation defined, so there was no way to gracefully terminate an I/O operation.

To allow DLP I/Os to be terminated, the IOP implemnted a Cancel command. This would be issued to channel 08 (which was not busy) with the channel number to cancel in the final two variant digits of the Cancel command. This would end up sending a hard Reset command to the designated DLP. This was not a graceful way of terminating in-process commands, but it was generally functional.

Later DLPs implemented Test/Cancel or Test/Discontinue commands of their own, permitting a graceful termination of an in-process command. However, the Channel Busy bit still prevented direct use of these commands by issuing them to the channel directly. The B4900 (and subsequent) IOPs allowed a special Discontinue command to be issued to channel 08. This looked to the host very much like a Cancel command, but it would internally issue a Test/Discontinue to the addressed DLP.

I/O Contol Blocks (IOCBs)

The limitation of only a single I/O in process to any DLP was becoming more and more severe as time went on and processor performance advanced. Almost all new DLPs that handled multiple devices were capable of multiple initiate operation, as it was called. But the Command Descriptor and IIO implementation along with Channel Busy bits all but prohibited multiple initiation to a single channel.

The second version of the V Series system specification solved this problem. Instead of a single Initiate I/O (IIO) operation pointing to a command descriptor and designating a channel, and a single result descriptor location for that channel, the new specification defined I/O Control Blocks.

Each I/O Control Block contained an MLI command directly, a channel number that it would be issued to, buffer starting and ending addresses, various IOP flags (such as a backward transfer indication), and space for the IOP to store the MLI result words, and also the updated buffer starting and ending addresses. Since each IOCB contained room for temporary IOP working storage related to the specific I/O, and contained space for the results of the I/O, it was at last possibble to issue more than one I/O to a given DLP at once.

Real-Time Queuing

Medium Systems and V Series machines have always handled a very special class of device: the Check Reader-Sorter. This is a physically large (and very expensive) device that will read checks at high speed, transfer the data to host memory, and then endorse the check and sort it into one of a number of “pockets”. This sorting operation may run at 1600 to 2400 documents/minute. To correctly endorse and “pocket select” a check requires a user application program to receive the check data, possibly correct errors in the data, and then formulate the endorsement text and determine the pocket number to sort the check to. This information must be transferred back to the sorter.

All of this must occur while the check moves less than two feet, even at 2400 documents/minute. This requires approximately a 6-8 millisecond response time between the I/O Complete for the document read and the I/O transfer to send the pocket selection and endorsement information back. A typical V Series machine could handle at least 8 reader-sorters simultaneously; reports were received from sites with more than 16 sorters. Obviously this leaves a very small time interval to do the necessary host processing, and demands that the processing not be delayed by applications such as online banking transactions that may be supported on the same machine simultaneously.

To support this the V Series IOCB specification defined two IOCB queues; a “real time” queue and a normal priority queue. When a reader-sorter was running, the MCP would assign all of the check reads and the resulting pocket select I/Os to the real time queue. All other I/O devices on the system (and “non flow” operations to reader-sorters) used the normal priority queue.

The IOP made sure that it would always present real time results to the processors before it reported any normal I/O completes. The MCP would then process real time I/O Completes completely in control state to avoid the possibility of being interrupted. Even the user-program pocket select routine was run in control state.

Performance Note

The V300 could support at least 8 reader-sorters. The average V Series instruction took about 9 clocks on a V 300 at a clock rate of approximately 8MHz. This gives about 1,000 machine instructions maximum that could be executed for each check to be processed. This includes all instructions in the interrupt and I/O completion path, and all instructions in the MCP necessary to initiate the subsequent pocket select I/O operation, as well as all instructions in the user's pocket select routine. The measured path length was typically around 600 instructions, leaving ample processing time for online banking and other applications.

Result Descriptors

Before IOCBs

When a command is issued to an I/O control or DLP, the system will want to know both when the command completes, and when it completes, if it completed normally or with some sort of error. If the I/O completed with an error the host will generally want to know the specific type of error, so that it can determine if it is possible to retry the operation and possibly correct the error.

In the original Medium Systems, the fixed channel numbering arrangement led to a fixed-address arrangement for channel results. Each original Channel I/O contol made a 4-digit “Result Descriptor”, or more commonly “R/D”. The R/D for channel 00 was stored at absolute address 100, and each subsequent channel R/D was stored at 20 digit offsets beyond this. Thus, for example, the R/D for channel 05 was at address 200 (100 + 20 * 05).

When a result descriptor was stored the I/O subsystem would interrupt the processor if it was in Normal State and not halted. When the processor got an interrupt it still needed to find out which channel (or possibly multiple channels) had completed and stored result descriptors.

To do this the Scan R/D (SRD) operator was used. This was a very special linked-list search operator designed specifically for quickly locating a “complete” R/D in system memory. As mentioned, each I/O result descriptor (and for that matter, the processor result descriptor) were 4 digits long, on 20 digit increments. The SRD operator was given an intial address in the range of 0000 to 9999 in its 4 variant digits. This was presumably the address of a result descriptor. The SRD operator would examine the first digit at this address to see if the 8 bit was set. If it was not, this channel was not “complete” (it might not even have had an I/O issued) and SRD would link to the next channel to examine. It did this by picking up the 4 digits immediately following the 4 digit R/D, and using it as the address of the next R/D to examine. This continued until a “complete” R/D was found or until a channel link of 0000 was found.

Because each channel (and later DLP) only had one “result” address, and it could not be determined how long it would take the system to find a result once it was stored, it is obvious that it would have been easy to lose channel results if multiple I/Os could be issued to a channel at once. This was one of the major reasons for the “Channel Busy” bit described above.

The original Channel I/O R/Ds were one 16-bit word long, and gave the status of the I/O transfer from both the system's and the I/O devices point of view. For instance, the I/O device might have successfully stored data, but when reading it from memory the control might have received a memory parity error. The memory parity error was not a device failure, but it was still a transfer failure relating to the particular operation.

When DLPs were invented, they could oringally have up to three 16-bit words of result descriptor. However this result descriptor was only from the DLP's “point of view”. In the above scenario it would not have anything to report about the memory parity error, as the DLPs did not directly access memory. A memory access error due to exceeding memory bandwidth would also not be reported.

Because the DLP R/D did not report “host oriented” errors affecting the success of the transfer, the IOP also had an R/D word for each I/O. This word was the same format for all I/O transfers, regardless of the DLP that was addressed. It contained the “host oriented” information such as memory errors, and also had “bus oriented” information about the path between the host and the DLP. There were for instance two “bus parity error” bits in the R/D. These could be set if data received from the DLP had an error when it reached the host. Most DLPs also had one or more “bus error” bits. These would be set if data sent from the host to the DLP had an error on arrival at the DLP.

For the DLP I/O subsystem, the IOP R/D word went into memory at the same address the corresponding Channel R/D would have gone. So the DLP 00 IOP R/D word was at address 100. Because the SRD link was at address 104, the first word of the DLP R/D was stored at address 108, just past the link.

While there was room to store the first DLP R/D word in memory, for historical reasons the remaining 8 digits between R/D slots was committed to other uses, and any remaining R/D words could not be stored directly in memory. As most DLPs at the time only made a single R/D word, this was not a major problem. For the cases where there was more R/D, the remaining words were stored in scratchpad space internal to the IOP. A special “Read Extended R/D” command would be issued to the IOP (Channel 08) to get the two remaining words of R/D. A bit in the IOP R/D word indicated when this extra information was present.

Later DLPs implemented more than three words of DLP R/D for certain operations. The words after the first three were not accessible before the advent of IOCBs.

IOCB R/D Storage

Each IOCB contains enough storage space for the largeest possible R/D for the DLP. The IOCB format indicates the length of both the command and result descriptor locations. The MCP must know how much space to allocate for each command, and how much space to allocate for the largest possible R/D for the device. If insufficient R/D space is allocated any remaining result words will be lost. The DLP R/D is stored sequentially, as there is no need to skip over an SRD “link word”.

The IOCB format also contains storage for the IOP R/D word, since the invention of IOCBs did not solve the problem that the DLP R/D does not contain host-oriented result information.

dlps/iop.txt · Last modified: 2012/02/04 16:16 by scott
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki