+Tarzilla Posted June 14, 2015 Share Posted June 14, 2015 As discussed in parts of this thread: http://atariage.com/forums/topic/238929-the-secret-government-waffle-project/page-9?do=findComment&comment=3254818 There has been discussion around IntyBasic, specifically version 1.04 As DZ Jay point out, successive calls to RAND without an intervening call to WAIT will return the same value. GroovyBee said: This is what I typically use in my games :- SCRATCH_RAM_START EQU $100 SYSTEM_RAM_END EQU $360 FALLBACK_SEED EQU ('G' SHL +'B' ; Go through all sources of entropy and create a random seed. ; Note: Reads all scratch RAM, PSG0 registers and system RAM. mvii #SCRATCH_RAM_START, r4 mvii #(SYSTEM_RAM_END-SCRATCH_RAM_START)/4, r3 @@RandomSeedLoop: add@ r4, r0 add@ r4, r0 add@ r4, r0 add@ r4, r0 decr r3 bne @@RandomSeedLoop ; Any non zero value is a good seed. tstr r0 bne @@RandomSeedOK ; Seed we computed was poor, so use a fallback value. mvii #FALLBACK_SEED, r0 ; Keep the seed for later. @@RandomSeedOK: mvo r0, theRandomSeed nanochess chimed in: Hey GroovyBee, it's a good idea. Can I use it in my next version of IntyBASIC? Then intvnut said: There are a handful of sources of limited true entropy on the Intellivision at powerup: System RAM. Doesn't get cleared by the EXEC. Checksum its contents and add to the seed. GRAM. Also doesn't doesn't get cleared by EXEC prior to game. Checsum and add to the seed. Reads from GRAM/GROM/STIC during active display. Not entirely random; more like "difficult to predict". CPU sees whatever activity is going on over on the STIC-controlled bus. On later systems that use an RA-3-9600A, addresses in the range $360-$3FF return garbage, and the garbage isn't 100% stable. ie. it's a decent small source of entropy, when it's available. Executing direct mode reads from instructions in System RAM. The System RAM doesn't implement the ADAR bus phase correctly, so you get some random 'bus fade' value. Non-sources: Scratch RAM and PSG. The EXEC zeroes out the Scratch RAM (and then writes some initializers over that), and zeros out the PSG. So, while you can checksum these, they won't help much. STIC registers. The EXEC zeros these out too. Other things were said, but this sums it up 1 Quote Link to comment Share on other sites More sharing options...
+Tarzilla Posted June 14, 2015 Author Share Posted June 14, 2015 JPL board or not ,I'm all for two random functions. One like GroovyBee suggested and one based off a seed. I've been doing some playing around with procedural generated dungeons and landscapes, having a repeatable random function would be handy for maze generation as would a true random one for enemy placement and stats. 'Randomize with Seed, auto advance on call RANDSEED 232 x=(RAND % 22)+1 and 'Entropy seeded at initialization, auto advance on call y=(RANDOM % 22) +1 1 Quote Link to comment Share on other sites More sharing options...
intvnut Posted June 14, 2015 Share Posted June 14, 2015 Typically, I use LFSR-based generators both for seed based generators and non-deterministic generators. LFSRs are very cheap and quite effective. It's around 112 to 160 cycles to update a seed by 8 bits w/out a lookup table: . MVII #POLY, R1 SLLC R0, 1 ADCR PC XORR R1, R0 SLLC R0, 1 ADCR PC XORR R1, R0 SLLC R0, 1 ADCR PC XORR R1, R0 SLLC R0, 1 ADCR PC XORR R1, R0 SLLC R0, 1 ADCR PC XORR R1, R0 SLLC R0, 1 ADCR PC XORR R1, R0 SLLC R0, 1 ADCR PC XORR R1, R0 SLLC R0, 1 ADCR PC XORR R1, R0 . That's not too bad, really. Combine that with ~50 more cycles of stuff for an 8x8 multiply and you've got a decent 8-bit RAND in around 220 cycles. (Note I said multiply, not modulo. Using modulo as I saw in the other thread is potentially much slower, esp. for small modulos.) With the LFSR approach, the only difference between the deterministic and non-deterministic generator is whether you mix in outside entropy sources. I guess the other question is whether you keep mixing outside entropy in, or only use outside entropy to seed it initially. Quote Link to comment Share on other sites More sharing options...
+Tarzilla Posted August 6, 2015 Author Share Posted August 6, 2015 IntyBasic 1.1 has improved support for Random Number generation RANDOM(range) Obtains a pseudo-random value between 0 and range-1. Forces update of random number (it doesn't need a WAIT to change). Note it's slower to generate, the faster ones are based on powers of 2. Also range limited to a maximum of 256. vs the original RAND (which is still supported) RAND Obtains a pseudo-random value between 0 and 255. Updated on each video frame RAND(range) Obtains a pseudo-random value between 0 and range-1. Updated on each video frame. Note it's slower to generate, the faster generated ones are based on powers of 2. Also range limited to a maximum of 256. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.