How do interrupts work on the Intel 8080?

问题:

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 detailed explanation about it, to emulate this CPU.

回答1:

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.

回答2:

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.

回答3:

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 INTerrupt 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.

回答4:

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.

回答5:

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.