How would I generate random numbers?

Yeah, this seems pretty difficult. How would I generate random numbers? I need between 0 and 255. Any suggestions?

These are the simplest pseudo-random number generators I'm aware of:

http://codebase64.org/doku.php?id=base: ... 8-bit_prng
http://codebase64.org/doku.php?id=base: ... 6-bit_prng

But we have lots of topics on this forum about this, just search for "PRNG".

That would work otherwise, but I'm having a randomly generated level, where we can't base it on stuff like how long the user pressed a button. And I also don't think Tokumaru's would quite work either. The data I'm working with will always have the same result, it's a loop. One register keeps the tile number it will write to the nametable depending on the number, another register has the random number, and another register has how many times it's looped and where in the level it is. So shifting bits would not only corrupt the data, having an EOR would make every single level have the exact same result.

You have to store X and A in memory before calling the PRNG subroutine, then reload them once it returns.


The levels will only be the same if the PRNG state is exactly the same. To randomize the starting state (i.e. seed the PRNG), you have to rely on other methods such as button presses or startup state.

There's no true source of randomness on the NES, seeing as memory tends to be all 0s or all 1s on power up, so the most straightforward seed you can get for a PRNG is one based on user input. Surely your game will have a title screen and maybe other menus before the actual game begins, so just count those frames and use the final result to seed the PRNG.


The 6502 has very few registers, so most kinds logic will require you to swap values between CPU registers and RAM, there's no way around that.

This topic appears to duplicate Implementing a (pseudo) random number generator.

Many games count frames from power-on until pressing Start and use that to seed the PRNG. There are other ways to generate entropy, such as polling the controller in a DMC IRQ handler (adds roughly 6 bits vs. once per frame) or even exploiting analog behavior of the PPU as in the Pretendo demo.

There are a lot of different kind of random number generators. However, for generating entropy, analog effects should probably not be used as the only source, although it may be usable as additional entropy. Initial RAM contents and microphone input also should not be used as the only sources of entropy, but they may be used as additional entropy. The primary sources should probably be time between inputs (e.g. how long before you push start). At least, these are my opinion.

There's some truth to this Dilbert Comic. (The RNG outputs 9,9,9,9,9,9). In a true random system, this might actually be random output, which is clearly not what programmers want.

http://dilbert.com/strip/2001-10-25

Assuming that's 6 random digits (repeat 6 1d10 at Rolz), a programmer wants that result one of every million tries. But 999999 thrice in a row makes it overwhelmingly likely that the RNG is broken.

Randomness extracted from user input is great (except if the user input is somehow manipulated before it reaches the program, such as a keyboard buffer).

Anectode on broken RNGs: This is what PHP rand() looks like on windows. Not so random.

We're getting into the usual round of commentary about PRNGs, but I suspect the OP's confusion is on a more basic level of not understanding the difference between generating a seed for a PRNG and using the PRNG sequence, and possibly at the same time not understanding how registers and memory storage works?

If there's a timer running anywhere in the system, reading its value to use for part of the RNG's operation usually works well since you don't know where it will be in its cycle when the random number is needed.