• "Interrupt Vector" - a pointer to the program to run

• Hardware in the I/O system to send the interrupt signal from the device to the CPU

• Hardware in the CPU to make the interrupt program run

• What the interrupt program does

1. Save the "state" of the interrupted program

• State = program counter, AC contents, other CPU registers, if any

1. Handle the device problem

2. Restore the "state" of the interrupted program

3. "Return from interrupt" to resume the interrupted program

• What else happens

• • The interrupt program is chosen according to the "cause" of the interrupt

• • • Each interrupt vector is assigned to a particular type of interrupting event

• • Other interrupts are disabled when the interrupt program runs

• • • If one tries to happen, the CPU "remembers" it till later

• • Other interrupts are re-enabled after the interrupt program finishes

• • • The "return from interrupt" turns them back on

• • • The next pending interrupt takes place, if any

• • • If no interrupts, the main program resumes

Direct Memory Access (DMA)

The essence of modern I/O systems, and lots of other things in modern systems

Eliminates the I/O loop program

Allows I/O devices to move lots of data to or from RAM without waiting for a program.

Device does the data transfer "itself"

Hardware requirements

Both the CPU and I/O devices are allowed to transfer data across the bus

"Bus Protocol" lets them take turns

I/O devices get more complicated: each one needs MAR and MDR registers.

Interrupts indicate when a multi-word DMA transfer is done

• How it works

  • Load the MAR with the RAM address for the transfer

• • When data is ready, the device requests the bus

• • Available at the end of whatever is happening (instruction fetch, data fetch, other I/O)

• • Device does its own data transfer to RAM

• • No "interruption" of the program, except for one RAM cycle.

• Software requirements

• • NO I/O loop program

• • I/O software (device driver) must set up the device's MAR and tell device what to do.