How do interrupts work on the Intel 8080? I have searched Google and in Intel\'s official documentation (197X), and I\'ve found only a little description about this. I need a d
The 8080 has an Interrupt line (pin 14). All peripherals are wired to this pin, usually in a "wire-OR" configuration (meaning interrupt request outputs are open-collector and the interrupt pin is pulled high with a resistor). Internally, the processor has an Interrupt Enable bit. Two instructions, EI and DI, set and clear this bit. The entire interrupt system is thus turned on or off, individual interrupts cannot be masked on the "bare" 8080. When a device issues an interrupt, the processor responds with an "Interrupt Acknowledge" (~INTA) signal. This signal has the same timing as the "Memory Read" (~MEMR) signal and it is intended to trigger the peripheral device to place a "Restart" instruction on the data bus. The Interrupt Acknowledge signal is basically an instruction fetch cycle, it occurs only in response to an interrupt.
There are eight Restart instructions, RST 0 - RST 7. RST 7 is opcode "0xFF". The Restart instructions cause the processor to push the program counter on the stack and commence execution at a restart vector location. RST 0 vectors to 0x0000, RST 1 vectors to 0x0008, RST 2 vectors to 0x0010 and so on. Restart 7 vectors to 0x0038. These vector addresses are intended to contain executable code, generally a jump instruction to an interrupt service routine. The Interrupt Service Routine will stack all of the registers it uses, perform the necessary I/O functions, unstack all the registers and return to the main program via the same return instruction that ends subroutines (RET, opcode 0xC9).
Restart instructions are actual opcodes, meaning they will do the same thing if they are fetched from memory during program execution. It was convenient to use Restart 7 as "warm restart" for a keyboard monitor / debugger program because early EPROMs generally contained 0xFF in each blank location. If you were executing blank EPROM, that meant something had gone awry and you probably wanted to go back to the monitor anyway.
Note that RST 0 vectors to the same memory location as RESET, both start executing at 0x0000. But RST 0 leaves a return address on the stack. In a way, RESET can be thought of as the only non-maskable interrupt the 8080 had.
An interrupt signal will also clear the Interrupt bit so an Interrupt Service Routine will need to execute an EI instruction, generally immediately before the RET. Otherwise, the system will respond to one and only one interrupt event.
CP/M reserved the first 256 bytes of memory for system use -- and that interrupt vector map used the first 64 bytes (8 bytes per Restart instruction). On CP/M systems, RAM started at 0x0000 and any ROM lived at the top end of memory. These systems used some form of clever bank switching to switch in an EPROM or something immediately after a RESET to provide a JUMP instruction to the system ROM so it could begin the boot sequence. Systems that had ROM at the low end of the memory map programmed JUMP instructions to vectors located in RAM into the first 64 bytes. These systems had to initialize those RAM vectors at startup.
I finally find it!
I create a variable called bus where interruption opcode goes. Then, I called a function to handle the interruption:
void i8080::interruption()
{
// only for RST
cycles -= cycles_table[bus];
instruction[bus]();
INT = false;
}
INT is true when needs an interruption. EI and DI instructions handle INTE.
When INT and INTE is true interruption is executed.
An interrupt is a way of interrupting the cpu with a notification to handle something else, I am not certain of the Intel 8080 chip, but from my experience, the best way to describe an interrupt is this:
The CS:IP
(Code Segment:Instruction Pointer) is on this instruction at memory address 0x0000:0020, as an example for the sake of explaining it using the Intel 8086 instructions, the assembler is gibberish and has no real meaning...the instructions are imaginative
0x0000:001C MOV AH, 07 0x0000:001D CMP AH, 0 0x0000:001E JNZ 0x0020 0x0000:001F MOV BX, 20 0x0000:0020 MOV CH, 10 ; CS:IP is pointing here 0x0000:0021 INT 0x15
When the CS:IP points to the next line and an INT
errupt 15 hexadecimal is issued, this is what happens, the CPU pushes the registers and flags onto the stack and then execute code at 0x1000:0100, which services the INT 15 as an example
0x1000:0100 PUSH AX 0x1000:0101 PUSH BX 0x1000:0102 PUSH CX 0x1000:0103 PUSH DX 0x1000:0104 PUSHF 0x1000:0105 MOV ES, CS 0x1000:0106 INC AX 0x1000:0107 .... 0x1000:014B IRET
Then when the CS:IP hits on the instruction 0x1000:014B, an IRET
(Interrupt RETurn), which pops off ALL registers and restore the state, is issued and when it gets executed the CPU's CS:IP points back to here, after the instruction at 0x0000:0021.
0x0000:0022 CMP AX, 0 0x0000:0023 ....
How the CPU knows where to jump to a particular offset is based on the Interrupt Vector table, this interrupt vector table is set by the BIOS at a particular location in the BIOS, it would look like this:
INT BIOS's LOCATION OF INSTRUCTION POINTER --- -------------------------------------- 0 0x3000 1 0x2000 .. .... 15 0x1000 <--- THIS IS HOW THE CPU KNOWS WHERE TO JUMP TO
That table is stored in the BIOS and when the INT
15 is executed, the BIOS, will reroute the CS:IP to the location in the BIOS to execute the service code that handles the interrupt.
Back in the old days, under Turbo C, there was a means to override the interrupt vector table routines with your own interrupt handling functions using the functions setvect
and getvect
in which the actual interrupt handlers were re-routed to your own code.
I hope I have explained it well enough, ok, it is not Intel 8080, but that is my understanding, and would be sure the concept is the same for that chip as the Intel x86 family of chips came from that.
The 8080 was dependent on external hardware to control its handling of interrupts, so it is impossible to generalize. Look for information on the Intel 8214 or 8259 interrupt controllers.
Function pointers to the interrupt handlers are stored in the low memory. Some 32 or so of the first addresses are hardware interrupts: hardware triggered.
The next 32 or so address are user-triggerable, these are called software interrupts. They are triggered by an INT
instruction.
The parameter to INT is the software interrupt vector number, which will be the interrupt called.
You will need to use the IRET
instruction to return from interrupts.
It's likely you should also disable interrupts as the first thing you do when entering an interrupt.
For further detail, you should refer to the documentation for your specific processor model, it tends to vary widely.