Re: [stella] Perfect BIN copy protection

Subject: Re: [stella] Perfect BIN copy protection
From: "Roger Williams" <mer02@xxxxxxxxxxxxx>
Date: Sat, 2 Feb 2002 07:30:31 -0800
----- Original Message ----- 
From: Manuel Polik <cybergoth@xxxxxxxx>

> Well, the goal Thomas and I had, was meant to provide 
> BINs that run flawlessly on an emulator, but not on any 
> real hardware.
> We know how to disable the Cuttle Cart, the 
> Supercharger, Distella and the Debugger of PCAE.

The problem w/r/t this is that you are depending
on subtle differences between emulators and real
hardware.  Those differences only exist because
the emulators are imperfect -- RAM where there
should be ROM, addresses mapped to 64K instead
of 8K, and so on.  Call me a purist, but bins created
to tank on a real 2600 aren't 2600 bins, even if you
do have nearly-identical bins that don't tank.

As far as the Supercharger/Cuttle Cart, we know
those devices were never meant as hack tools.  It
doesn't take much effort, especially if you are aiming
at 4K/8K ROMs, to build a RAM cart with write-
protect switch which will work *exactly* like a ROM
or, with the flick of a switch, *exactly* like an emulator
with RAM yet none of the control structures of the
Cuttle Cart.  Such a beast is actually much simpler than
the Cuttle Cart, and would be the standard if the
Supercharger had never existed.

> We know how to addtitionally hack-protect the game, in a 
> way we think that's so frustrating to remove, that 
> anybody attempting it will give up at some point.

Well, that's a more reasonable goal.

> It'd be a 2600 in _every_ sense, but noone halfway 
> insane would go through the troubles to hack it to run 
> on the Cuttle Cart :-)

Point taken, but that's not "perfect" copy protection.
You have to remember that a lot of hackers ARE
halfway insane.  If retrogaming was more popular
among 15-year-olds with nothing to do but learn
programming by hacking your code, 2600 copy
protection would be a goal worthy of King Canute

> After the headache of removing Thomas test protection, 
> which was far away from what we could do now, I decided 
> to never do that again :-)

Heh.  You just haven't been motivated to build
the appropriate tools, that's all.  Wait till some
15-year-old gets interested :-)

Once upon a time there was a computer called
the "Interact Model R" which was surplused after
the company that made it tanked.  It had 16K RAM,
a 4 MHz 8080A, and integral tape deck.  There
were a few hundred of us in the user's group.

A fellow named Harry Holloway wrote some
really fine programming and debugging tools
and sold them through the user group.  One
tool was the HI/LO monitor, so called because
it could be loaded in either high or low RAM
so as to examine other programs wherever
they might live.  8080A code is not relocatable.
HI/LO had a lot of neat functions; it would
examine tape headers without loading them,
do most of what DOS DEBUG does, and
so on.  Only one problem -- it would not do
any of these things to a program Harry
Holloway had written, including the HI/LO
monitor itself.

I finally cracked it by writing an 8K block
of zeroes.  I started loading this tape, stopped
the deck, put the HI/LO monitor tape in, and
pressed play.  This sprayed the tape leader
and header information in raw form into the
machine's RAM where the monitor didn't
realize what it was.  This dump revealed the
existence of a nonsense header which loaded
6 bytes from $0000-$0005, which was
stoopid because those addresses were ROM.
Dad, who had taken German in school,
explained to me what the data "VERBOT"
probably signified.

Since HI/LO would not monitor within
itself I wrote a very, very short external program
to search its guts for "VE."  Then another very,
very short program to change the "E" to
something else.  And that, as they say, was

Of course I'd never spend this much time
on such a project today.  But that's because
I'm not 15 any more.


P.S. If Harry is out there, thanks for teaching
me how to program.

Archives (includes files) at
Unsub & more at

Current Thread