[Coco] Is the RND command really generating a random number?

[Mark McDougall]

On 19/05/2017 11:05 AM, Glen Hewlett wrote:

> On that note, the Pac Man game actually gets the value of a byte in
> the ROM and uses that as part of next seed value for the random #.
> So to make a Pac Man game work exactly the same as the arcade machine
> (use the same patterns) you need to have a copy of the that actual
> Pac Man ROM.  Sorry - I’m all about Pac Man these days...

And it's not the only game to do it; I've seen it a few times in the 
past, though I can't immediately recall when and where.

As others have mentioned, generating random numbers is one side of the 
equation - the other is seeding it. It's common to use the delay of 
human input to a prompt, something that was quite common in the early 
days of BASIC games.

ZX Spectrum Knight Lore (sorry, I'm all about Knight Lore these days) 
seeds the whole process by reading the value of one byte of the ZX 
Spectrum FRAMES system variable (the frame counter) on startup.

Without any means to generate a random seed on a stock Coco3, I went old 
school and spun an LFSR during the splash screen display in my port of 
Knight Lore, waiting for input. That subsequently seeds the LFSR that is 
updated periodically in a timer FIRQ to 'emulate' the Z80 Refresh 
register used as a random value throughout the (original version of the) 
game.

[An LFSR is a mathematical construct that can produce a long string of 
seemingly random values. The issue is that it's completely deterministic 
- ie. the sequence it produces is fixed - so you need a 'seed' to 
randomise the starting point in the sequence. Particularly useful are 
so-called maximal length LFSRs, which will produce a sequence of 2^n-1 
numbers for an n-bit value. And computationally, Galois LFSRs are very 
efficient to code - just a few ASM instructions to implement a 3-tap, 
16-bit maximal length LFSR for example!]

Regards,

-- 
Mark McDougall
<http://retroports.blogspot.com.au>