Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Show me your (pseudo) random number generators!
2021-11-06 16:27
Frostbyte

Registered: Aug 2003
Posts: 183		 Show me your (pseudo) random number generators!

So, let's assume you need a "good enough" random number generator, but can't use SID OSC3 for it. Either you need the third channel for actual sound production, you're sizecoding and can't afford the overhead of setting up SID, or whatever reason.

For size reasons, I needed such generator for Bubblesid. After many iterations, I came up with this:

lax $dc04     // load CIA1 timer lo to A and X
eor ($02, x)  // EOR w/ {addr}. Randomish vector from previous list X position


Thus 5 bytes, 10 cycles. $02 is start of the table on zero page where I stored 200 random values (and later sorted them), so on 2nd and subsequent runs the previously sorted values work as a "seed" for the routine. It works pretty well even if you don't use ZP for storing the values.

In the end I needed to save some more bytes and used X as the loop counter, thus I didn't use lax for the final release. Anyway, the above seemed to produce the highest quality "randomness" given its footprint and speed.

Which approach would you take, or have taken in the past? Just curious to see other ways to implement this, as I'm sure there are many alternatives, which produce better (more random) results, are faster and/or smaller in footprint, etc.

PS. To a pretty newbie asm coder, it's mind blowing how much one can do with very little code. I really want to keep learning this stuff!
2021-11-06 16:44
Krill

Registered: Apr 2002
Posts: 2980		 Quoting Frostbyte
Which approach would you take, or have taken in the past?
You usually want a somewhat random seed (e.g., determined by current raster line and some other entropy sources), then a deterministic run of pseudo-random numbers (repeating at some point). Fixing the seed during development can then greatly ease fixing bugs etc.

As you mentioned size-coding, i took a very simple approach for Artefacts in the end (had an LFSR for a while during development):
				; get pseudo-random number
				; won't trash x, y
				; out: a - number in the range [$00..$ff]
.ifdef NTSC_VERSION
getrandom:      eor Artefacts+$0655
.else
getrandom:      eor Artefacts+$0653
.endif
                inc getrandom+$01
                rts
So a range of 256 bytes of its own code is read and EORed with whatever the caller passed in the accu.

Note that there weren't so many new numbers to get for a given amount of time, and that (iirc) the number of different callers to the routine was co-prime to 256.
It takes a very long time for the demo to loop and arrive at the same textures and heightmaps it starts with.

Oh, and about eor ($02,x) in your approach, do you initialise $02/3? Because if not, you really do not want to accidentally read things like certain IO registers and trigger creative bugs. =)
2021-11-06 17:12
Frostbyte

Registered: Aug 2003
Posts: 183		 Ha, very cool approach! :)

Quote:
Oh, and about eor ($02,x) in your approach, do you initialise $02/3? Because if not, you really do not want to accidentally read things like certain IO registers and trigger creative bugs. =)

No init done, I didn't think (know) that simply reading something from memory (or IO) would alter the state of anything else, I always thought that a read is a read and that's it. What examples of this would there be?
2021-11-06 17:22
Krill

Registered: Apr 2002
Posts: 2980		 Quoting Frostbyte
No init done, I didn't think (know) that simply reading something from memory (or IO) would alter the state of anything else, I always thought that a read is a read and that's it. What examples of this would there be?
Things like interrupt control registers which are read to acknowledge interrupts (http://unusedino.de/ec64/technical/aay/c64/cia113.htm) or collision detection registers (http://unusedino.de/ec64/technical/aay/c64/vic30.htm).

So yeah, reading certain IO registers may change internal state in the corresponding chips. :)
2021-11-06 17:38
Frostbyte

Registered: Aug 2003
Posts: 183		 Ahhh right... Well, good to know. I guess I was lucky that my humble little prod was so simple, with no IRQs or care about sprite collisions etc. Otherwise I would have pulled my hair out trying to resolve seemingly randomly (pun intended) occurring bugs. :D
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
Dan
MWR/Visdom
Broti/DT/KRN
megasoftargentina
Steve/Laser, Zenith,..
rexbeng
Murphy/Exceed
Shake/Role
Knight Rider/TREX
Guests online: 104
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Coma Light 13  (9.6)
4 Mojo  (9.6)
5 Edge of Disgrace  (9.6)
6 The Demo Coder  (9.6)
7 What Is The Matrix 2  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 Layers  (9.6)
2 No Listen  (9.6)
3 Party Elk 2  (9.6)
4 Cubic Dream  (9.6)
5 Copper Booze  (9.6)
6 Rainbow Connection  (9.5)
7 Dawnfall V1.1  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Triad  (9.3)
5 Censor Design  (9.3)
Top NTSC-Fixers
1 Pudwerx  (10)
2 Booze  (9.7)
3 Stormbringer  (9.7)
4 Fungus  (9.6)
5 Grim Reaper  (9.3)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.044 sec.