Re: [stella] entropy & randomness

Subject: Re: [stella] entropy & randomness
From: Kevin Horton <khorton@xxxxxxxxxxx>
Date: Wed, 10 Oct 2001 18:31:33 -0500
At 11:34 10/9/01 -0400, you wrote:
On Tue, 9 Oct 2001, Kevin Horton wrote:

> As for seeding it, I suggest this method. It seems to work very effectively.
> Note I also initialize the 2600 at the same time by writing 000h to all
> zeropage addresses, and I set the SP to 0ffh.
> init2600: ldx #000h ;start at byte 00000h in RAM
> ir_loop: txa
> eor #03h ;prevent XORing regs with themselves
> and #03h ;make sure all 4 regs get a chance at being
> tay ;seeded
> lda 000h,x
> eor rand0,y ;xor is best for this since all bits have an
> sta rand0,y ;equal chance at being flipped.
> eor lda #0 ;load #00h into RAM
> sta 000h,x
> txs ;set stack to 0ffh at end of loop :-)
> inx
> bne ir_loop
> lda rand0
> ora rand1
> ora rand2
> ora rand3 ;check for 000000000h state. bad juju if so
> bne no_prob
> inc rand2 ;set rand2 to 001h.
> no_prob: rts
> Basically, the routine grabs whatever happens to be in the TIA regs, and in
> RAM and XORs it with the random # registers. Note that the eor #03h is
> very important, since it prevents the registers XORing themselves. This
> would set them to 00h. After it grabs what happens to be in RAM/TIA, it
> writes 00h to the location, and sets the stack. Since x will be 0ffh
> before the loop ends, we get a "free" way to set the stack. Cute,
> hunh. As a bonus, X will = 0 which may be useful on return from this routine.

Very cute. May I steal^H^H^H^H^Hborrow that code for a game?

Sure, feel free to use it.

Hmm, if the RAM also holds random junk on powerup, wouldn't it be enough to
just use them as-is (after checking to make sure they didn't all happen to
be zero)?

Maybe. Even though the RAM holds junk on startup, the junk is usually "biased" heavily; i.e. every powerup, location 080h may hold 23h. The determining factor for this is the sizes of the transistors on the chip; which ever one has more current drive will "win" and stick the flipflop in the same state usually. There is no way to predict which bits will go which way, and it varies from chip to chip and manufacturer to manufacturer.

I suggest the XOR thing just out of good practice just in case. Why settle for steak if you can have fillet mignon?

> 000h Even so, the TIA addresses shouldn't all read 00h).

Oddly enough, xstella doesn't init all RAM to zero... apparently it does
put random garbage in there, because I had forgotten the BNE in the zeroing
loop at the beginning of the cart, and the result was, the `suicide mission'
LSFR started with a different seed each time the emulator was run...

hmm, interesting.

> A very good example of an LFSR getting stuck at the all 0's state is

That also could be useful behavior, for debugging... maybe you could take
advantage of it by defining the random seed on the command line:

Hmmm, that's a good idea.

Couple of questions... I'd like to include this piece more-or-less verbatim in
the V2 stelladoc, is that ok with you? Also, what assembler is your code written
for? DASM doesn't seem to like 000h as a constant... so I run it thru this


I used Table Assembler with the 6502 table. It's my assembler of choice since it works for multiple processors I use (Z80, 8085, 6502, 65816 (personal table mod)).

perl -pe '1 while s/^([^;]*?)([a-fA-F\d])*h/$1\$$2/'

and all is well. So what do I call my perl program? <something>2dasm... having
typed that horrible mess once, there's no way I'm going to remember it or type
it again :)

hahaha. My coding convention is slightly different than what everyone else uses here it seems. Hope it won't cause problems.

- Archives (includes files) at Unsub & more at

Current Thread