I'd be interested to learn more about the timing of the frame counter in PAL units, especially how the IRQ functions. Does it happen less often than with the NTSC frame counter?
Because if it doesn't, it could be useful to easily maintain the same resolution for an audio engine in both regions by using the IRQ to update the APU registers, instead of skipping every 6th frame on NTSC, which makes arpeggios sound muddier.
PAL Frame Counter
Moderator: Moderators
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: PAL Frame Counter
Yes the frame counter is slower on the PAL CPU (i.e. the IRQ should be similar to the video refresh length). I know of games that depend on this to have correct audio, don't know any examples that require it for IRQ but there's probably a few.
Unfortunately, exact measurements of it don't appear to be available on the wiki. You can look at emulator source (e.g. Nintendulator has tables in APU.cpp / FrameCyclesPAL) if you're just looking for numbers to plug in to your emulator.
Unfortunately, exact measurements of it don't appear to be available on the wiki. You can look at emulator source (e.g. Nintendulator has tables in APU.cpp / FrameCyclesPAL) if you're just looking for numbers to plug in to your emulator.
Re: PAL Frame Counter
I think the PAL frame IRQ runs at 50Hz, unfortunately.
To achieve a 60Hz sound update rate on a PAL system, possibly a CPU cycle counting IRQ could be used. There is one problem, which is that you don't want the sound updates to fall on top of VBL updates, but by spacing things out properly and by synchronizing the IRQ to the NMI every now and then I think it should work. (NOTE: It's possible to disable interrupts to make sure the sound update IRQ wouldn't happen on top of VBL updates, but that would cause jitter in the audio timing, so it would be better to set up things such that it can't happen at all.)
I haven't tried this method personally, yet.
To achieve a 60Hz sound update rate on a PAL system, possibly a CPU cycle counting IRQ could be used. There is one problem, which is that you don't want the sound updates to fall on top of VBL updates, but by spacing things out properly and by synchronizing the IRQ to the NMI every now and then I think it should work. (NOTE: It's possible to disable interrupts to make sure the sound update IRQ wouldn't happen on top of VBL updates, but that would cause jitter in the audio timing, so it would be better to set up things such that it can't happen at all.)
I haven't tried this method personally, yet.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: PAL Frame Counter
If you have a consistent NMI routine timing, an APU IRQ that is delayed to the end of NMI would probably end up in a stable configuration. Since acknowledging the APU IRQ resets its timer, it's eventually going to start at a consistent spot at the end of an overlapping NMI, and from there should have a finite series of fixed timings until it overlaps again and restarts the series.
This could actually be really bad for jitter, emphasizing it strongly by having a short stable pattern. It could also be really good for jitter though, if you get lucky with a stable pattern that has low deviation.
This could actually be really bad for jitter, emphasizing it strongly by having a short stable pattern. It could also be really good for jitter though, if you get lucky with a stable pattern that has low deviation.
Re: PAL Frame Counter
Really ? I was pretty sure it was arround 55Hz or something crazy like that. Sort of a compromize between PAL and NTSC refresh rates.thefox wrote:I think the PAL frame IRQ runs at 50Hz, unfortunately.
I think it's better to assume PAL sound engines are updated at 50Hz and speed up the tempo a bit in order to compensate. If you can afford a CPU counter that allows for free update of the sound engine then I'd definitely pick up something way higher than 60Hz in order to benefit from it.
Re: PAL Frame Counter
Well, I couldn't find a good source for this, so take it with a grain of salt.Bregalad wrote:Really ? I was pretty sure it was arround 55Hz or something crazy like that. Sort of a compromize between PAL and NTSC refresh rates.thefox wrote:I think the PAL frame IRQ runs at 50Hz, unfortunately.
I could test it later, I guess, but not much point if it has been done already.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: PAL Frame Counter
This is all we've got on the Wiki right now:thefox wrote:I could test it later, I guess, but not much point if it has been done already.
Wiki: APU Frame Counter wrote:TODO: describe PAL
Re: PAL Frame Counter
I tested it, it's definitely ~50 Hz. This test prints $40F2 on PAL NES ($40F2*2 = 33252, close to the PAL PPU frame length of 33247.5 CPU clocks) across multiple powerons and resets. Same result in Nintendulator. On NTSC console the value was $3A42 (also matches Nintendulator).Bregalad wrote:Really ? I was pretty sure it was arround 55Hz or something crazy like that. Sort of a compromize between PAL and NTSC refresh rates.thefox wrote:I think the PAL frame IRQ runs at 50Hz, unfortunately.
NOTE: Even though the value printed by the test exactly matches the APU cycle count documented in the wiki (for NTSC), no effort was put into precisely synchronizing with APU.
ROM + source (for ASM6) attached.
EDIT: Just as a further note: 33252 makes sense considering that 26.6017125 MHz / 16 / (50Hz) = 33252.1406.
- Attachments
-
- frame-counter-test-v01.zip
- (2.35 KiB) Downloaded 557 times
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi