Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user ltk_tscc ! (Registered 2018-07-15) You are not logged in 
CSDb User Forums


Forums > C64 Productions > Random Numbers
2003-01-29 18:32
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!

 
... 11 posts hidden. Click here to view all posts....
 
2017-03-05 10:32
Groepaz

Registered: Dec 2001
Posts: 8586
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
2017-03-05 11:01
Perplex

Registered: Feb 2009
Posts: 209
Not to mention that using a random function to generate the table can result in *very* unevenly distributed sets of numbers.
2017-03-05 11:11
Groepaz

Registered: Dec 2001
Posts: 8586
indeed. its also pointless - combining two random things does not really improve anything (often quite the contrary)
2017-03-05 16:11
enthusi

Registered: May 2004
Posts: 646
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.
2017-03-06 00:41
Rudi

Registered: May 2010
Posts: 101
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.
2017-03-06 09:33
Groepaz

Registered: Dec 2001
Posts: 8586
relying on the current value of A is really a bad idea.... (this has nothing to do with LFSR either....)
2017-03-06 09:49
tlr

Registered: Sep 2003
Posts: 1168
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.
2017-03-06 14:52
Rudi

Registered: May 2010
Posts: 101
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.
2017-03-06 15:19
Groepaz

Registered: Dec 2001
Posts: 8586
its not a LFSR because it is not a shift register in the first place =)
2017-03-06 23:31
Rudi

Registered: May 2010
Posts: 101
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.
Previous - 1 | 2 | 3 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Merlin/The Seven-A-T..
Groepaz
Grue
iAN CooG/HVSC
nucleus/TempesT
Stainless Steel/F4CG
cadaver/covertbitops
Guests online: 58
Top Demos
1 Uncensored  (9.7)
2 Edge of Disgrace  (9.7)
3 Coma Light 13  (9.6)
4 Comaland 100%  (9.6)
5 The Shores of Reflec..  (9.6)
6 Wonderland XII  (9.6)
7 Lunatico  (9.6)
8 We Come in Peace  (9.5)
9 Incoherent Nightmare  (9.5)
10 Wonderland XIII  (9.5)
Top onefile Demos
1 FMX Music Demo  (9.6)
2 Daah, Those Acid Pil..  (9.5)
3 Pandemoniac Part 2 o..  (9.5)
4 Treu Love [reu]  (9.5)
5 Merry Xmas 2017  (9.4)
6 Arok 20 Invitation  (9.4)
7 Dawnfall V1.1  (9.4)
8 In Memoriam BHF  (9.4)
9 Dawnfall  (9.4)
10 Synthesis  (9.4)
Top Groups
1 Oxyron  (9.4)
2 Booze Design  (9.4)
3 Censor Design  (9.4)
4 Finnish Gold  (9.4)
5 Crest  (9.3)
Top Crackers
1 Mr. Z  (9.9)
2 Snacky  (9.6)
3 Antitrack  (9.6)
4 Sailor  (9.6)
5 S!R  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2018
Page generated in: 0.068 sec.