| |
Dr. Jay
Account closed
Registered: Jan 2003
Posts: 32 |
Random Numbers
Just wanted to share. This has probably been discussed a million times, but in case it hasn't ... was doing a search for random numbers. Some of the old hardware tricks like $d800 don't work with specific versions of the machine and certainly not in all emulators. I found this snippet of code which, if I remember correctly, was from boulderdash:
random eor $dc04
eor $dc05
eor $dd04
adc $dd05
eor $dd06
eor $dd07
rts
Tried using it - I always test random numbers by using the sequence to plot pixels. If you have a bad generator, you can easily see patterns. I could tell this pattern above was clustering on byte-boundaries after watching a few minutes in the plotter. I felt like it was because it was synched too much to the timers and that something would have to throw it out. Then I started thinking about how stable rasters are a $#$@#$@$ and if the call to this routine doesn't always come on a stable raster then we'll have some cycles out of synch ... so I made this simple modification:
random lda #$00
eor $dc04
eor $dc05
eor $dd04
adc $dd05
eor $dd06
eor $dd07
sta random+1
rts
And it appears to work like a charm - much more random! Just uses a seed to feed into the timer sequence, rather than the timer sequence alone!
|
|
| |
Stryyker
Registered: Dec 2001
Posts: 465 |
I used something similar but had some addings I think. It used 2 or 3 bytes that BASIC uses for it's seed. I added, shifted etc. with these bytes, also using CIA timer 1 then wrote over the seed values. I used it in some random plotter (inspired by Chaos 101/Style I think), maybe also used in my demo Sans. stryyker.webhop.org has the demo. |
| |
CyberBrain
Administrator
Posts: 392 |
what a kewl and *elegant* way to make random numbers! |
| |
xIII
Registered: Nov 2008
Posts: 210 |
Sorry for bringing this very old thread back but is this still a good way to make random numbers ?
How should I change this routine to get random numbers from 0 to 9 ? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
this has never been a good way in the first place :) its not even faster than a proper 16bit lfsr for that matter....
to get numbers in a specific range, the "correct" way (which preserves even distribution of all numbers) is to generate a number in range 0...1, and then multiply the result by your range.
if you can live with somewhat uneven distribution, first generate a number in 0...255 range, then use the result as index into a one page table that contains all numbers you want to get |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
http://codebase64.org/doku.php?id=base:6502_6510_maths#random_n.. |
| |
xIII
Registered: Nov 2008
Posts: 210 |
Thx Groepaz.
I did some more research @codebase64 and found this random generator and in combination with the table you suggested it works fine for me.
.var sr = $ff
lda sr+1
asl
asl
eor sr+1
asl
eor sr+1
asl
asl
eor sr+1
asl
rol sr
rol sr+1
tax
lda rnd_table,x
sta rnd_number
rnd_table: .for(var i=0;i<256;i++) .byte random()*9+48
|
| |
xIII
Registered: Nov 2008
Posts: 210 |
Thx Oswald :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
Quote:.byte random()*9+48
i'd use something like .byte (i%9)+48 instead ... if only because it will always assemble into the same table |
| |
xIII
Registered: Nov 2008
Posts: 210 |
Quote: Quote:.byte random()*9+48
i'd use something like .byte (i%9)+48 instead ... if only because it will always assemble into the same table
Kickassembler doesn't seem to like this ?
Maybe because I use C64 Kickass IDE v1.2 which is old? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
no idea what kickass likes really :=) it must have some kind of modulo operator, i guess =P |
| |
xIII
Registered: Nov 2008
Posts: 210 |
Quote: no idea what kickass likes really :=) it must have some kind of modulo operator, i guess =P
mod(random()*9,9)+48 seems to work.
But it's no problem if the table assembles different everytime ;) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
Quote:mod(random()*9,9)+48 seems to work.
now THAT makes no sentence whatsoever.... you are still using the random function =)
Quote:But it's no problem if the table assembles different everytime ;)
trust me, unless what you are doing is trivial, you always want code that can be tested in a way that the expected results do not change for each compile =P |
| |
Perplex
Registered: Feb 2009
Posts: 254 |
Not to mention that using a random function to generate the table can result in *very* unevenly distributed sets of numbers. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
indeed. its also pointless - combining two random things does not really improve anything (often quite the contrary) |
| |
enthusi
Registered: May 2004
Posts: 675 |
For my recent games I create a Rijndael sbox table which is surprisingly little code and the I generate pointers into it with a simple full width 8 bit lfsr. Thus I have no bit-correlations between calls. |
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
prng:
inx
adc #157 ;lo-byte of seed
sta $fb
eor $fc
adc #17 ;hi-byte of seed
sta $fc
eor $fb
sta $0400,x
jmp prng
use two immediate values for seed, and two memory locations: $fb and $fc for processing. those are scrambled during each update by the xor and adc's. not done any diehard testing, but looks random to me. rule 30 produce randomness which is basically two boolean operators: or and xor on two inputs. i guess its the same what happens here. it is LFSR probable due to previous states of the accumulator. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
relying on the current value of A is really a bad idea.... (this has nothing to do with LFSR either....) |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quote: For my recent games I create a Rijndael sbox table which is surprisingly little code and the I generate pointers into it with a simple full width 8 bit lfsr. Thus I have no bit-correlations between calls.
Doesn't this just give you a repeating sequence of 255 numbers? I would go for a longer LFSR. |
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
Quote: relying on the current value of A is really a bad idea.... (this has nothing to do with LFSR either....)
You are right Groepaz, its not linear, but it is dependant on its previous states, so I misread wikipedia: "a linear-feedback shift register (LFSR) is a shift register whose input bit is a linear function of its previous state."
Don't use accumulator then. The values are stored in memory. In this case accumulator is used only to generate the numbers. It have longer periodicity because it use two temp values (16-bit). This was meant as precalc. Doing this in without precalc may be used in special cases like this: 32 Bytes Fuzzy Logic but that uses another method. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
its not a LFSR because it is not a shift register in the first place =) |
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
true true. i was wrong when i said it was LFSR. but would have been nice to find out what their logical differences are however. its just bit manipulation. some prng's ive made earlier use rol instead of lsr. |
