Dan,

It seems that Maarten has hit on the reason your random number generator was always giving even numbers, and it seems that by removing the unnecessary initialization of R2, R3, and R4 in your 'bin_to_bcd' routine, you have found a way to make it work.

Although we now understand what was wrong and have a fix, it's not a very good fix because the same even-only problem will appear and disappear in the future whenever you make changes to the program that affect the timing of the main loop. This is not a good thing.

I was thinking that you should arrange the hardware to produce an interrupt whenever somebody pushes the switch. The handler for that interrupt would capture the timer value and write it to a location in RAM that the main loop will then subsequently read and display.

That would be better than the current implementation, for the reason explained above, but I still don't think the resulting numbers would be truly random. Depending on the mix of instructions in the main loop, I think there would still be a tendency to see more even numbers than odd numbers (or the other way around) at the time of the interrupt. Maarten's suggestion of throwing away the LSB of the result would fix that problem. Then we're left wondering if the remaining upper bits are truly random.

My thinking is really fuzzy on this point, but I'd have to guess that the answer is "nope, even though the upper bits may look random to a casual observer, their distrubution still depends on the mix of instructions in the main loop." It seems that to make this thing really work right, the timer has to be running asynchronously with respect to the CPU clock, as well as somewhat faster.

Can somebody come up with a different slant on this that makes it easier to understand and talk about? I'm starting to confuse myself.

-- Russ