This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

What's the fastest rate of repeated IRQ possible?

What's the fastest rate of repeated IRQ possible?
by on (#207125)
I'm having trouble with the math.

If I did some kind of APU IRQ, what's the fastest rate I could get? And, yes, I know there would be a ton of overhead in the IRQ handler, making this difficult to calculate. Rough estimate? Anyone?

I know MMC3 scan line counters are NOT really useful below 2 scanlines, and that's not fast enough (7000 hz) for what I had in mind (PCM audio).
Re: What's the fastest rate of repeated IRQ possible?
by on (#207127)
If I understand correctly, a DMC irq would give you a minimum of 428 cycles between interrupts, which comes out to 4182Hz. You would need to play a sample of 10101010, which would add a slight noise to the playback as well. So DMC irq probably wouldn't work for what you're looking for.
Re: What's the fastest rate of repeated IRQ possible?
by on (#207128)
VRC3 is an easy mapper if you need to play back samples, since its timer can reset to a specific value, rather than requiring timed code to restart the timer. Maybe look at other mapper IRQs too, maybe RAMBO.
Re: What's the fastest rate of repeated IRQ possible?
by on (#207130)
See also viewtopic.php?t=14520
Re: What's the fastest rate of repeated IRQ possible?
by on (#207159)
russellsprouts wrote:
If I understand correctly, a DMC irq would give you a minimum of 428 cycles between interrupts, which comes out to 4182Hz. You would need to play a sample of 10101010, which would add a slight noise to the playback as well. So DMC irq probably wouldn't work for what you're looking for.

If you're doing that, you might as well allow to play different "samples" for up ramp, down ramp or pseudo-flat, potentially increasing sound quality dramatically.
Re: What's the fastest rate of repeated IRQ possible?
by on (#207164)
Bregalad wrote:
If you're doing that, you might as well allow to play different "samples" for up ramp, down ramp or pseudo-flat, potentially increasing sound quality dramatically.

I'm pretty sure someone posted about this technique here in the forums already... Can't find it though.
Re: What's the fastest rate of repeated IRQ possible?
by on (#207168)
I've abandoned this idea. I don't think I could get a fast enough IRQ frequency to do in-game pcm sound.
Re: What's the fastest rate of repeated IRQ possible?
by on (#207176)
My method probably has the highest sample rate possible without mapper IRQs. Depending on what you're going for, it can even do music fairly decently, but your best bet is to play something more orchestral: (This is without OAM DMAs)
https://www.youtube.com/watch?v=mddZUUcu_fU

I would be happy to help tailoring the original player to your game's needs if you see any chance for you to change your mind.
Re: What's the fastest rate of repeated IRQ possible?
by on (#207202)
That was exactly what got me started on making Squeedo (the original 2004 version), wanting the IRQ to do sampling/synthesis. Then I quickly realized the PIC MCU I used could do everything even better, ended up with NES just getting IRQ to write the PIC's generated data to $4011.

Another reason MMC3 wouldn't be useful for this, is that the IRQs stop coming during vblank.
Re: What's the fastest rate of repeated IRQ possible?
by on (#207203)
Memblers wrote:
Another reason MMC3 wouldn't be useful for this, is that the IRQs stop coming during vblank.

A related thought: what happens if you get an IRQ during OAMDMA? Can you get a ~500 cycle delay in this case?

i.e. when using the PCM IRQ would it be prudent to use OAMDATA instead of DMA? (Drastically reduces available upload bandwidth, but you could do a reasonable amount of animation maybe?)
Re: What's the fastest rate of repeated IRQ possible?
by on (#207204)
rainwarrior wrote:
A related thought: what happens if you get an IRQ during OAMDMA? Can you get a ~500 cycle delay in this case?
Yup.

This is one of the reason I think a "right" solution is to have a synthesizer directly generate DPCM instead of PCM.
Re: What's the fastest rate of repeated IRQ possible?
by on (#207206)
rainwarrior wrote:
i.e. when using the PCM IRQ would it be prudent to use OAMDATA instead of DMA? (Drastically reduces available upload bandwidth, but you could do a reasonable amount of animation maybe?)

And you have to work around the weird OAM corruption that results from using $2003/$2004.
Re: What's the fastest rate of repeated IRQ possible?
by on (#207207)
I thought as long as you set OAMADDR back to 0 before vblank ends things should be fine? (At least, I've used it before and not seen anything wrong...)

Is there some additional corruption you're talking about?
Re: What's the fastest rate of repeated IRQ possible?
by on (#207208)
I remember being concerned that OAM DMA would ruin the audio, but when I enabled it, it seemed pretty much unnoticeable to me. But that was 10+ years ago on a project where I was excited that it even worked at all (being my first hardware), so it could be a case of rose-tinted glasses (er, earphones?). I'm seriously tempted to revive my old code and find out sometime. I'd expect to hear some kind of combination of a 60hz buzz and aliasing, getting worse as the frequency gets higher.

I wonder how much worse the OAM DMA's effect would be when the NES is doing the synthesis, because those cycles are just gone. In Squeedo's case the PIC runs independently, the NES misses out on a few updates, the audio isn't permanently distorted.
Re: What's the fastest rate of repeated IRQ possible?
by on (#207209)
Memblers wrote:
I wonder how much worse the OAM DMA's effect would be when the NES is doing the synthesis, because those cycles are just gone. In Squeedo's case the PIC runs independently, the NES misses out on a few updates, the audio isn't permanently distorted.

A missing sample that's filled in with the previous value is a lot less of a problem than a complete halt/delay of the stream.
Re: What's the fastest rate of repeated IRQ possible?
by on (#207211)
Pretty easy to simulate that situation, right?

Say we're aiming for 10kHz audio, 180cy per DAC update. OAMDMA would knock out 2 samples every 16ms.

A little bit of trivial perl:
Code:
use Math::Trig;
for ($cy = $sa = 0; $cy < 297805; $cy += 180, $sa++) {
      $newsample = 63.5*(1+sin($sa*pi/5)); # sine wave at exactly sample rate / 10, so 994Hz
      if ($cy*2 % 59561 >= 1028) {
            $oldsample = $newsample;
      }
      print chr($oldsample);
}

yields this sound:
Attachment:
sim.ogg [3.7 KiB]
Downloaded 98 times


Of course, this is roughly the worst possible situation; a sine wave will make this distortion maximally audible.
Re: What's the fastest rate of repeated IRQ possible?
by on (#207216)
Neat, that does have a familiar ring to it. Thinking about the old samples I had recorded, IIRC, 001.WAV and 002.WAV are the only ones recorded while I purposely turned the OAM DMA off (they are sine waves also). Aliasing seems especially noticeable in 007.mp3 (those detuning glitches were in the music driver, I know it sounds awful).
http://membler-industries.com/squeedo/2004_version/samps/007.mp3
http://membler-industries.com/squeedo/2004_version/samps/
Re: What's the fastest rate of repeated IRQ possible?
by on (#207217)
rainwarrior wrote:
I thought as long as you set OAMADDR back to 0 before vblank ends things should be fine? (At least, I've used it before and not seen anything wrong...)

Is there some additional corruption you're talking about?

This whole OAM corruption thing confuses me to no end, but I think you're right. Setting OAMADDR back to 0 before sprite evaluation starts should work just fine.

It's just that for years we knew that using $2003/4 was unreliable somehow, but AFAIK it was only recently that the exact behavior was properly analyzed and documented. I guess I just put OAM manipulation through $2003/4 in my "list of things to never do" and it remains there to this day.

Anyway, I understand that the purpose is to be able to have PCM audio during actual gameplay, but 50% of the CPU time, slow ass OAM updates, vblank time being spent on audio... those are pretty severe restrictions, making the technique still prohibitive for most kinds of games.
Re: What's the fastest rate of repeated IRQ possible?
by on (#207218)
I know I've had situations where just writing to $2003 caused corruption, even if we write 0 to $2003 before rendering starts.

The last time this came up, Quietust said that in his tests, it works for some CPU-PPU alignments and not for others.
Re: What's the fastest rate of repeated IRQ possible?
by on (#207219)
Now that you mentioned it, I think I remember someone saying that the only safe way to use $2003/4 is to write all 256 bytes and let OAMADDR wrap back to 0 (which's exactly what an OAM DMA does, only faster). That'll eat nearly your entire vblank time, even if you use unrolled code.
Re: What's the fastest rate of repeated IRQ possible?
by on (#207220)
last time

That was me.

You can also safely write the first 7 bytes by hand, but ... being only able to update sprite 0 and everything but X in sprite 1 isn't very useful.
Re: What's the fastest rate of repeated IRQ possible?
by on (#207221)
Oh, I completely forgot about that topic! Hahaha Yeah, that was certainly the most recent conversation that contributed to my "only fill the OAM using DMAs" stance.
Re: What's the fastest rate of repeated IRQ possible?
by on (#207224)
Hunh, well that's new to me. I'm going to have to do some tests laster, ha ha. :S
Re: What's the fastest rate of repeated IRQ possible?
by on (#207394)
I've tested the effect of the OAM DMA distortion with my FME-7 test ROM before. This exemplifies the worst possible distortion though where the output is delayed, since the sample is fetched from ROM inside the IRQ handler. But this could be solved as well by manually adjusting the vector after each OAM DMA to get the "missed samples" effect instead.
Re: What's the fastest rate of repeated IRQ possible?
by on (#207406)
Sounds good. Those file sizes, though. Hmm.
Re: What's the fastest rate of repeated IRQ possible?
by on (#207407)
11.6kHz audio consumes an awful lot of ROM awfully fast. Sometimes compression helps, but ...

On the other hand, it is pretty valid to say that, right now, the economies of ROMs are such that you may as well use a 512KiB ROM if you have any PRG bankswitching at all.
Re: What's the fastest rate of repeated IRQ possible?
by on (#207421)
lidnariq wrote:
right now, the economies of ROMs are such that you may as well use a 512KiB ROM if you have any PRG bankswitching at all.

Unless you're limited by CPLD macrocells.