Hardware RNG/Entropy on Cart?

[segaloco]

Are there any mappers or other companion cartridge hardware that served to provide an entropy/RNG source in hardware rather than software? What triggered this curiosity is that Nintendo's predominant RNG on the Famicom was a linear-feedback shift register, quite easy to implement solely in hardware, which then makes me wonder, if RNG is such a central part of game operation, wouldn't there have been a motivation to put such a circuit in the hardware? Sure, if someone doesn't like that implementation, now they've got a hardware subsystem they aren't using. Still, RNG seems like one of those areas where most folks don't want to have to fret, they just want to hit some entropy source and go. Thoughts? Considering other design patterns in early consoles were specifically to use purpose-driven hardware, and how simple LFSR is, it seems like something you could easily give someone in hardware (and faster than doing it in code).

[lidnariq]

The only readable hardware LFSR on anything NES-related I know of is the copy protection used in certain Vs. System arcade games.

The oldest place I remember seeing hardware LFSR actually used as PRNG is the WonderSwan.

[Pokun]

The NES CPU has an LFSR in the APU portion which uses it for the noise channel, but as Lidnariq implied it's not readable to the CPU.

But if you are going to waste hardware for a readable RNG, wouldn't it make more sense to make a TRNG circuit than another LFSR? Or perhaps just make the APU's LFSR readable for the CPU.

[TakuikaNinja]

I'm sure Atari would've chucked POKEYs into their carts if they were allowed to. They loved their LFSRs.

[segaloco]

Part of it too is that while it would still be an LFSR, it could be clocked directly to cycle on the master clock or something else. Sure, it is still deterministic for a finite time quantum, at this point the frequency would no longer be a function of specific code pathways. In other words, you'd have higher entropy because the only common thread between the generator and the code using it is that they're on components sharing a common clock. Still, it's different than knowing precisely what you seeded it with and precisely when you trigger a recycle.

Still I guess the flip side is that again if people aren't that obsessive and just need something "good enough" then a predictable deterministic software mechanism is probably good enough.

[TakuikaNinja]

Atari references aside, there are a few factors against using hardware entropy sources:

• Extra components for entropy means extra manufacturing costs. There's also the chance of hardware failures affecting the entropy.
• Programmers typically want to be able to debug RNG usage, so the deterministic nature of software PRNGs are usually better suited.
• The common remark is that "we don't actually want true randomness anyway" - We tend to prefer uniformity/"fairness" in outputs rather than true randomness. Our intuition of probability is also poor enough that some games go so far as to lie about percentages to reflect human perception. (e.g. "90% success" may be adjusted/inflated to guarantee 9 successes out of 10 attempts)

Even with a hardware source of entropy, it's often better to just use that for one-time seeding of software PRNGs for the second and third reasons. Thus, it makes the extra cost hard to justify.

[creaothceann]

There are some sources of randomness in the console:
- opcode 8B
- CPU/PPU clock alignment
- uninitialized/decaying RAM (or wire)

But even with the SNES, Nintendo didn't bother including a hardware RNG source. (Btw. the SNES has some randomness due to the different CPU/APU clock frequencies; the APU clock drift can even be seen via SD2SNES / FXPAK Pro.)

[TakuikaNinja]

Another aspect I forgot to mention: Software emulation and hardware clones may affect hardware entropy sources.
There are several commercial games which seed their PRNG with uninitialised RAM contents. There is a homebrew game which uses OAM decay and PPU open bus decay as sources of entropy to seed its PRNG: Auntie Tass
Verifying TASes for these games on hardware becomes much harder as a result.

[Ben Boldt]

The Famicom Network system provides a random number at register $40D5. The values of the low 3 bits change faster than, and asynchronously to, the Famicom's CPU clock.

[Pokun]

Another important argument against it might be that while a hardware LFSR is simple to build, a software LFSR is even simpler to implement and costs little ROM space. Given that it's good enough for most games as was said above there may not be much of any reason for a hardware one.