In any case, thank you very much for your considerations and contribution to this discussion. I think we all have the opportunity to learn a lot in this matter .

It's one of those things that's fun to think about too. Incidentally for entropy I also tend to use time spent in the menu screen for the seed. I have used the quick-and-dirty R register to measure that time in the past but then realized you can't get more than 128 different seeds that way and in reality probably much less depending on the length of the code path. That means possibly much less than 128 different games. A counter is better.

Not to derail the discussion but I've also snuck in use of R to generate "random" events inside a quicksort implementation (shocker!!):

` ; enable equality dispersal`

jp m, right_squeeze_0 ; if item[lo=pivot] < item[i]

or a

jr nz, left_squeeze_0 ; if item[lo=pivot] > item[i]

; item and pivot are equal

ld a,r ; instruction count

and 31 ; use prime number

jp pe, left_squeeze_0 ; if parity is even (random event)

The problem being solved here is if quicksort gets an array of equal elements it can degrade to a bubble sort so this is supposed to disperse equal elements randomly to the left and right partitions. I've taken R, ANDed with a small mask (it's modulo 32 cycles of execution time now) and used parity to decide if the element should go left or right. The value of R will not be very random because it will depend on a finite number of code paths spiced up a bit by the user comparison function and the data that determines when swaps are necessary. I still haven't tested this yet but will be doing so when I do some sorting benchmarks.