| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
SID noise generator testing
yay!
one thing that'd be really nice to have in the VICE testprograms repo for regression testing would be one (or more :)) programs that check for various properties of the noise generator LFSR. now i tried a few things, and always run into one annoying problem - the damn thing doesnt seem to like being "reset" in any sort of way. which makes comparing with reference data kindof hard.
so my question to the SID wizard is - can you share some ideas please? whatever wizardry may reset the damn thing into a state so that after it it can be sampled and compared to some reference reliably would do the trick. |
|
... 10 posts hidden. Click here to view all posts....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
wait until a (one) value isnt really practical.... you'd have to wait for a longish sequence - which isnt really practical either unfortunately.
what i tried so far is what sounddemon describes, set testbit for a while (several seconds) with $f0 wave selected, then set $81 and sample the result from osc3 cycle by cycle. this does "almost" work, the resulting sequence is "almost" predictable.... however not entirely, after ~50 or so bytes randomness seems to creep into it. which is sort of strange, it either means the reset didnt work, or the feedback of the LFSR is subject to analog magic too. i get also different results from different C64s, which supports the theory of analog magic going on. :( |
| |
Mixer
Registered: Apr 2008
Posts: 452 |
Has anyone recorded the noise cyclewise from many c-64 units for statistical study? (using REU as in http://www.sidmusic.org/sid/sidtech5.html) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
noise loops, I guess I've read this in a c= hackin article someone sample it into reu iirc. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
yes sure, thats besides the point however :) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
OK, working on some tests off the back of those die shots, but I can't currently transfer files to my real c64. Once I get that working again I'll report back. |
| |
lft
Registered: Jul 2007
Posts: 369 |
From the resid source (0.16):
Combined waveforms:
By combining waveforms, the bits of each waveform are effectively short
circuited. A zero bit in one waveform will result in a zero output bit
(thus the infamous claim that the waveforms are AND'ed).
However, a zero bit in one waveform will also affect the neighboring bits
in the output. The reason for this has not been determined.
Example:
1 1
Bit # 1 0 9 8 7 6 5 4 3 2 1 0
-----------------------
Sawtooth 0 0 0 1 1 1 1 1 1 0 0 0
Triangle 0 0 1 1 1 1 1 1 0 0 0 0
AND 0 0 0 1 1 1 1 1 0 0 0 0
Output 0 0 0 0 1 1 1 0 0 0 0 0
(...)
Tests show that minor (1 bit) differences can actually occur in the output from otherwise
identical samples from OSC3 when waveforms are combined. To further
complicate the situation the output changes slightly with time (more
neighboring bits are successively set) when the 12-bit waveform
registers are kept unchanged.
And:
All waveform combinations including noise output zero after a few cycles.
NB! The effects of such combinations are not fully explored. It is claimed
that the shift register may be filled with zeroes and locked up, which
seems to be true.
So here's my hypothesis: The bleeding between neighbouring bits happens not only for combined waveforms, but for regular noise too. Theoretically, the bit that is shifted into the LFSR is bit 22 EOR bit 17. However, bit 22 is an output bit (it's bit 7 of OSC3). Sometimes a zero will bleed over from OSC3 bit 6 (LFSR bit 20) and upset this computation.
Here's how to falsify it: Record some actual noise sequences (e.g. read OSC3 by REU), and find the places where the output diverges from the theoretical LFSR. In all of these places, if the hypothesis is correct, bit 22 should be 1 and bit 20 should be 0 just before it happens. Otherwise it's back to the drawing board. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
its easier infact - using $f wave when resetting causes 0s to sneak in, using $0 wave instead works reliably :)
see here for progress: https://sourceforge.net/p/vice-emu/bugs/746
(and why would you look at resid 0.16 when there is 1.0 in the trunk already? =P) |
| |
lft
Registered: Jul 2007
Posts: 369 |
Quoting Groepazits easier infact - using $f wave when resetting causes 0s to sneak in, using $0 wave instead works reliably :)
see here for progress: https://sourceforge.net/p/vice-emu/bugs/746
It's nice that you found a way to consistently reset the lfsr. Still, there's a need for an explanation for how those zeros "sneak in". The link you provided has some interesting information, so thanks for that!
Quoting Groepaz
(and why would you look at resid 0.16 when there is 1.0 in the trunk already? =P)
That's easy: I happen to have 0.16 on disk, so that's the version that my subconsciousness is familiar with. When I got the idea for the hypothesis, it was therefore based on information present in version 0.16. It's not like I deliberately went and downloaded the latest version in order to read it and see if I came up with something; the idea came uninvited, and I documented it. |
| |
Mixer
Registered: Apr 2008
Posts: 452 |
One could take a state of the bit 0 of some number read in osc3, that bit state should eventually appear in higher bits when the noise lfsr is clocked. When it appears in the next bit is the sequence in which output bits are in lfsr. Testable. Would prove that the shifting works.
The observation that testbit clear clocks the lfsr once is interesting, one could use low or 0 frequency and clock the lfsr when needed. Testbit will reset the oscillator, but not the noise lfsr. Testable.
Third idea is a question: are the "analog effects" more likely to take place when frq is low, and lfsr state stays the same a long time or when frq is high? Testable. |
| Previous - 1 | 2 - Next |
