tepples wrote:
I'd consider clocking it at 113.667 CPU cycles per sample so that it can be used from cycle-timed code.
Yeah, good idea. That way the NES could do scanline effects and sound output in the same IRQ routine. Would be faster than having 2 seperate IRQ routines timed differently, for sure. It might not have enough time to do much mixing in 113.667 NES cycles, though. One channel, maybe two, I'm guessing. My goal currently is to get 4 channels at 22050Hz.
It'll be tricky to set up with that 2/3 CPU cycle, but I've got 3 different clocks. The 10Mhz PIC clock is timing the mixer, then there's the 1.789Mhz NES clock (not much advantage over the PIC clock in this case), and the scanline counter (which stops counting during vblank, can't let that happen in a mixer).
Polling the register could work instead of IRQs also, but keep in mind that reading the register too often will steal time from the PIC (since it get's interrupted).
Quote:
And it shouldn't be too hard to support wavetables at any power-of-2 length: just have an AND and an OR between the frequency counter and the address generator.
This newer PIC has an indirect indexed mode, also greater/less than comparison opcodes. So I think an optimal thing to do might be to have a max 256 byte sample and make registers to allow a program to set the start and end points of the waveform. Keeping it pointed towards the same 256 byte table especially would save time.
Quote:
Does this mixer have volume control? Does the PIC even have a multiplier?
Yeah, the PIC18F-series has an 8x8 hardware multiplier. Single cycle operation, it's great. The PIC16F that I was planning on using originally doesn't. The 18F is really powerful, faster, and much more fun/easier to code for. I'd like to use it exclusively, if anyone planning on buying a Squeedo cart wouldn't mind paying the extra $4-$5.
Volume is what I plan on adding next, that multiplier should make it practical to do. Yesterday I added 24-bit frequency control (though the highest bits are kinda useless, you usually don't want to skip 127 bytes in a 256 byte sample, heheh.
In other news, I'm getting an EPROM programmer, and should have it in a couple weeks. So I can finally figure out if my flash programming design works or not, heh.