Laserbeak43 wrote:wow, i didn't even know most of that stuff. Different sample rates!! interesting. I should look into making a shift register for random values in hardware. Never heard of that one.

Thanks for all of that information. What doc gave you all of that? (Brad Taylor's? I'd assume it's that one, cause it's the one i find most confusing.)

This is guaranteed to be a rambling post, so be warned...

I said random, but it's not *truly* random because it creates a sequence that will eventually repeat. That repetition is what gives the NES and Atari "pitched" noise sounds. As the shift register gets longer so does the sequence, until a long enough sequence sounds like pure white noise.

The thing is, current synthesis is all resource-intensive DSP. When arcades needed soundchips, they didn't have all the memory and processing power available that we do now. These days it is about optimizing software methods for sound generation. Back then, it was about getting the most mileage out of simple logic circuits and transistors. Even though the circuits are "digital" in the sense of being logic-based, there are things going on that can't be copied directly in the modern software world.

I noticed from another post that you seem to be trying to emulate 2A03 sounds in software. One of the main issues you will run into, if you haven't already, is that you will have all kinds of aliasing problems if you generate these waveforms the naive way.

Say you want to make a square wave. The naive way would be to make something that switches between high and low values instantly, making a pattern like this with the samples (values are arbitrary):

-500

1000

-500

1000

...

or an octave lower:

-500

-500

1000

1000

-500

-500

1000

1000

There are two big problems with this right away. First, the frequency will only be accurate when it is an integer division of the sample rate. If that's not the case then jitter will occur.

Suppose that's good enough, though, and non-integer-division frequencies are lame anyway. That naive square wave is easy to code and will look perfect on the screen, but it will not sound good compared to an actual 2A03 square wave. The problem is that instantaneous switching requires an *infinite* frequency response. If you look up the frequency spectrum of a square wave, you'll see a fundamental frequency plus harmonics that extend far off into the distance. That is what you get in the hardware world, though the very high frequency harmonics will roll off because circuits can only change so quickly...

Back in the software domain, though, we don't have infinite frequency response. We know that whatever our sample rate is, no frequencies greater than half that will be recreated properly. In fact, any frequencies higher will fold back down as new erroneous frequencies! By creating a square wave with the "naive" method, that is exactly what happens. All the harmonics of the square wave that occur naturally will become errors if they are greater than half the sample rate. What's even worse, since we are in the pristine digital domain, we get as many harmonics as mathematically possible! Even though higher and higher harmonics are eventually rolled off enough to be below the noise floor, there will be a whole lot of garbage piling up until then.

We really want a square wave that is 100% accurate as far as the frequency response of the digital system can get us. So how can we make a square wave with only frequencies less than half the sample rate?

This is where band-limited impulse trains (BLIT) work wonders. They use very simple signals (mainly a sinc function) and some relatively simple calculus concepts to create square waves (among other waves) that don't alias. If you're looking to emulate hardware, this is really the place to start.

Hopefully I'm somewhat correct in guessing what you are trying to do. If not, the rambling was still fun.