Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpda!hpcuhc!hpcupt3!ken
From: ken@hpcupt3.cup.hp.com (Kenneth M. Sumrall)
Newsgroups: comp.sys.atari.8bit
Subject: Re: Copy Protection Scheme
Message-ID: <48510004@hpcupt3.cup.hp.com>
Date: 12 Apr 91 06:15:04 GMT
References: <40060005@hpopd.pwd.hp.com>
Organization: Hewlett Packard, Cupertino
Lines: 64

>       * Read Sector <N> into buffer        [$600-$67F]
>       * Read the SAME Sector into buffer   [$680-$7FF]
>       * For X = #$00 to #$7F do..
>	  * EOR $600,X with $680,X and store in $2800,X
>                     [... Stuff deleted...]
>Does anyone know how the disk was manufactured such that reading the same
>sector gave TWO different, but CONSISTANT, sets of data?
>
Excellent hack work Simon.  I did this on Choplifter way back in 1981.
Very difficult to figure out when I never knew more than one sector
could have the same sector number.  (10th grade == not very bright :-)

>Observations:
>  1. The two sets of data NEED to be consistant to produce the correct code
>      when EOR'd together.
>  2. It doesn't matter which order the data sets arrive in as EOR is 
>      commutative.
>
Correct.

>  3. Reading the sector several times did not guarantee alternation of the
>      two data sets.
>
If you read them with a sector editor, of course not.  However, if read
in rapid succesion by an assembly program, the computer generates the
first read.  It is satisfied as soon as a sector with the correct number
passes under the disk drive head.  Then, immediately ask for the same
sector again.  The computer will send the request to the disk drive before
the other sector with the same number passes under the head, and now
the disk drive will satisfy the read request with the other sector.

>  4. There wasn't any provision for checking that the second read of the 
>      sector had produced the OTHER data set.
>
Not needed because the way the sectors are read in guarantees
the correct data.

>What puzzles me is 3. and 4.  Together they seem to imply that occasionally, 
>two consecutive reads of the sector would produce the same result which when
>EOR'd together would, of course, produce a zero filled buffer. This in
>turn would halt the program with the JSR call. However, in the numerous
>times I have loaded and played the game in the past, I have NEVER seen this
>happen.. it's always loaded fine.
>
>Any ideas?
>
Choplifter used a slightly different scheme, if I remember correctly.
It seems that three sectors had the same number.  The loading routine
would read the same sector 10 times into two different locations
alternatively.  Some how, this produced the correct data in the right
locations.  I never figured out why.  Anyway, I copied the two
neccesary sectors to two DIFFERENT sectors on my copy, changed the loader
to read one sector into one location, and the other sector into another,
and jump to it.  Luckily, the boot loader didn't checksum itself before
running the program.  I believe that Way Out did this.  Made it a little more
difficult to hack.  Of course, now that I have a Happy Drive, backups
aren't so difficult!

>Simon Hunt.

| Ken Sumrall                          |     Internet: ken%hpda@hplabs.hp.com |
| HP California Language Labs          |           UUCP:  ...!hplabs!hpda!ken |
|    "I'd stomp desert dope heads for some gas in my moped!" - Bill the Cat   |
|              "What a stupid world" -Calvin (speaking to Hobbes)             |