That's not quite what I was up to. The table in the PRM features values, which are off by more than one half a unit and it has very uneven intervals. And modulation (which does not relate to the quick toggling of the gate bit, BTW) can only cover up those de-tuned sounds, but does not result in pure tones.johncl wrote:Thanks, the Reference Manual actually mentions modulation is needed to get pure tones - no doubt, many just ditched that and went with a simple lookup table yes.
RND() in both C64 and VIC-20 is *completely* broken.An example of this was a random number generator, where I have previously used a simple code snippet from codebase65 which ofc works for the Vic20. But the RND function at $e094 might work as well even though its slower as it generates a full set of random bytes ($61-$66). But when I then tested the randomness of those numbers by plotting them onto the screen, I noticed several weren't very random at all [...]
In principle, it is a linear congruential generator with a 32-bit seed. However it seems like one of the programmers tried to 'improve' on it, exchanging the upper and lower half of the mantissa after the multiply-add. Everyone at least slightly involved with random number generation knows, that the lower bits of a linear congruential generator are nowhere near random.
As a result, there is no big cycle of 2^32-1 or 2^32 numbers, but only several thousand cycles with ~58000 or even just ~750 different numbers! Depending on the seed, some numbers are reached only once, and then never again, the sequence entering one of the aforementioned cycles.
For a game I have as WIP, I derived a 65xx version of the RNG in the ZX81. It uses the sequence 'X = 75 * X MOD 65537', starting with X=1 (or any non-0 seed of 1..65536). It isn't that good either, but at least it works, and produces all numbers 1..65536 in a pseudo-random sequence.