Noise pitch is different in emulator vs hardware?

[DragWx]

The emulator appears to play PSG noise at double the rate that the hardware VERA does.

PSGWAV0,$FF
PSGFREQ0,440
PSGVOL0,$3F
PSGPAN0,3

I don't think it's my speakers playing tricks on me, is it?

[DragWx]

Figured it out and opened a ticket here.
It was subtle enough that it almost took me an hour to figure it out.

[DragWx]

After the related pull request, the PSG noise in the emulator now matches the hardware.

[kliepatsch]

I recently got a board and noticed the same thing. Thanks for fixing the emulator, much appreciated!

Also, I noticed that the noise on the HW board seems to suffer from what I would describe as a "comb filter effect" (most people probably won't know what I mean) ... basically when the noise pitch is almost maximal (almost white noise), the noise seems to have a pitch/tone. And no, that one is not correlated to the pitch you configure in the PSG registers.
But I am not certain it's not caused by something I do in Concerto (like using a VIA timer ... maybe?)

[DragWx]

Oh yeah, it's not present in the emulator, but it's present on hardware. If you play noise at frequency $CC00, it's very obvious, like a resonant noise. It sounds like aliasing or something.

[DragWx]

I'm making a guess here, but I noticed that the VERA clocks the LFSR differently from the emulator.
The VERA clocks the LFSR every clock cycle, of which there are 512 per output sample. In other words, every time we go back to update channel 0, the LFSR will have advanced by 512 steps.

The emulator is much more naive, and only clocks the LFSR when it updates a channel, so every time it goes to update channel 0, the LFSR will have only advanced by 16 steps.

Since the VERA is clocking the LFSR so much per sample, it's possible that we're hearing a very rapidly repeating sequence and it only appears when we're aligned to the LFSR's period a specific way. It's worst when the channel frequency is a multiple of $400, but there's another noticeable (but lower pitched) interference sound at multiples of $400, offset by $200 (so, $FA00, $FE00, etc). There's a third barely-noticeable interference sound (even lower pitched) at offsets $100 and $300.

If this is indeed what the cause is, then I'd like if the VERA itself could be corrected to clock the LFSR similar to how the emulator does it (i.e., only during the clock cycles where a channel is being updated, not during the idle cycles in between). This isn't a show-stopping issue though.

[kliepatsch]

Do you know how many bits the LFSR is? And is the VERA running at 8 Mhz or does it have its own clock?
Your idea sounds plausible to me. Maybe it can be verified with some clever experiments.

[DragWx]

The LFSR is 16 bits, shifts left, and uses (before-shift) bits 1, 2, 4, and 15 as XOR taps.

The VERA itself is clocked at 25 MHz, and generates one sample of audio every 512 clock cycles. When it's time to generate a new sample, the 16 channels are updated in 2 clocks each, with the second clock being the one where the channel's new amplitude is calculated. After channel 16 is finished (32 clocks later), the PSG goes idle until it's time for the next sample, so 480 cycles.

The LFSR is clocked with every cycle, even though there's only 16 of the 512 cycles where its value is actually needed.

If you're familiar with Verilog, you (and anyone else) can verify all of this here.

[kliepatsch]

Thank you! I am not yet familiar with Verilog, so I'll have to take your word for it at the moment.

I do not know how the sequence of 65535 values in the LFSR are turned into audio samples, but let's assume they do. That means we have a sequence of 65535 unique (semi-random) samples which we are burning through at a rate of 25 MHz.

25 MHz / 65535 = 381.4 Hz

That means the list of random samples gets repeated 381 times per second!
Incidentally, the spectral peaks we get are located at multiples of 381 Hz. So there seems to be a correlation between the spectrum of the noise and the rate at which the LFSR repeats its "waveform".

Nonetheless, I am surprised about this result because only every 512th sample (at most!) of the 65535 samples should end up on a PSG noise channel. And because 65535 isn't a multiple of 512, it shouldn't actually loop that quickly.
One possible explanation: There is still some correlation between subsequent iterations, which elevates the "harmonics" above the noise floor. In other words, 65535 is almost a multiple of 512, and that's what we can hear.

More specifically, if you take each of the 65535 iterations in the LFSR as a sample, these samples aren't entirely independent. Each sample shares most of its bits with the previous iteration (but shifted, of course).
This isn't an issue within a single iteration of the 65535 samples. The LFSR advanced 512 times before you draw another sample for a noise channel. Those two samples are practically completely decorrelated.

BUT: once you wrap around the 65535 samples, you pass nearly the same samples as in the previous iteration. 65535 mod 512 is -1. This means that after 1/381.4 seconds, the random samples you draw are the same as in the previous LFSR period, except one iteration later! Both samples should bear at least some similarity, which leads to audible correlations.

[DragWx]

Yes, I've just confirmed via modifying the emulator, the fact that the LFSR is clocked 512 times is the exact reason for the ringing sound.

In vera_psg.c:

Code: Select all

	for (int i = 0; i < 16; i++) {
		// In FPGA implementation, noise values are generated every system clock and
		// the channel update is run sequentially. So, even if both two channels are
		// fetching a noise value in the same sample, they should have different values
		noise_state = (noise_state << 1) | (((noise_state >> 1) ^ (noise_state >> 2) ^ (noise_state >> 4) ^ (noise_state >> 15)) & 1);

		// (SNIP)
	}
	for (int i = 0; i < 512-16; i++) {
		// The LFSR gets clocked a total of 512 times for each sample, so perform
		// the remainder here.
		noise_state = (noise_state << 1) | (((noise_state >> 1) ^ (noise_state >> 2) ^ (noise_state >> 4) ^ (noise_state >> 15)) & 1);
	}

After adding that second loop for clocking the LFSR the rest of the way, the noise waveform gains the ringing sound we're hearing on the hardware.

If we want to fix this, I think we should consider modifying the VERA itself so it only clocks the LFSR during the cycles where it's updating a PSG channel, rather than clocking it for 512 cycles. This would be akin to a "cosmetic" change that just makes the noise sound nicer.

I'll go ahead and open an issue in the VERA github repo about this.

Edit: Opened. The change doesn't look unreasonable to me, but I don't know how much this affects the VERA's gates, so we'll see what the team says.