nesdev.com

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).

_________________
nesdoug.com -- blog/tutorial on programming for the NES

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.

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.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

See also viewtopic.php?t=14520

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.

I've abandoned this idea. I don't think I could get a fast enough IRQ frequency to do in-game pcm sound.

_________________
nesdoug.com -- blog/tutorial on programming for the NES

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.

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.

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?)

Yup.

This is one of the reason I think a "right" solution is to have a synthesizer directly generate DPCM instead of PCM.

And you have to work around the weird OAM corruption that results from using $2003/$2004.

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?

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.

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.