Get the first program to automatically load the next part

[Mike]

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.

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.

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 [...]

RND() in both C64 and VIC-20 is *completely* broken.

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.

[johncl]

Well, I have used this simple one previously with success:

http://codebase64.org/doku.php?id=base: ... om_numbers

Ofc heavily simplified it works good enough for many things. Have not tested how well it covers the range though. I guess in my case I can also use a timer to affect the seed in some way as the time between user input will be highly random.

[Kweepa]

I did some random quality tests on some simple 6502 random number generators a while back.
Search the forum for random by Kweepa (I would post search results but my DNS is acting up so I don't have the right http) - the threads are "More random questions" and "Random number generation on a VIC".

[johncl]

Found these where you have posted about random stuff:

Randomness in games

More random questions

That latter one has a nice one with some analysis. Very nice.

Just wondering how bad the ROM RND routine really is, I will see how well I can use it. In most cases I only need RND for number ranges 0-15 actually so it might be good enough for that. I guess I can make a simple counter for each RND number I get out to see if it has serious bias issues for certain numbers.

[johncl]

Ok, I feel the ROM routine is pretty decent for my use, at least it covers all bytes somewhat evenly as you will see from this example:

Code: Select all

	lda #9
	sta $900f
	lda #1
	ldx #0
clearmore:
	sta $1e00,x
	sta $9600,x
	inx
	bne clearmore
again:
	jsr $e094
	ldx $63
	lda $1e00,x
	beq again
	inc $1e00,x
	jmp again

This initialize the screen with A's (char value 1) and then increments a random one up until they wrap around to zero (and stops adding then). You will notice by running the program that all numbers reach this end state not far from each other meaning the numbers are pretty well spread at least.

[Mike]

Just to show you how bad the RNG of CBM BASIC really is:

With MINIGRAFIK, you can use this simple algorithm to fill the hires screen with single pixels:

Code: Select all

1 @ON:@CLR
2 @1,RND(1)*160,RND(1)*192:GOTO2

A good RNG should produce all possible pairs of x,y-coordinates, even if it takes some time to fill the final points (much akin to radioactive decay). With the RNG in BASIC V2 however, some pixels are never filled.

The RNG is seeded with negative numbers. Now this extended version of the program below takes an especially bad seed, that enters a small cycle after ~25000 iterations:

Code: Select all

1 X=RND(-7621):CLR
2 FORT=1TO25000:X=RND(1):NEXT
3 @ON:@CLR
4 @1,RND(1)*160,RND(1)*192:GOTO4

You can use the warp-mode in VICE to speed up the warm up in line 2 a bit.

Only a few hundred pixels are plotted, and then the RNG loops.

[beamrider]

Johncl - in case you hadn't seen it, I think that [Compute's - Programming the VIC] by Raeto Collin West is possibly the best resource for Vic-20 development. You can download a copy in PDF form if you Google for it.

[orion70]

Hint: bombjack

[joshuadenmark]

Or here:
http://www.commodorecomputers.dk

[johncl]

Thanks for the tip, I found the PDF version of that book online and have been leafing through it a bit.