It's not cheating. It's just a different category. I mention both the period as well as the PractRand results. The minimum period is important if you want to be sure to avoid bad seeds where the period is really short. For instance, if you initialize an LFSR with all-zero value, it gets stuck there, which is highly undesirable. When I say that the period is guaranteed to be 2^48, it means you don't have to worry about any bad seeds. As far as random quality is concerned, most 6502 users would happily pick a decent algorithm that's smaller & faster over one that's super high quality. When PractRand says it's good until 1 GB, it doesn't mean that it suddenly gets really bad. It just means that it's getting enough data that subtle patterns start to emerge. If you toss a coin that's heads for 50.00001% of the time, and you throw it billions of times, you start to realize that the coin is bad, but that doesn't mean it's useless. There are many applications where such a coin would be perfectly acceptable.


That's fine if you only want to test one particular algorithm. If I'm trying to optimize for cycles, I run hundreds of different trials, sometimes thousands. I can't run hundreds of variations if each attempt takes weeks to run.


1TB for a 6502 system is exceptionally good.


It's an issue for me, because having the test running on my PC slows it down for other things, including other random generators that I'm testing.

All you have to do is test your final generator, the one you propose as the best. For example, I proposed only two algorithms: LFSR64+LCG64 and ACR4. Not all intermediate test algorithms need to be tested for as long, only the last one should be.

Off topic, but may be interesting to some. I've (finally) released a version of a pseudo random generator for Microchip AVR / Arduino.

Arlet, superficially, this looks very promising with an immediate of #39:



I wondered what the ASL was doing to help, and TBH it looks pretty good without it:



These images are of an Apple ][ hi-res screen after filling the screen approximately 30% full of "random" dots. The one without the ASL seems to have a slightly coarser "texture", but I think either one suits my purposes just fine. Do you (or anyone else) have any further comments before I add it to VTLC02? It's going to have a net cost of nine bytes, but I think the improved quality and slightly improved performance outweigh the cost.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

The ASL is used to clear the carry flag, so that the output function is bijective (invertible). The first part of the code

has a cycle length of 65536, going through each 16 bit value exactly once before repeating. However, the random quality is poor, so this is followed by an output function to make it more random. In order to keep the property that each value appears exactly once, this extra output function must be invertible. Now, an EOR operation is invertible, if you know one of the operands, however, an ADC is only invertible if you also know the carry state before the ADC. Since the code above leaves the carry in a random state, we need to define it. That's what the ASL does, in a tricky way.

ASL followed by ADC #0 performs an 8 bit rotate left of the accumulator, and clears the carry. The rotate left is invertible, and helps with the randomness. In the code, there's no ADC #0, but ADC s+0, which does the same thing as ADC #0, but also adds s+0 as a bonus.

If you remove the ASL, there will be 256 values that appear twice in the 65536 cycle period, and 256 other values that don't appear at all.