The Vector Pull (VPB) output indicates that a vector location is being addressed during an interrupt sequence. VPB is low during the last interrupt sequence cycles, during which time the processor reads the interrupt vector. The VPB signal may be used to select and prioritize interrupts from several sources by modifying the vector addresses.
Which doesn't really glean any useful information. So it looks like I'll just leave it as NC.
VPB is one of those signals that a first-time builder should not be considering. As Jeff suggested, ignore it for now. That said, I'll explain how it could be used.
When a hardware interrupt occurs or a BRK instruction is executed, the MPU executes a series of steps to save its state on the stack and then jumps to the interrupt service handler (ISR) code. The jump occurs by loading the program counter from a location in memory that points to the ISR that is expected to process the interrupt. As there are several interrupt types, there are several addresses involved, which are collectively referred to as the interrupt vectors. On the 65C02 or the 65C816 when operating in 65C02 emulation mode, the vectors are as follows:
Code: Select all
$FFFA/$FFFB non-maskable interrupt (NMI)
$FFFC/$FFFD hardware reset
$FFFE/$FFFF interrupt request (IRQ)
The addresses stored at these vectors are often burned into ROM, but in a unit whose operating system runs from RAM, the vectors will likewise be in RAM and could be changed. However, it gets even more interesting.
A system could be designed to prioritize IRQs, which means it would have hardware logic that can identify each interrupting device and assign it an ordinal number (interrupt number). A pecking order can be established based upon the interrupt number, making some interrupts more important than others. Nowadays, this function would be part of the glue logic in a CPLD or FPGA, but in the past was done with discrete devices. In either case, the glue logic, upon detecting an IRQ and determining which device caused it, could trick the MPU into jumping directly to the ISR for the interrupting device, eliminating the need to check all devices to see which one is interrupting. The result would be improved interrupt processing performance.
The trickery comes in two parts:
- The glue logic does nothing until the MPU asserts the VPB output, that is, pulls it low. When VPB goes low it means the MPU is fetching from the interrupt vector. It does this by performing consecutive reads from the least significant byte (LSB) at the vector address (at $FFFE in the case of an IRQ) and then the most significant byte (MSB) at the vector address (at $FFFF in the case of an IRQ). The address bytes are internally loaded by the MPU into the program counter (PC).
- The glue logic, in response to VPB going low, prevents ROM or RAM from actually driving the data bus and instead, takes control and places an alternate ISR address on it, first the LSB and then the MSB. That address is determined by the glue logic analyzing the interrupt number that it generated when a device interrupted. The MPU is none the wiser that the glue logic is talking to it and loads the alternate address into PC instead of the address at $FFFE/$FFFF. Hence execution is directed to the ISR associated with the interrupting device.
The logic to do all this is not particularly simple to implement, which is why it is something best left for a future project.
).
