One fair way to do this is to take 3 bits (8 cases), and if they read 0 or 7, take another 3 bits - repeat until you get a value in [1..6] as required. This avoids the small bias of mapping the less-than-six highest values of a larger integer range onto the lowest values of the die, which would occur with a naive modulo operation.

Found this older post. I have already coded an implementation using the T1 timer on the VIA, will test it when I get actual hardware done.

But let's say I have to use the T1 timer for something else. Could I instead use the T2 timer to generate random numbers? Isn't there a 'free run' mode for T2 as well?

Looking at the datasheet, I see:



Say I don't have anything using CB1 and CB2 (or I could set those as inputs and/or disable interrupts?), wouldn't this also work?

Chad

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Interesting question! The datasheet says the shift register can shift in or out under control of T2 or free-running at the T2 rate. These modes are selected by ACR bits 4,3,2.

But those are shift-reg modes, not T2 modes. And T2 needs to be able to free-run (ie, self-reload) even when the shift-reg isn't. That's because, even when not free-running, the shift register still has 8 bits that need to be shifted.

So, clearly T2 is able to reload itself, which implies a latch is present... but the datasheet omits any mention of a T2 high-order latch; it only mentions the T2 low-order latch.

Maybe the T2 high-order latch does exist, and it gets written when the T2 high-order counter (address $9) gets written. Or, (more likely, I suspect) maybe the T2 high-order latch doesn't exist, and when T2 reloads itself the high-order bits get loaded with zero. Can anyone help me shed some light on this?

Back to your RNG, Chad... which is only 8-bit anyway. You also have the option (via ACR bit5) to let T2 count down according to pulses applied on PB6. In this case I expect T2 would, after reaching zero, simply underflow (as you would prefer) rather than self-reloading from the latch... but I haven't tried it, and I haven't pored over the datasheet for clues.

ETA: I overlooked Garth's post until now. But I too suspect the "one-shot" thing only has to do with interrupts. With no solid reason forcing them to stop the timer, the designers would've opted to just let it keep counting. I expect T2 never stops unless it's driven by PB6 and the latter has no activity.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I believe "one-shot" is more related to whether the timer automatically reloads after expiring. Yes T2 does keep counting after it has expired, indeed with care it's possible to reload T2 from within an interrupt handler to maintain a precise rate of T2 interrupts by subtracting the overrun from the new count to be loaded. This way I've been able to maintain an accurate time of day clock using T2, leaving T1 free for tone generation.

Warning off track - a "Now, let me tell you about the day, sonny.." story.

Back in '78 I made a 'true' random number generator. It consisted of a cheap AM radio tuned to a local station whose audio out was squared off, offset and fed into an a pair of 74ls93 counters which were attached to the data bus via a 74LS373 in a non-sequential manner. If you wanted a random number you just read the latch. It worked great for infrequent fetches, but had strict statistical issues if accessed too frequently (like more often than about every few of seconds or so) over small ample sets. Other than that, the distribution it produced was near perfect for reasonably short (for the day) accumulation times (hours - the longer the better).

You could do much better today for about $5 worth of parts. Simple things that just did not occur to me then or were out of price range.

Another trick we used for less important work was to pause program execution and ask the user to "Press any key to continue." While they responded a software counter would run and once they provided the response the value of the counter was used to seed the typical RNG (whatever was available). This pretty much guaranteed a different sequence (within the precision of the routine) each time the program started.

Sorry for the interruption.

_________________
Bill

The TSC Space Voyage game came with a pseudo-random number generator. It had two problems.

* It relied on garbage left in memory for the seed.
* If the seed was four bytes of zero, the code locks up.

To which I implemented two remedies:

* Before turning the game loose, check the seed for four zero bytes. If they are all zero, set them to something else.
* The game asks for four characters of input during initialization: Long or short game and three characters for the self-destruct password - four prime opportunities to randomize the seed.