Re: [stella] Poker solitaire source, versions 012 & 014

Subject: Re: [stella] Poker solitaire source, versions 012 & 014
From: "Roger Williams" <mer02@xxxxxxxxxxxxx>
Date: Wed, 28 Nov 2001 21:33:52 -0800
> Whatever it was doing? Like showing white noise? Hmmm. The TIA won't spit
> out any signal at all just from being powered up? I'll have to play with
> this.. wait. Even if there's no TIA output, the RF modulator will be on..
> Still, if I get a black screen, or rolling v-hold nastiness or whatever
> as long as it takes to do 200 shuffle loops, that's no biggie (about 50
> cycles per loop, times 200, still isn't much real time!)

During the few frames it would take to shuffle the deck, most TV's
wouldn't manage to sync up anyway.  You get a little "snap" effect
as the TV acquires horizontal and vertical sync.  It would be a tiny
fraction of a second longer, that's all.  I doubt if it would take more
than a frame or two to do *nothing* but a full shuffle.  One frame is
19912 CPU cycles.

> Have to reinitialize the deck. It takes 52 bytes to store the deck during
> the shuffle, then I `throw away' the last 27 cards (use them to store the
> hand as it's being played, so they get initialized to BLANK_CARD). If I
> had the RAM, I wouldn't do that.. I thought of initializing the deck to
> a `random' order instead of sorted, but of course the `random' order would
> still be hard-coded in the ROM, identical for every shuffle.

Ah, makes sense.  Definitely leave the RNG running all the time
then, and you'll at least have a good random starting point in the
RNG second time around.

> > It's more like an exploration of how thorough you were.  Many
> > of the "easter eggs" triggered by "frying" the 2600 are actually due
> > to bypassed initialization.
> Meaning the program makes assumptions about the contents of RAM, or
> the init code somehow gets bypassed by the act of frying? I've never had
> the slightest idea what goes on inside the 2600 during `frying'... seems
> thoroughly random to me, but then I haven't done it much... if it's not
> really random, I wonder how hard it would be to emulate? :)

It's a bit more subtle than that.  Frying works by undervoltaging
the chips, and different chips react differently to that.  I think
most of the effects come from RAM (the PIA) getting randomized
or reset without the 6507 getting reset.  The program charges
happily along thinking it has good data, oblivious to the fact that
its state has been trashed and it is interpreting garbage as data.
(The fact that frying is so consistent would argue that the RAM
is getting zeroed of $FF'ed, a condition which could be tested.

Incidentally, I once had a computer in the late 70's that could
_really_ be fried.  It had the very early 4-voltage 4116 16Kbit
chips.  These chips specified that +12V *must* be applied
before +5.  The maker of this surplus computer I had ("Interact
Model R") had solved this problem by leaving +12 on all the
time.  Which worked fine, unless you used an outlet strip to
turn on the computer.  Usually this was OK too, except for
the one time in every few hundred when +5 would win the
race, and your RAM chips would blow up like little firecrackers.
Cost a couple of hundred bucks for replacements, and they
were soldered in :-(

--Roger Williams

Archives (includes files) at
Unsub & more at

Current Thread