I can clearly hear different tone heights on the noise channel, and there's a formula in fceux that calculates its midikey for a given frame, and the resulting midikey seemingly reflects the tone height difference. But unlike the other channels, I can't figure out where this overall height is coming from. The noise channel is supposed to pseudo-randomly jump between a bunch of possible frequences, isn't it?

I also see noise channel is given values in things like famitracker.

So the question: are these values even notes, or just presences of those frequencies that are internal to the chip?

When used with the normal "white noise" mode, the effective sound is mostly a function of the sample-and-hold effect, on average it works out to your choice of corner frequency of a 1st-order lowpass (6dB/octave).

The noise pattern loops. If it loops slowly ("periodic" mode off) you get a repetitive whoosh noise, if it loops fast enough (periodic mode on) you get a tone.

The frequency of the tone produced just depends on the length of the loop; with the periodic mode on it's 93 samples long at whatever the current noise frequency is. You can think of it like a wavetable tone, like with N163 or FDS expansion audio. The actual waveform in periodic mode depends on whatever bits were in the LFSR when that mode was turned on. Sort of a randomly selected timbre.

In non-periodic mode it's a much longer loop, so it's no longer a tone but just a repeating sound. You can hear the looping easily at the higher frequency settings.

When the noise channel Mode flag is clear, the noise channel repeats a sound wave that is 32767 steps long. Each step is pseudo-randomly the minimum or maximum level. Although the sound wave eventually repeats, it's so long in duration that you don't hear it as a definite pitch.

When you change the Rate bits, the long-mode noise does sound higher pitched or lower pitched compared to the noise at other rates. But if you try to compare the pitch of the long-mode noise at a specific rate to the pitch of, for example, a square channel tone at a specific pitch, you can't really tell which one is higher or lower in pitch, they're not really comparable.

Short mode noise

When the noise channel Mode flag is set, the noise channel repeats a sound wave that is 93 or 31 steps long. This is short enough to have a perceptible pitch.

For short mode noise, I calculate the pitch as the frequency of the repeating wave. See the attached test.zip under this paragraph. I'm interested in discussing with other people if my calculations are correct. (When I proposed changes to how FCEUX calculates the pitch of short mode noise, no one replied to my proposal. Now I'm excited someone else is wondering what FCEUX's pitch values mean for the noise channel.)

on the noise channel [...] there's a formula in fceux that calculates its midikey for a given frame [...] I also see noise channel is given values in things like famitracker. [...] are these values even notes, or just presences of those frequencies that are internal to the chip?

FCEUX

FCEUX assigns lua sound.get().rp2a03.noise.frequency and .midikey values based on the rate.

Note: I think the (39375000.0/44.0) value represents the NTSC APU clock frequency, but the NoiseFreqTable values are in terms of NTSC CPU clocks.

Famitracker

Famitracker assigns "hex pitch" values in the noise channel: 0-# to 9-# then A-# to F-#. These values are based on the Rate bits. Edit: Like tepples says below, Famitracker displays values that are 15 - the PPPP bits, so that the lowest pitch (longest period, PPPP = 1111) is shown as 0 and the highest pitch (shortest period, PPPP = 0000) is shown as F.

Last edited by Bavi_H on Sat Jun 04, 2016 7:06 pm, edited 2 times in total.

Note: I think the (39375000.0/44.0) value represents the NTSC APU clock frequency, but the NoiseFreqTable values are in terms of NTSC CPU clocks.

Yes the noise samplerate is the CPU clock (~1789772 Hz) divided by the period in the table. (The same table is on the wiki, and it's been independently verified on many occasions).

The periodic mode ones should again be divided by 93 to give a musical pitch.

The non-periodic mode ones shouldn't be divided by 32767, though, because this doesn't produce musical pitches; they are too low frequency to be perceived that way. However, the base samplerate of the non-periodic noise does generate harmonics at its samplerate which produce a faint but noticeable musical pitch, at least for the lower frequency settings. The higher frequency settings are too high to be perceived as musical pitch.

As such, if you're looking for perceived pitch frequency, use CPU / (table * 93) for the periodic mode, and just CPU / table for the non-periodic mode.

Now another interesting thing to know would be if it's possible to reliably get the same timbre every time by immediately setting the mode flag when the NES is powered on, hopefully before the LFSR receives its first clock. Losing the static would not be an issue if there's an expansion chip present like the 5B, which has its own noise or alternatively it's also possible to create noise-like sounds by playing back random data or code as DPCM samples.

Now another interesting thing to know would be if it's possible to reliably get the same timbre every time by immediately setting the mode flag when the NES is powered on, hopefully before the LFSR receives its first clock. Losing the static would not be an issue if there's an expansion chip present like the 5B, which has its own noise or alternatively it's also possible to create noise-like sounds by playing back random data or code as DPCM samples.

It must be seeded with at least one 1 bit in it, so it has to initialize at least one bit at power-on (or reset). Perhaps Visual 2A03 could help understand this.

Because of this, I expect it is at a consistent state on reset, and you can probably do what you're proposing.

CopyNES installation would interfere with this, since it runs BIOS code on reset. There might be other situations that would compromise a user's system for this purpose too.

The NSF format can't use such a trick either, because the player is supposed to set up the system prior to any code run from the NSF, so there's no guaranteed time-since-reset there. I did implement an option for randomized vs consistent noise initialization, though, in my NSF player, but that's really just so that you can get consistent results if you need tehm.

It must be seeded with at least one 1 bit in it, so it has to initialize at least one bit at power-on (or reset). Perhaps Visual 2A03 could help understand this.

Visual2A03 tells me that it is seeded with all ones ... which would be the easiest thing to do.

Interestingly, the noise LFSR appears to contain a self-recovery flag (node 11464) that, if every single bit inside the LFSR is 0 (and thus it would stop making noise), it'll instead clock in a 1 instead of a 0. i.e., the feedback term being fed into noi_c0 is not noi_+c14 XOR SELECT(noi_lfsrmode,noi_+c13,noi_+c8) but instead n11464 = NOR15(noi_+c[0..14]) = 'safety'n11454 = SELECT(noi_lfsrmode,noi_+c13,noi_+c8) = 'FB2'n14042 = NOR3(noi_+c14,n11464,n11454)n14046 = NOR3(snd_halt, n14042, AND2(noi_+c14,n11454) = bit to be clocked into noi_c0

It's not explicitly initialized. I vaguely fear that the power-on value is an artifact of the simulator, so I guess we should make a tiny test ROM to play with this on hardware. (goes and does that, will post with results later)

rainwarrior wrote:

Interesting that it would have this in addition to an initialization. Why initialize at all? Hmm.

Yeah, that is awfully suspect.

rainwarrior wrote:

Does setting [snd_halt in $401A] cause the noise to progressively fill with all 1s as it's clocked?

Who is online

Users browsing this forum: No registered users and 4 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum