Hi!
I have question about interrupt vectors.
Are interrupt vectors always fetched from $FFFA - FFFF ? or are they somehow cached in the CPU during the bootup cycle?
- Sepi
To my knowledge they're read from $FFFA-FFFF each time. I'm not an expert on 6502/2A0X though...
Yes, the program counter (PC) gets loaded with the proper address at $fffa-$ffff, depending on the type of interrupt, sometime at the end of the actual cycle count used for the interrupt itself.
Bankswitching $E000-$FFFF will affect which physical address in PRG ROM the CPU pulls the vectors from. Most mappers freeze $E000+ or $C000+ to the last bank to prevent this, but some have "32 KiB bankswitching" that allows $8000-$FFFF to be switched as a unit. This is useful if a game has multiple independent 32 KiB game engines, as the NMI and IRQ vectors can be pointed to a different handler for each bank, but it needs special care when one subroutine calls another subroutine in a different bank.
Thanks for your help!
Clearing bit 7 from $2000 disables execution of /NMI, but is there any way to prevent triggering of BRK/IRQ vector?
the SEI instruction, I believe.
Also, what if completing a interupt vector takes long enough to miss falling edge in /IRQ line?
is the interrupt cleared on RTI or when the jump to the interrupt vector completed?
The interrupt disable flag is set on the processor status register everytime an interrupt is allowed to occur. It is reset to whatever it was set to originally upon reaching RTI. It is also affected by the PLP instruction.
In general a device asserting /IRQ must hold it until the program acknowledges it. Why doesn't the processor just latch it like /NMI? Because multiple devices could be connected to /IRQ and more than one could be asserting at once.
It was while I was studying the C64 that I learned about the subtle but important differences between level and edge triggering, when I wondered how the C64 didn't overflow its stack everytime the RESTORE key was held down.
Since it's already back from the dead I thought I'd make a related comment.
blargg wrote:
In general a device asserting /IRQ must hold it until the program acknowledges it. Why doesn't the processor just latch it like /NMI? Because multiple devices could be connected to /IRQ and more than one could be asserting at once.
I recently found out that Nintendo didn't do a very good job of allowing this with the MMC3. The IRQ output isn't open collector, it's push-pull (could be line driver, I never tested it low). So it sources at 5v when the MMC3 IRQ isn't firing, and can't be 'pulled down' as it should on an open collector line. I found the issue when testing my MMC3 on a portable clone, it didn't like the open collector output I gave the MMC3 and required a push-pull. I tested an original cart and found out the MMC3 IRQ is indeed push-pull. So if anything besides the MMC3 tried to trigger an IRQ it'd have to fight against the MMC3 holding the line high...
infiniteneslives wrote:
So if anything besides the MMC3 tried to trigger an IRQ it'd have to fight against the MMC3 holding the line high...
... Like the internal audio IRQs? (tests visual2a03) Ah. Internally, the /IRQ is inverted and then NORed with internal sources, so that doesn't conflict. (phew)
lidnariq wrote:
infiniteneslives wrote:
So if anything besides the MMC3 tried to trigger an IRQ it'd have to fight against the MMC3 holding the line high...
... Like the internal audio IRQs? (tests visual2a03) Ah. Internally, the /IRQ is inverted and then NORed with internal sources, so that doesn't conflict. (phew)
Yeah it'd have to be some other external IRQ to cause a problem I guess. That'd really only be able to come from the EXP connector...
EDIT: It just occured to me why the famicom box doesn't support mmc3 IRQs... Because they made this 'error' you can't put a bunch of MMC3 carts on the same bus/line because they'd conflict with each other. So I guess they took the cheap route out and just didn't support the MMC3's IRQs.