Do you know how random number work? You use either Applesoft BASIC
or Integer BASIC. You use the function like RND(). Take a look at my
example here.
10 PRINT INT( RND( 10 ) * 10)
20 GET A$
30 GOTO 10
Apple II has chosen the random number of the range from 0 to 9 and
print each random number to the screen. How do Apple II know to guess
random number? Take a look at monitor routine $FD1B. $4E and $4F are
the high byte of random and low byte of random. It waits for the key to
be pressed while random number continues to increment. If key is
pressed, random number stops to increment before it is printed to the
screen. Repeat the procedure to increment random number while it waits
for a key.
Do you know the alternative implementation rather than keyin? Do you
think to implement the clock to replace keyin? The random number stops
to increment each one second while clock reads one second and another.
What do you think?
If the KEYIN 16-bit counter is used, the result is actually random
(particularly in the low byte), since the counter is counting at over
50kHz and human response times (even when trying to be consistent) have
variances of several milliseconds, the sampled value of the low byte
is essentially random. The effect is like a roulette wheel with 256
"slots" that is spinning at 12,000 RPM being stopped by a keypress!
The high byte "turns over" in slightly more than a second, so if
a person is asked to read a prompt and respond, a situation in which
variances are likely to be on the order of a second, then even the
high byte of the counter is fairly random.
The Applesoft RND function, however, is a *pseudorandom* number
generator (and a defective one, at that), whose outputs will always
be an identical sequence of numbers. The length of the sequence,
because of a design error, is rather short (a few tens of thousands of
numbers before approximate repeats occur). The starting point in this
sequence is set by the "seed", which is set by a call with a negative
argument. (Interestingly, another bug causes the low byte of the
cold-start seed to be ininitialized.)
Unlike Integer BASIC's RND, which returns a positive integer determined
by RND's argument, Applesoft ignores the value of any non-negative
argument, and always returns a floating point number greater than or
equal to zero and less than one.
There is a long history of pseudorandom and actual random number
generators, with some very interesting results. If you're interested
in them, a Google search will turn up lots of fascinating reading.
If you are debugging a program, there are real advantages to having
a deterministic source of pseudorandom numbers. If you wish to avoid
repeating the same sequence in game play, then the pseudorandom
generator can be seeded with a "real" random number from the KEYIN
counter as long as there is at least one (nondeterministic) human
interaction prior to each sampling.
There are also several better replacements for Applesoft's RND
function for demanding applications--though that may be an oxymoron.