To find this program the processor fetches an address from predefined (by the hardware) locations. There may be just one of these interrupt vector locations but generally there are several which allow different types of response.
In the case of the 6809 there seven interrupt vectors
FFFE/F Reset Reset signal for startup and reinitialisation FFFC/D NMI Non Maskable Interrupt FFFA/B SWI Software Interrupt FFF8/9 IRQ Interrupt Request FFF6/7 FIRQ Fast Interrrupt Request FFF4/5 SWI2 Software Interrupt 2 FFF2/3 SWI3 Software Interrupt 3The 'normal' interrupt input is IRQ. The sequence of events when an IRQ signal is received (logic 0) is:-
The first task is finding the source of the interrupt. There are a variety of ways in which this can be achieved.
Software Polling - The ISR contains program which looks at flags in each of the interfaces in turn to see whether it is the one causing the interrupt. If it is then a branch is executed to the relevant device handler, if not the next interface is examined. This is why the VIA (or PIA) has a single flag to indicate if it is causing an interrupt for whatever reason. Obviously a priority can be built into this process so that high priority devices are checked first so that if two devices interrupt simultaneously (i.e. within the same instruction period) then the one with higher priority is the one which is serviced first.
Hardware Polling - The processor, either automatically or under program control, sends out an interrupt acknowledge signal which tells the device causing the interrupt to put its device code on the the data bus so that the processor can read it. Again a priority structure can be included by daisy chaining the acknowledge signal so that an interrupting device does not send it on to subsequent devices. Thus the first interrupting device in the chain will respond with its code. Special interface devices are required for this as they need to be programmed with the appropriate device code in the initialisation part of the software. This technique is not used by the M6809.
Hardware Vectoring - This effectively means that there are different interrupt inputs for each device and different vector locations. Thus when a device interrupts the processor goes directly to the device handler. The 68000 allows this approach provided there are not more than seven devices in the system. External Interrupt Controller chips are available which provide this facility for processors which don't have it built in. They work by modifying the address sent out by the processor when it responds to an interrupt depending upon which device caused the interrupt. This technique is not available to the M6809.
In practice a combination of techniques may be used with a few devices sharing each of a few interrupt inputs. Thus software polling is kept to a minimum whilst keeping hardware to a minimum as well. This is the approach used in 6809 systems where we have two other interrupt inputs although they work slightly differently.
A more satisfactory approach is to make returning to the monitor an interrupt-like situation. Effectively we interrupt the user program to return temporarily to the monitor. Moreover since interrupts cause the processor status to be stored on the stack the monitor can then examine the stack directly and show us what was in the processor registers when the program stopped.
So we use the SWI instruction to get back to the monitor. It stacks all the registers and starts running the program whose address appears in the SWI vector locations i.e. the monitor. To run the user program the monitor executes a Return From Interrupt instruction. This restores all the registers from the stack. The monitor first arranges that the PC stack locations contain the starting address of the user program. This has the added advantage that all the other registers are restored to the values they had when the user program stopped. Thus you can continue a program from the point it was stopped without loss of data.
We find in any computer system that there are these levels of program. The equivalent of the monitor may be the operating system which allows us to communicate with the system and enter commands to load and run programs from disc. When a user program wishes to read data from a disc file you don't have to write the necessary sofware since it already exists in the OS. All you do is call up the OS and tell it to read a file by putting a code for the appropriate action in, say, AccA and a pointer to the area of memory the data should be put in in X. Again SWI makes a useful way of calling up the OS without having to specify any addresses.
The 6809 has three such SWIs. They all work the same way, they just have different vector locations allowing different programs to be run. Usually these are just different entry points in the same monitor or O.S. For example a different entry point may be needed when errors occur. If there is a disc read error then the program may have to abort with a suitable error message. A different SWI could be used in this case. In the 68000 several such instructions are provided although they have a different name, they are called traps, and some of them have specific uses, e.g. an attempt to use an illegal instruction code.