I agree with others that a psuedo random generator seeded from RTCC would be adequate for your game application.
I was pursuing the comparator idea as a curiousity. Pursuing it a little further, I don't understand the need for the transistor. I was trying to minimize the amount of external parts required down to basically two resistors. Why not just turn the comparator on and off via the comparator mode bits, CMP_B? You could even use it then for other i/o.
Hi Tracy, I have each of the port b registers hooked up to a diode, and each of the port a registers hooked up to a switch.
There are 2 blue diodes on top, 2 red on the right, 2 green on the bottom, and 2 yellow on the left.
I plan to have the game produce little light shows to celebrate the players progress every time the length of the memorized sequence increases by 4 colors.
Since it is an SX20 there are no more I/O pins available.
If I bridge the rb.0 and rb.1 pins then I will not be able to light the 2 blue diodes independently, so the transistor is there to let me open or close the bridge.
PJ, I like the idea of running the Psuedo-random generator in the RTCC.
If I understand you correctly the output of the generator is input into the RTCC and incremented some number of times before being pulled out to use as a new seed. This seems like it would take care of the problem that a psuedo-random generator always produces the same series of numbers from a given initial value.
James, I always assumed that the RTCC starts at zero and increments along with the program counter.
Is this wrong?
If I ran the following program:
RESET Start
Start
nop
nop
nop
Wouldn't the RTCC hold a value of 3?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I wonder if this wire is hot...
Actually, what I do is run the random number generator in the RTCC interrupt itself. I store the result (an 8 bit number) in a variable. Since the RTCC is running at a (presumably) fast rate, the pseudo-random sequence is being run through hundreds or thousands of times a second. Given that there is no way to predict when the human will push the button to start the game, and also given that no human is going to be accurate enough to push the button the exact same time after starting the device, there is essentially zero chance for the same random number to appear.
Furthermore, your code could test the condition of the button at start up and not accept the button as being pushed until it has at least seen it not pushed once in the primary loop. This would prevent the user from holding the new game button down at startup.
In addition, the whole time your game is being played, the RTCC is still running and the pseudo-random number generator is still cranking out new values on each interrupt. Because of this, even if the user were able to somehow get the unit to give the same game each time they started it up, they would never be able to get the same second game unless they took the exact same amount of time to play the game and hit the "New Game" button.
Basically, imagine a roulette wheel behind a curtain. It's turning at high speed and someone is watching it. Periodically, someone in front of the curtain asks what number the wheel is at, and the person in back notes the number and passes it to the front. This is what is happening by simpy having the pseudo random number generator running on each interrupt all the time. Periodically, the user will push the "New Game" button and the foreground code will look at the variable with the current random number, but there is zero correlation between the current state of the generator and the time the user pushes the button, hence the human variable guarantees a truly random number generator since they themselves are the true random element.
Comments
I was pursuing the comparator idea as a curiousity. Pursuing it a little further, I don't understand the need for the transistor. I was trying to minimize the amount of external parts required down to basically two resistors. Why not just turn the comparator on and off via the comparator mode bits, CMP_B? You could even use it then for other i/o.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
There are 2 blue diodes on top, 2 red on the right, 2 green on the bottom, and 2 yellow on the left.
I plan to have the game produce little light shows to celebrate the players progress every time the length of the memorized sequence increases by 4 colors.
Since it is an SX20 there are no more I/O pins available.
If I bridge the rb.0 and rb.1 pins then I will not be able to light the 2 blue diodes independently, so the transistor is there to let me open or close the bridge.
PJ, I like the idea of running the Psuedo-random generator in the RTCC.
If I understand you correctly the output of the generator is input into the RTCC and incremented some number of times before being pulled out to use as a new seed. This seems like it would take care of the problem that a psuedo-random generator always produces the same series of numbers from a given initial value.
James, I always assumed that the RTCC starts at zero and increments along with the program counter.
Is this wrong?
If I ran the following program:
RESET Start
Start
nop
nop
nop
Wouldn't the RTCC hold a value of 3?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I wonder if this wire is hot...
Actually, what I do is run the random number generator in the RTCC interrupt itself. I store the result (an 8 bit number) in a variable. Since the RTCC is running at a (presumably) fast rate, the pseudo-random sequence is being run through hundreds or thousands of times a second. Given that there is no way to predict when the human will push the button to start the game, and also given that no human is going to be accurate enough to push the button the exact same time after starting the device, there is essentially zero chance for the same random number to appear.
Furthermore, your code could test the condition of the button at start up and not accept the button as being pushed until it has at least seen it not pushed once in the primary loop. This would prevent the user from holding the new game button down at startup.
In addition, the whole time your game is being played, the RTCC is still running and the pseudo-random number generator is still cranking out new values on each interrupt. Because of this, even if the user were able to somehow get the unit to give the same game each time they started it up, they would never be able to get the same second game unless they took the exact same amount of time to play the game and hit the "New Game" button.
Basically, imagine a roulette wheel behind a curtain. It's turning at high speed and someone is watching it. Periodically, someone in front of the curtain asks what number the wheel is at, and the person in back notes the number and passes it to the front. This is what is happening by simpy having the pseudo random number generator running on each interrupt all the time. Periodically, the user will push the "New Game" button and the foreground code will look at the variable with the current random number, but there is zero correlation between the current state of the generator and the time the user pushes the button, hence the human variable guarantees a truly random number generator since they themselves are the true random element.
Thanks, PeterM