80-Bus News

interrupt, the Z80 CPU automatically disables interrupts, that is, it won’t accept any more until it is told to. This has the advantage that you can control where your routines are interrupted. Say for example, that you had a disk unit, which was driven under interrupt control. Every time it needs data, it interrupts for it. Some disk units read data every 25uS, and if the data is not accepted in time by the CPU they report an error. In addition to this disk, suppose you have a RTC which ticks every 1/10 sec. Each tick is signalled by an interrupt, and the CPU writes the time to the corner of the screen.

So, you are reading sectors from your disk and your clock is ticking away. In the midst of the reading you get another interrupt for a tick, go and service that, and return to your reading service routine. Unfortunately, your tick service routine takes some 2 or 3 mS, and when you get back to reading, you’ve missed about 100 bytes so your disk reports a bad read. So you try again. Same story. The only way you can deal with this is to let the CPU disable interrupts on the first interrupt, and not to reenable them again until the read is finished. Fair enough – a read is so quick that it won’t matter if the clock on the screen is not updated for a few 1/10s of secs. There is another way to deal with the problem – interrupt priority. This assigns to each device a certain priority, and only devices of higher priority than the device under service can interrupt. We’ll come to this in a moment or two. The 8080 interrupt response (IM 0) is automatically invoked after a reset, with interrupts disabled. This mode allows (using the restarts) eight different interrupt handling routines. It is possible to make a number of devices share common handing routines, or for the appropriate routine to be selected for the device by the handler. This means that the handler has to identify which device has interrupted, which adds to the time overhead. In S100 systems, which were originally 8080 based, interrupt response was often obtained by using unintelligent devices. When the peripheral response was required, they did nothing. Using open collector bus drivers, the effect of the pull up resistors was to make the bus read as high, so the CPU thought that there was a byte 0FFH on the bus. This meant that RST 38H was most frequently used. This provoked Zilog into providing Interrupt Mode 1.

IM 1 is similar to the NMI response. On interrupt, the CPU executes a call to location 0038H. This allows only one interrupt handling routine, but has the advantage of hardware simplicity. In a controller, there could be two interrupts, the more important one on the NMI line, and the lesser on IM1. The lesser interrupt could be disabled by the program at will, and by the NMI routine. The NMI routine would always take priority. In IM1, the peripheral device need not place any byte on the bus. Use of that mode will automatically get you to location 038H on interrupt.

The last interrupt mode of the Z80 is IM2. This is at once the most interesting and the most baffling interrupt method. What happens is this: in the I register, the CPU holds the high byte of an address of a table which points to all the interrupt handling routines. On interrupt acknowledgement, the peripheral places the low byte of an address on the bus. The CPU reads this byte and builds up the address of a line of the table. From this line of the table, it takes the address of the appropriate interrupt handling routine. The confusion arises because the address built up by the CPU and peripheral is not the address of the interrupt handling routine – it is the location where the address of the interrupt handling routine is stored. Further complication is introduced by the fact that we have to set up the ‘I’ register. This cannot know the address of the interrupt service table otherwise. We also have to tell the peripheral the appropriate line of the Interrupt Service Table. We must not forget also that we must construct this table, and all this before we Enable Interrupts. In addition, the peripheral, if a Zilog peripheral, is so complex that we have to spend a little time letting it know just what we want it to do.