Standard Interrupt Vector Table?

[FistOfFury]

Hi

So, I was reading about interrupts on wikipedia. Haven't messed around with zsnes or 65c816 coding in a while, but it got me thinking about interrupt vector tables.

When you're coding an SNES game, are there standard interrupt vector types that SNES or ZSNES expects? Like are they actually required so that the ROM code will load up, or is it just good programming practice to have them? And more importantly, what would the standard vectors be (or is there too many to list?) Reset/Power On? I can't think of any other types, help me out here. Maybe some that have to do with the SPC700? I dunno.

Another thing, can those vector addresses be any address location that you specify, or is there a standard or even required location? I guess reset woud be $00 or something? Err, my homebrew coding knowledge is basic and a little rusty right now, so go easy on me lol

[anomie]

When you're coding an SNES game, are there standard interrupt vector types that SNES or ZSNES expects? Like are they actually required so that the ROM code will load up

Well, you need to set the Reset vector to something sane, since the first thing the SNES does on power up is load the address at $00FFFC-D and jump to it in Bank $00. Typically, the Native NMI vector will also be used. The vectors themselves are located at $00FFE5-$00FFFF, all 16 bits specifying an address in bank $00. Any good doc should tell you the remaining details.

For the SPC700, the Reset vector is at $FFFE-F in the APU memory space. You cannot set this vector, as it is in the IPL ROM area and IPL ROM is enabled on reset. The TCALL instructions reverence a vector table at $FFC0-$FFDF, with BRK sharing TCALL 0's vector.

[OptiRoc]

Here's a complete list.

Native (65816) mode:
$FFE4 COPROC
$FFE6 BRK
$FFE8 ABORT
$FFEA NMI (triggered at vblank)
$FFEC RST (unused)
$FFEE IRQ

Emulation (6502) mode:
$FFF4 COPROC
$FFF8 ABORT
$FFFA NMI (vblank)
$FFFC RST (SNES starts here, in emulation mode)
$FFFE IRQ/BRK


It's worth of note that the interrupt vectors all reside in ROM space, so you
can't change them in run-time.

[anomie]

It's worth of note that the interrupt vectors all reside in ROM space, so you can't change them in run-time.

Not necessarily, the cart could put whatever it wants there. For example, the SA-1 allows certain of those vectors to be altered. If you enable the feature in a particular SA-1 register, the values in ROM are hidden (similar to the SPC700 IPL ROM hiding a portion of RAM) by the values of some other SA-1 registers.

[byuu]

It's worth of note that the interrupt vectors all reside in ROM space, so you can't change them in run-time.

Not necessarily, the cart could put whatever it wants there.

Another good example is Final Fantasy II/IV. The NMI is set to 0x0200, IRQ to 0x0204. In bank 00, this is a mirror of the first 8k of WRAM.
Of course, this results in the game jumping to that location, which contains a jml that is writable. So it becomes a sort of pseudo-indirect vector, if you will.

And hell the SA-1 sounds like a terrible beast >_<

[OptiRoc]

Not necessarily, the cart could put whatever it wants there. For example, the SA-1 allows certain of those vectors to be altered. If you enable the feature in a particular SA-1 register, the values in ROM are hidden (similar to the SPC700 IPL ROM hiding a portion of RAM) by the values of some other SA-1 registers.

Aha, that is rather interesting.

But, when hackin up your own software there's no way to get around your hard coded vectors, is there? Directing them to a small interrupt handler in RAM is the way to go, obviously.

[anomie]

But, when hackin up your own software there's no way to get around your hard coded vectors, is there? Directing them to a small interrupt handler in RAM is the way to go, obviously.

You could stick RAM everywhere except the RESET vector, as long as you make sure to initialize the RAM before using the rest of the vectors. Sticking RAM on the RESET vector would be difficult to make work right.