Jump to content
IGNORED

IntyBasic RAND


Recommended Posts

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

  • Like 1
Link to comment
Share on other sites

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
  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 1 month later...

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.
     

 

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...