I've studied this article which details a well known limitation with AppleSoft BASIC when it comes to generating a pseudo-random number sequence:
I've done some experiments, and there is one thing I still cannot figure out.
Try to do this: set the AppleWin emulator to Apple II+ mode, paste this program, RUN it and then save the emulator state (f11):
10 home:get k$:x=rnd(-1*(peek(78)+256*peek(79))):print x
What this code does is wait for a keypress and then seed the random number generator with a value taken from the memory locations used by the keyboard scanning routine. Since the exact moment when a key is pressed can be considered pseudo random, this results in a different seed (x) being generated every time.
To test this, after saving the emulator state press a key, take note of the value of x, then load the emulator state you saved previously, and press a key again. The value of x will be different.
OK and as expected so far. Now try this code (and again, RUN the program and save the emulator state):
10 home:wait 49152,128:x=rnd(-1*(peek(78)+256*peek(79))):print x
This code is very similar, but instead of the GET statement we are using a WAIT statement that has the effect of waiting for a keypress while hiding the cursor. We can follow this with a GET to grab the keypress, but that does not change the issue I am about to explain.
Again, press a key and take note of the value of x, then load the emulator state you saved and press a key again. The value of x will be the same!
And the issue is not the RND statement, because PEEKing the values of 78 and 79 before generating the seed reveals the two values don't change. Try this:
10 home:wait 49152,128:print peek(78),peek(79):x=rnd(-1*(peek(78)+256*peek(79))):print x
Note that if you save the emulator state when the program is NOT running, so that to run it you will have to load the emulator state and then type RUN, this issue does NOT happen. It only happens when loading a RUNNING emulator state. In theory, loading an emulator state should be equivalent of "resuming reality" and not the equivalent of cold booting the machine straight to the program; and besides, even if that was the case, seeding the random number generator AFTER a keypress should guarantee that a new series of pseudo random numbers is generated every time.
OK, enough with the blah blah. Why does this happen? Why does the WAIT statement above cause the 78 and 79 memory locations to NOT get a pseudo random value from the keyboard scanning routine? Is this a problem with the emulator or can this be traced back to the actual machine?