CPLD square wave synthesizer

[Dwedit]

But RAMBO-1 just has an 8-bit counter.

[tepples]

So does POKEY but they made music with it anyway.

[adelikat]

Fails on FCEUX, Nestopia, Bizhawk, and possibly everything else.

Actually, it works fine on BizHawk.

[Dwedit]

Sorry, my copy must have been too old. It was from Sep 23. Works fine in the new version that was uploaded 12 hours ago.
Congratulations on the new release! I can see all the bug fixes. I just wish it wasn't so slow.

[infiniteneslives]

It's just a gut feeling, but I think you'll be lucky to fit 2 channels as you've defined into 72Mcells (assuming we're talking XC9572XL)

Even if it didn't fit, you might be able to make one channel inferior to the other by removing duty cycle or some other limitations. Perhaps only allow frequencies below a certain value since this would be best for bass use. Although really it would seem the logic needed for something like this would be pretty simple. Since my knowledge of sound is lacking I think I have the illusion it's more complex that it really is... Sound like it's really nothing more than counter and comparator with some logic for the irqs and such so two channels may very well fit in the 72Mcell goal.

Would it really be that much of a trouble to limit/prevent the time collision with OAM/sprite transfer? Some ideas: perform the transfer in smaller loops so the irq can be 'caught' half or 1/4 of the way through the transfer. Another way would build more time into the irq servicing routine, but you could use a flag to determine if it was the first irq during vblank and transfer sprites after servicing the irq.

But RAMBO-1 just has an 8-bit counter.

Keep in mind it's clocked by M2 divided by 4.

[Dwedit]

Interesting, when dividing by 4, you can use integer multiples of the smaller period.
Middle C is a period of about 3420 cycles. First division by 4 gets you 855, which can be 5 IRQs at a period of 171 (*4), or approximately 4 IRQs are a period of 214 (*4). But that's more interrupts to handle, eating away CPU time. But then you can simulate different waves than a 50% duty cycle square.

A NES OAM DMA is not interruptable at all, and can't be broken into smaller chunks. It will always transfer 256 bytes. The only way to make it interruptable is to not do DMA, and that takes 2048 CPU cycles to do a completely unrolled sprite transfer, which is ridiculous.

[Memblers]

It's an interesting idea for sure, I've wondered what else could into a 72 macrocell CPLD, because a simple mapper doesn't take much. My current CPLD board only gives D0-D3 to the NES. That would require the NES to do a 3 ASL instructions per sample at most, a significant penalty but I wouldn't say it ruins it.

BTW, speaking of the POKEY, in a CPLD I imagine one could fit an LFSR and create some relatively complex waveforms with only the shift register size + seed values.
I'm still working on my Squeedo synth too, but it's an entirely different class (General MIDI compatible ). Of course an $8 or $9 MCU can do more than an a $1 or $2 CPLD, but it's quite a cost difference, and the CPLD is already there for memory mapping.

As for the timing glitches, when I made my really old first version of my synth on a PIC18 MCU, I thought I would try turning on the sprite DMA to see what it did.. then realized my sprite DMA had always been enabled. I didn't seem to be a noticeable to me. I would suppose that the twinkle demo isn't a good indication of what you would get with a CPLD, because like the MCU, your synth will probably keep generating samples at a steady rate regardless of what the NES is doing.. a few samples being missed seems to be less of a problem, compared to having timing errors.

[Dwedit]

So how does this compare to the DMC SAW/Square wave technique? That requires no additional hardware, but you only get one extra tone channel.
Meanwhile, good ol' fashioned DMC Bass is looking really appealing...