RE: [stella] Perfect BIN copy protection

Subject: RE: [stella] Perfect BIN copy protection
From: Nicolás Olhaberry <nolh@xxxxxxxxxxxxx>
Date: Sun, 3 Feb 2002 16:35:46 -0300
----- Original Message -----
From: Chad Schell <gamer@xxxxxxxxxxx>
To: <stella@xxxxxxxxxxx>
Sent: Saturday, February 02, 2002 7:04 PM
Subject: Re: [stella] Perfect BIN copy protection

> The difference lies in the state of the processor flags and the 2600's
> internal RAM.  With a standard cart, when you plug it in and turn on the
> 2600, the RAM will be in a random state.

Are you sure about this? I think the RAM starts in a known state, zeroed,
most likely.

For example, combat uses the address $DD as some sort of mask
for the objects colors (I can´t give more info, never looked at the code
with too much detail). The game doesn´t write on $DD until you press reset
or some time passes, so, for the first seconds of the game, $DD will have an
undefined value, and, unless it is zero or one (since the low order bit
isn´t used in COLUXX), you don´t get the right color for any object.

Also, Roger Williams posted some interesting thoughts on how the "frying"
worked, he said that the ram gets undervoltaged, and since the effect
it´s so repeatable, the ram probably started in a known state. I tried this
in my
emu with a few games, and storing zero in all the ram area seems to produce
the same "frying" effect. I didn´t get the same effect storing one, for
example the guy in Pitfall! doesn´t get colored in black.



Archives (includes files) at
Unsub & more at

Current Thread