Bregalad wrote:
- It's a use of that damn IRQ label you have to put somewhere if you don't use it by anything else
That's a pretty lame pro. It's not hard to just have your IRQ vector share the Reset label or something similar.
Quote:
- It is (almost ?) the same frequencey on NTSC and PAL systems, and you will never suffer to have music plaiyng slower on PAL nor having to compensate this by software by changing tempo values,
Games will have to compensate for PAL mode if they want to be compatible anyway. Not just the tempo, but tone pitch changes, so even if you use Frame IRQs to drive the music engine, you'll still need to make adjustments to be PAL friendly.
If you design your music engine with PAL support in mind from the start, compatibility isn't that hard at all. You could even do a mock-up PAL tempo support with something as simple as:
Code:
PAL_music_play:
JSR NTSC_music_play
DEC pal_tempo_adj
BNE :+
JSR NTSC_music_play
LDA #$05
STA pal_tempo_adj
: RTS
That will call the normal (NTSC) play routine 1 extra time every 5 frames, effectivily making the music 1.2x faster (changing ~50Hz to ~60Hz)
Quote:
wich can cause sound bugs in some games (aka Megaman 3's protoman whistle).
Was there even a PAL version of Megaman 3? If so was it ever dumped? I only have (U) dumps in my collection (all NTSC). This sounds like it's more of a problem with Megaman 3 not being adjusted
at all for PAL. Which doesn't have anything at all to do with APU IRQs vs. NMI.
Quote:
- Your main code will get interrupted (so timing code isn't possible during the frame).
This is a big turnoff, for me (but there's a bigger one I mention later). All the other game logic already is driven by NMI rates, so why complicate things by having two different logic regulators running at the same time?
Quote:
If you have anyother use of the IRQ vector, it may be annoying to have to detect from where did the interrupt come from, and can loose time in timing critical IRQs
Not really -- Reading $4015.6 will tell you whether or not your IRQ is caused by APU frame IRQs, so differentiating between mapper and frame IRQs is as simple as:
Code:
IRQ:
BIT $4015
BVS apu_frame_irq
JMP mapper_irq
The REAL downside to using APU frame IRQs to regulate the music is that it borks split screen effects. APU Frame IRQs can (and will) occur at any point in the frame -- and the music driver will eat quite a substantial amount of time.
Even with the aid of mapper IRQs things will get screwed up real fast if you're not careful. Say you have your mapper IRQ set to trip on a scanline where you want to split the screen. Now what happens when your APU IRQ trips 10 cycles before your mapper IRQ would trip? You're essentially screwed, as the music driver code will run first, postponing your split-screen code until you RTI (which will take several scanlines).
One solution to this is to acknowledge the APU frame IRQ and then CLI right away so that another IRQ can interrupt your APU IRQ code. This could work, but the extra latency of going through an second IRQ will really make it harder to time a hit to HBlank.
Personally -- I would just stick with NMIs. KISS. There's no real benefit for using APU frame IRQs in this fashion and it adds a world of unnecessary complication.