It is currently Mon Oct 23, 2017 10:21 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 12 posts ] 
Author Message
PostPosted: Fri Jun 23, 2006 1:09 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7235
Location: Chexbres, VD, Switzerland
Frame IRQ :
- It's a use of that damn IRQ label you have to put somewhere if you don't use it by anything else
- 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, wich can cause sound bugs in some games (aka Megaman 3's protoman whistle).

Against frame IRQ :
- Your main code will get interrupted (so timing code isn't possible during the frame).
- 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
- Need of more flags/temporary variables in init-code related stuff ?

So what's the best ?

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
PostPosted: Fri Jun 23, 2006 1:55 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jun 23, 2006 2:18 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7235
Location: Chexbres, VD, Switzerland
Well, if you use mapper IRQ for split screen, you can do cli just after the bit $4015 stuff, so it will not cause so much problems. However, if you're reling on $2002 polls to do split screens, this will cause more problems.
However, if you code say an RPG, you'll have no reason to do any split effects during the frame.
Overall, I just think the frame IRQ hardware has been basically designed for sound engine purposes, and then it becomes useless if not used as it, because it cannot be used for split stuff either (this has been discussed just before).

Yes, there is a PAL version of MegaMan 3, and I don't know if it has been dumped, but I have it. On the real PAL console with the real MM3 card, when protoman whistle, you hear the sequel to the whistle song that you're supposed to hear only in the enging - because the music was fixed to play faster in the NES's viewpoint to compensate the fact that the NES runs slower, but the timer that acts in gameplay seems to not have been touched. This wouldn't happen if the music engine was running at 60Hz, because the tempo wouldn't have to be changed.
And doing the trick you shown to correct would be bad, because it would remove linearity in the sound causing pitch and volume effects to have gaps, and additionnaly it will consumme more time one frame out of six wich isn't very good.
Correct pitch is MUCH easier than correct timing, just change the values in your pitch table (assuming you have a pitch table, but I don't think how you could code a sound engine without).

BTW Megaman 3 PAL has a ton of glitches with MMC3's IRQ. On the second to last battle, where I think IRQ is normally used to scroll Wily's machine separatly from the ground the whole screen flicker. If I remember correctly, when the menu is oppen it flickers (because it is also done via MMC3 IRQ) and isn't usable. That way, the doctor Wily is totally unbeatable on the PAL version, unless it's just me. Surprising I've never head anyone about that bug, that is much more annoying than the protoman's whistle bug-

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
PostPosted: Fri Jun 23, 2006 3:00 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19119
Location: NE Indiana, USA (NTSC)
Disch wrote:
Games will have to compensate for PAL mode if they want to be compatible anyway. Not just the tempo, but tone pitch changes

By almost exactly a semitone, which can be set as a global transposition by the init code.

Quote:
so even if you use Frame IRQs to drive the music engine, you'll still need to make adjustments to be PAL friendly.

But at least an IRQ driven arpeggio will the sound the same on both systems if the pitch table is adjusted by a semitone in PAL mode.

Quote:
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

NT2's playback code does the exact opposite (skipping calls every 6th frame when run on NTSC). It causes artifacts on arpeggios, sharp volume envelopes, and similar effects.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jun 23, 2006 3:09 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
Bregalad wrote:
Well, if you use mapper IRQ for split screen, you can do cli just after the bit $4015 stuff, so it will not cause so much problems.


Yeah I hinted at that in my post. But still. IRQ+BIT $4015+CLI is 13 cycles. When you consider that HBlank is only about 21 cycles (even less on PAL) -- that extra bit of latency just makes it that much harder to time your writes so they fall on HBlank.

Quote:
However, if you're reling on $2002 polls to do split screens, this will cause more problems.


I don't see any way it'd be possible without the aid of DMC IRQs or something. Unless you periodically poll $2002 in your music driver code or something -- but that's just silly.

Quote:
However, if you code say an RPG, you'll have no reason to do any split effects during the frame.


I'm sure I could find ways to. FF3 did some status bar scrolling in its battles, if memory serves. Maybe you'd want to make it so some char stats are visible on the map screen via a status bar or something.

Quote:
then it becomes useless if not used


So you would comprimise your game and make things harder for yourself just so you could give use to specific feature of a system? That's nonsense.

So what if APU IRQs become useless? Why would that matter?

Quote:
And doing the trick you shown to correct would be bad, because it would remove linearity in the sound causing pitch and volume effects to have gaps,


Yeah, that's why I called it "mock-up" PAL support. It's rather hackish, but can be easily slapped into a setup that wasn't built to support PAL. But like I said initially -- if you keep PAL in mind when developing your music engine, supporting it isn't really that hard at all.

Quote:
and additionnaly it will consumme more time one frame out of six wich isn't very good.


considering the inflated VBlank time you're given on PAL -- I don't think that'd be much of an issue -- but you're right.

Quote:
Correct pitch is MUCH easier than correct timing, just change the values in your pitch table (assuming you have a pitch table, but I don't think how you could code a sound engine without).


And what makes correct timing more difficult? You could just as easily have a length table just like you have a pitch table.



The bottom line is, using Frame IRQs inhibits you. It makes it harder to do things, and even prevents you from doing some things. Instead of asking yourself "why not use Frame IRQs?" and then finding ways to work around the problems Frame IRQs cause -- you should be asking yourself "why bother with Frame IRQs?" I mean really -- the only pro I've heard so far is that it makes tempo adjustment for PAL support a little easier -- but really, that's not much of an issue if you plan ahead for it.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jun 23, 2006 6:41 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
I'm with Disch on this; I don't see how there can be any significant discussion of using the APU's frame IRQ. Run your sound code at the end of your NMI handler, after all time-critical stuff is done. If you're advocating any other approach, you first have to show some significant advantages, not just show how the problems can be worked around.

Quote:
The bottom line is, using Frame IRQs inhibits you.


Is that just in Soviet Russia?


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jun 23, 2006 10:39 pm 
Offline

Joined: Sat May 13, 2006 1:05 pm
Posts: 76
Location: USA
Bregalad wrote:
Yes, there is a PAL version of MegaMan 3, and I don't know if it has been dumped, but I have it.

I'm pretty sure it's undumped as of GoodNES 2.01. Not sure about the upcoming GoodNES 3.00.

_________________
This signature intentionally contains no text other than this sentence.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jun 23, 2006 11:45 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7235
Location: Chexbres, VD, Switzerland
Overall, frame IRQ has one single advantage on NMI hanlding : It has the same frequencey on both systems.
My sound driver does have a lenght table but it's sort of different : Each note is x "ticks" long, and the ticks are done by incrementing a tempo variable by the song's tempo constant every frame. If there is overflow, then the frame is a "tick" (the song logic advance), else it is not (only volume and pitch effects are done, but not the song logic).
I think the lenght table wouldn't be changed, but the tempo constant for each tune would. This would cause problems only when the main gameplay is in syncronous with the music or sound effects, but I think this is a smaller problems than problems with IRQ stuff, so definitely, frame IRQ are useless and NMI hanling is better.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jun 24, 2006 8:32 am 
Offline

Joined: Wed Mar 09, 2005 9:08 am
Posts: 348
From where did you get the information that frame IRQ is 60 Hz on PAL systems? All the tests I have performed on the frame IRQ show that it's appr. 50 Hz, and has a slightly longer phase than the NMI. This makes it a completely useless interrupt IMO. The only reason for using it that I can see is if you would build your own simplified NSF-player using just the CPU without the PPU.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jun 24, 2006 8:42 am 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
If it's around ~55 or ~56 Hz that would make a lot of sense.

Since the CPU clock rate is slower on PAL, the APU frame sequencer will run slightly slower as well. If the APU hardware is the same on both systems, then APU frame IRQs will probably run about 56 Hz:

PAL_CPU / (NTSC_CPU / NTSC_irq_rate) = PAL_irq_rate

1662607 / (1789772 / 60) = ~56



But from what you're saying it's slower than that? Closer to 50? Perhaps the APU frame sequencer steps are closer together on PAL. We may need some in-depth testing and documentation on this one.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jun 24, 2006 10:15 am 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3471
Location: Indianapolis
I never thought of any use for frame IRQ. It would trigger sometimes during vblank, wouldn't it? No way anyone would want that interrupted. So for music you'd end up with little pauses in the music playback (very brief ones, but I can't imagine it helping anything).

Quote:
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)


That burns up CPU cycles though. In the worst case, the sound frames that take longer to process than the others will get called twice.

A better way, I think would be to use fixed-point counts for the tempo. Then it would be pretty trivial to adjust it for NTSC/PAL and still run the code once per frame, just adjust some equations. Same thing applies to the rest of a game too, just that it becomes less trivial to cover everything.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jun 24, 2006 10:27 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7235
Location: Chexbres, VD, Switzerland
If frame IRQ isn't even about the same speed in NTSC and PAL, I think it really is useless.

VBlank woudln't interrupt, unless you have a "cli" opcode in your NMI code, wich would be a bad idea.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google Adsense [Bot] and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group