Where does the Applesoft RND() function get its data?
Jayson Smith
there a spot in memory that contains random values, or a machine language
routine, or what?
Jayson
vladitx
Just by memory - I think the subroutine that produces pseudo-random
numbers uses entropy from a counter incremented by the KEYIN loop.
If you need more details, I can look it up for you. Or some of the
encyclopedic fellows on this list could cite it by heart. ;-)
And, no, there is no I/O location that gives random values. You either
read whatever device drives the bus, or the remnants of the last
scanned video byte. Almost 20 years ago I did a LORES maze generator
in 6502 assembly and needed some "random" source. I used $C030 as it
both produced some noise and resulted in seemingly-random mazes. But
they weren't - just the relation was too complex. :-)
David Empson
> On Feb 25, 10:48 am, "Jayson Smith"
> <ihatespamratguynospample...@insightbb.spamsucks.com> wrote:
> > I'm just wondering where the Applesoft RND() function gets its numbers. Is
> > there a spot in memory that contains random values, or a machine language
> > routine, or what?
>
> Just by memory - I think the subroutine that produces pseudo-random
> numbers uses entropy from a counter incremented by the KEYIN loop.
Nope. There is an entropy generator ($4E and $4F are incremented as a
16-bit number while waiting for a keypress) but there is nothing to
connect that automatically to the Applesoft RND() function.
By itself, RND() is a standard pseudo-random number generator which uses
a formula to calculate the next number in a sequence, which will
eventually wrap around and repeat the same pattern. I don't think I ever
knew the specific algorithm used by Applesoft.
The "wait for keypress" method is a good way to _seed_ the random number
generator. My vague recollection is that you seed RND() by passing it a
negative number, which you could construct from values PEEKed from
$4E/$4F.
--
David Empson
dem...@actrix.gen.nz
Toinet
IF ARG=0, THE LAST RANDOM NUMBER GENERATED IS RETURNED.
IF ARG .LT. 0, A NEW SEQUENCE OF RANDOM NUMBERS IS STARTED USING THE
ARGUMENT.
TO FORM THE NEXT RANDOM NUMBER IN THE SEQUENCE, MULTIPLY THE PREVIOUS
RANDOM NUMBER BY A RANDOM CONSTANT AND ADD IN ANOTHER RANDOM CONSTANT.
THE THEN HO AND LO BYTES ARE SWITCHED, THE EXPONENT IS PUT WHERE IT
WILL BE SHIFTED IN BY RMAL, & THE EXPONENT IN THE FAC IS SET TO 200 SO
THE RESULT WILL BE LESS THAN 1. THIS IS THEN NORMALIZED AND SAVED FOR
THE NEXT TIME. THE HO AND LOW BYTES WERE SWITCHED SO THERE WILL BE A
RANDOM CHANCE OF GETTING A NUMBER LESS THAN OR GREATER THAN .5."
There is a routine in ROM as well as a table for the use of it.
Sorry about the capital letters but it is not my writing (I am not
responsible for the mistakes)
antoine
BLuRry
Yes, in the source code of days gone past, they didn't think they were
yelling. Probably because they didn't have caps lock back then. ;-)
Michael Black
Hey, they didn't have lowercase.
Michael
Toinet
Michael and you are probably right. Who knows! AHAHAHAHAHAHAHAHAHAH
antoine
dagz
it up when I get home if that's what you really need.
On an Apple IIgs I tend to seed my Pseudo Random Number Generator
(PRNG) using the current value of the one of the Mega II Video Counter
values located at $C02E and $C02F.
Then (this is what I used for my fire demo last week) I found this
brilliant piece of code for 'randomizing' through all possible
values. Very awesome for the size involved. (The code below assumes
RND is a byte where we'll store our number)
GetRnd
lda RND
beq :doEor
asl
bcc :noEor
:doEor eor #$1d
:noEor sta RND
rts
That's basically what my implementation in Merlin looks like but go
see David Holz's page for a description and on how to increase the
number of possible values before repeating and expanding to 16bit (or
more) values.
David Holz's Article where I got this awesome bit of code:
A tiny, fast, 8-bit pseudo-random number generator in 6502 assembly
http://codebase64.net/doku.php?id=base:small_fast_8-bit_prng
You can also see it in my code from this demo (included on the
downloadable prodos image) though in my case I immediately remap it to
one of two values to seed my fire.
http://www.dagenbrock.com/blog/?q=node/23
Michael J. Mahon
> vladitx <vla...@nucleusys.com> wrote:
>
>
>>On Feb 25, 10:48 am, "Jayson Smith"
>><ihatespamratguynospample...@insightbb.spamsucks.com> wrote:
>>
>>>I'm just wondering where the Applesoft RND() function gets its numbers. Is
>>>there a spot in memory that contains random values, or a machine language
>>>routine, or what?
>>
>>Just by memory - I think the subroutine that produces pseudo-random
>>numbers uses entropy from a counter incremented by the KEYIN loop.
>
>
> Nope. There is an entropy generator ($4E and $4F are incremented as a
> 16-bit number while waiting for a keypress) but there is nothing to
> connect that automatically to the Applesoft RND() function.
>
> By itself, RND() is a standard pseudo-random number generator which uses
> a formula to calculate the next number in a sequence, which will
> eventually wrap around and repeat the same pattern. I don't think I ever
> knew the specific algorithm used by Applesoft.
It's a modified linear congruential generator. The seed (or previous
generated number) is multiplied by a constant, then a constant is added
and (the modification) the high and low bytes of the mantissa are
exchanged.
Unfortunately, the choice of constants is bad, resulting in a period
*much* shorter than 2^32-1. Further, there is a bug in Applesoft
initialization which causes the low byte of the initial seed to not
be initialized, so the default sequence is not repeatable unless the
function is explicitly seeded.
> The "wait for keypress" method is a good way to _seed_ the random number
> generator. My vague recollection is that you seed RND() by passing it a
> negative number, which you could construct from values PEEKed from
> $4E/$4F.
If you want different sequences of random numbers on each run of a
program, this method of seeding is good. If you want repeatable
sequences, seeding with a constant is necessary.
-michael
NadaNet and AppleCrate II: parallel computing for Apple II computers!
Home page: http://home.comcast.net/~mjmahon
"The wastebasket is our most important design
tool--and it's seriously underused."