interrupt vectors

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

Post Reply
User avatar
sepi
Posts: 82
Joined: Fri Nov 26, 2004 5:50 am

interrupt vectors

Post by sepi »

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
atari2600a
Posts: 324
Joined: Fri Jun 29, 2007 10:25 pm
Location: Earth, Milkyway Galaxy, The Universe, M-Theory
Contact:

Post by atari2600a »

To my knowledge they're read from $FFFA-FFFF each time. I'm not an expert on 6502/2A0X though...

Code: Select all

          *=$0000
loop      JMP loop
          .eof
doppelganger
Posts: 183
Joined: Tue Apr 05, 2005 7:30 pm

Post by doppelganger »

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.
Be whatever the situation demands.
tepples
Posts: 22345
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

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.
User avatar
sepi
Posts: 82
Joined: Fri Nov 26, 2004 5:50 am

Post by sepi »

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?
atari2600a
Posts: 324
Joined: Fri Jun 29, 2007 10:25 pm
Location: Earth, Milkyway Galaxy, The Universe, M-Theory
Contact:

Post by atari2600a »

the SEI instruction, I believe.

Code: Select all

          *=$0000
loop      JMP loop
          .eof
User avatar
sepi
Posts: 82
Joined: Fri Nov 26, 2004 5:50 am

Post by sepi »

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?
doppelganger
Posts: 183
Joined: Tue Apr 05, 2005 7:30 pm

Post by doppelganger »

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.
Be whatever the situation demands.
User avatar
blargg
Posts: 3717
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg »

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.
doppelganger
Posts: 183
Joined: Tue Apr 05, 2005 7:30 pm

Re: interrupt vectors

Post by doppelganger »

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.
Be whatever the situation demands.
User avatar
infiniteneslives
Posts: 2102
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re:

Post by infiniteneslives »

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...
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
lidnariq
Posts: 10677
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Re:

Post by lidnariq »

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)
User avatar
infiniteneslives
Posts: 2102
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Re:

Post by infiniteneslives »

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.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
Post Reply