I have discovered a potentially disasterous bug in
the random number generator we use in our games. The problem
lies in the line:

	    return( (((ulong) in << 15) + lfrac) >> 16);

which should just be:

	    return lfrac >> 16;

Apparently the extra factor of in was added in an attempt to force rand()
to return numbers from 0 to in _inclusive_. Without this factor, rand()
should return a uniform distribution from 0 (inclusive) to in (exclusive).
With the added factor, rand() may actually return numbers LARGER than in!

	By the time you read this, an updated copy of rand.asm for the 68K
will be in EE$USERDISK:[68K_US].

			We now return you to your regular programming
				Mike

	My mail yesterday was based on the (dubious) practice of
stripping the 'C' comments out of the 68000 assembly 'RAND' from
Pit Fighter. In fact, the addition of (in << 15) is not only harmless
in the asm version, it is needed, if the rest of the routine is
left alone. Unfortunately, the "MULS" immediately above the lines
in question makes the "raw" random number have a range [-in/2..in/2),
so the addition (effectively) of in/2 was needed. On the other hand,
changing to a MULU lets you shine on the addition _and_ save some time.

	If all this is just too confusing, just copy the _new_ RAND.ASM
(if you took the old-new one yesterday) and accept my apologies for
any hair-tearing that rand(42) occasionally returning -21 caused.

				Maybe I should go back to pumping gas,
					Mike