Commodore Free 6/Commodore_Free_Issue_06_2007_Commodore_Computer_Club.d64/t.pres.2

Text File | 2007-01-01 | 14.3 KB | 435 lines

u
    Commodore Preservation Project
      http://rittwage.com/c64pp

Part 2

Drive Internals The drive head, at
it's lowest level, can only detect and
create polarity changes in the
magnetic flux on the surface of the
disk, which is interpreted by the
drive as a binary 0 (no change) or a 1
(flux polarity change). Because of the
specifics of the hardware used to
access this magnetic flux, the bits
stored on the disk have a couple of
limitations (or "features"). This flux
detection circuit feeds dual 4-bit
"shifters" which convert the bits
(detected from the flux changes) into
a whole byte (8 bits), much like a
serial port does. If this circuit
detects ten '1' bits in a row, it
knows that it has read a "sync". This
sync is what tells the software that
it's about to get a series of bytes
representing either a sector header or
sector data right after the sync ends.
An anomaly of this circuit is that it
if it runs across three or more '0'
bits in a row, it will clock in an
extra '1' bit on each 4-bit shifter
that doesn't really exist on the disk.
When this happens, the track loses
framing, meaning the data is
bitshifted after this due to our new
phantom bit. It will shift a new
phantom '1' into the LSB once in a
while (and wrap it around) according
to drive speed and other environmental
factors until the next real '1' bit is
seen. This data is "random" in the
sense that the data is never the same
twice due to drive speed (and
humidity, temperature) fluctuations. A
good example is when you try to read a
new, unformatted disk. If you try
this, you'll get "random" data caused
by this anomaly in the drive hardware
because there are no flux changes on a
blank disk. To the 1541 hardware, this
is all '0' bits. Because of this
weakness of the hardware, all data is
stored on the disk in an encoding
system called "GCR". This encoding
assures that there will never be more
than two '0' or '1' bits in a row in
the data itself. This "feature" of the
'0' bits is of course taken advantage
of in some later copy protection
schemes. (Rapidlok, Mindscape, and
Datasoft, for example) ;)

Differences between a "fast copier"
and a "nibbler" Copy programs have
been referred to by these two
different types since the first
nibblers came out on the Apple II. A
little more background is required in
how the disk is structured to explain
the difference. A track is broken up
into a number or sectors, which are
further broken up into a header and
data portion, and each of these has a
filler "gap" at the end to give the
drive software time to change modes.
The actual GCR data is structured like
this:  SYNC (at least 10 bits of '1'
in a row)  header0 (8 bytes in DOS)
header gap (usually 5 filler bytes,
longer for nibbled copies) SYNC
sector data 0 (CBM DOS uses 260 bytes)
 tail gap (usually 5 filler bytes,
longer for nibbled copies) SYNC
header1... (and on until the end of
the track)

Fast copiers A "fast copier" reads the
source disk on a sector-by-sector,
normal CBM DOS level, and recreates
them onto a new formatted disk. This
method produces a "clean" copy of the
disk, but does not copy any protection
since it will ignore any sectors with
errors, or any sectors that don't
conform to the format explained above.
It was really only used when we
weren't going to try to copy the disk
protection, but rather apply a
"parameter" to the disk. A "parameter"
is nothing more than a patch program
that was run on the backup disk to
remove the check for copy protection.
Fast Hack'em, Kracker Jax, and later
Maverick were all very popular copy
programs that utilized parameters.

Nibblers A "nibbler" works at a lower
level and will duplicate the actual
headers and data, whether or not they
are in CBM DOS format. It does have
limitations, though. First, they don't
duplicate the header or tail gaps or
the original sync length, but rather
creates it's own, so protections that
hide in the gaps or count sync lengths
won't be duplicated. Secondly, the
drive only only has 2k of RAM, but a
whole track is up to 8k, so it must be
broken down and read in several
passes, then stitched together on the
destination disk. Protections that
exploited this would use a sector or
track larger than would fit in RAM at
once, making it impossible to copy.
Later, there were hardware solutions
to this, such as extra drive RAM and
parallel ports.

Protection Methods Intentional Disk
Errors This protection consists of a
disk error purposefully placed on a
sector or an entire track, then it's
existence is checked for in the
program. If the error isn't found,
it's knows it's a copy. In the
beginning, there were no copy programs
except Jim Butterfield's "COPY/ALL"
that came on the 1541 test/demo disk.
This program could not reproduce these
errors (and even if it could, it took
*FOREVER* to copy even regular disks).
Like most protection, though, it only
foiled casual copiers. Early, clever
crackers figured out how to scan an
original disk for these and the
methods for recreating the errors were
not difficult. Soon after, programs
like "Copy II/64" came out that could
effortlessly detect and reproduce
these errors which marked the end of
this era. Most publishers of disk
software used this method before late
1984.

Fat Tracks This protection involves
placing a track on the disk that is
actually 2 tracks (4 half-tracks)
wide. This has two effects.

1) The second track is invalid
because Commodore DOS stores the
track number as part of the track
header, which is now for the wrong
(previous) track.

2) The tracks are perfectly aligned
on the disk since they were written
at the same time.

The protection is checked by the
program by stepping the head up and
down between these 2 tracks and the
halftrack between them while reading
the whole time. Normally, a half-track
will contain a garbled combination of
it's neighboring tracks. However,
since these two tracks are now
identical, this track should contain
the same data as both of it's
neighbors. If it doesn't, it knows
it's a copy. Electronic Arts used this
protection from about 1984-1985 and
Activision used a tougher variant of
it called "XEMAG 2.0" for many years.
These protections stand out from most
of the early protections because they
could *not* be copied 100% reliably
even with *any* nibbler. As mentioned
earlier, the 1541 has no way to know
where it is on a track. Therefore, it
has no way to know where it is in
comparison to any other tracks on the
disk. For this reason, it is
impossible to reliably write these
tracks out perfectly aligned with a
1541 drive. This was an idea that was
greatly expanded on in future
protections, but it still stands the
test of time and still can't be
duplicated reliably with the best
copiers that ever existed. It is of
note that it *is* possible to
"unreliably" copy these, as you can
just try over and over again copying
just these two tracks until you happen
upon "close enough" alignment for it
to work. The EA protection in
particular relies less on the exact
track alignment, so it is less
difficult to copy this way. NOTE:
Slowing your disk drive motor down to
298.5rpm or less seems to allow you
to load a copy of any fat-track
protected disk remastered with MNIB.

Half Tracks Along the same vein as
fat-tracks, it was of course possible
to read and write to the usually
skipped "half-tracks" instead of the
normal tracks, if you weren't worried
about storing any data on the normal
tracks. This foiled many copiers
because they didn't search for and
copy these half-tracks by default, so
they instead got garbled, invalid
mixes of the "real" data when trying
to read the tracks as if they were
normal. Copiers later came out that
could scan for and detect these and
copy them properly. I have not yet run
into any disks which are known to
use halftracks.

Extra Tracks This protection simply
relies on using disk tracks beyond 35.
Normally, copy programs default to
copying only tracks 1-35, so these are
missed. I am not sure why the
programmers didn't extend this by
default, except maybe some would lock
up reading unformatted tracks, which
these tracks usually are. Sometimes
these tracks contained actual
DOS-formatted data, but usually they
were just "key" tracks, or the second
part of a "fat" track from track 35.
They could sometimes be nibbled, other
times they could not, because they
were combined with other protections.

Changed Bitrates As mentioned above,
the bitrate is normally higher on the
outer tracks and lower on the inner
tracks. Some disks were protected by
using a non-standard bitrate on
different tracks. Copiers later came
out that would scan for the correct
density and these disks could be
copied that way.

Header and Tail Gaps As mentioned
above, when a disk is copied with
either a fast copier or a nibbler, the
gap data is not copied directly.
Copiers would commonly just fill this
space with 0x55 bytes. Gaps are
"inert" bytes, meaning they aren't
normally used as data, but just a
space filler that is ignored by DOS.
There are some protections that check
for specific bytes here, or even the
length of the gaps, and know they're a
copy if it's different. This
protection can be copied with hardware
solutions that either extend the RAM
in the drive to 8k or add a parallel
port so it can read and write the
entire track in one pass.

Long Sectors As mentioned above, the
drive has only 2k and can't fit an
entire track in RAM, so it must be
broken down into 4 parts and stitched
together on the destination disk. If
you make a sector longer than will fit
in RAM, it can't be copied with a
normal 1541. This can be copied with
hardware solutions that either extend
the RAM in the drive to 8k or add a
parallel port so it can read and
write the entire track in one pass.

Custom Formats These usually depend
on the long sectors trick above to be
successful, but they also entail
changing the way that GCR is
interpreted in a custom DOS. If you
write your own DOS, you can use your
own disk format entirely, ignoring
common sync, gap, header, and data
conventions altogether and use
whatever you want. You only have to
adhere to the hardware limitations of
sync and no more than two '0' bits in
a row, but even that didn't stop later
innovations. :)

Long Tracks Normal drives spin at
{$fe}300rpm and can "write" data at the
highest density up to about 7700 bytes
per disk track. However, the drive can
"read" more than that, within some
margin of error depending on motor
speed. Some protection took advantage
of this and put more data on the track
than could be written back out at the
normal speed, making it difficult to
copy. Some copiers would "trim" the
data in as non-destructive way as
possble (reducing sync length and
gaps) and it was also possible to slow
down the disk drive to foil this, but
usually these disk relied on a
combination of other protections as
well. A good example of this is Harald
Seeley's "V-MAX!".

Sync Counting A sync mark must be at
least ten'1' bits long to signal the
drive hardware that it's about to see
GCR data. However, sync marks are
usally much longer than this (40 bits)
and have no limit to their length.
When copying a disk with a software
nibbler, sync has to be reproduced
rather than copied, since it is more
like a "signal" than actual data
stored on the disk exactly. For this
reason, the length of a sync is also
somewhat dependent on drive speed and
will vary a little. Some protections
count on this and measure the lengths
of the sync, or the occurances of sync
on a track, to see if they match, and
know they're a copy if they don't.
Microprose used this method on some
disks, and in fact "trimming" the sync
will fail the protection checks. Track
Synchronization We mentioned above
that the drive doesn't use the index
hole, so lining up the tracks on the
disk is nearly impossible on the 1541.
Since disks weren't usually mastered
with a 1541, but rather with machines
that could do track sync based on the
index hole, protections took advantage
of this in different ways. They would
move to a halftrack or the next track
in the middle of reading to see if the
data that should be there exists. If
it doesn't, it knows it's a copy.

Weak Bits/Unformatted We mentioned
before that if the drive gets more
than two '0' bits in a row, it clocks
in a random '1' bit occasionally.
Single occurances of this sequence
won't always make it lose framing, it
will return a "random" byte, but more
than a couple in a row will result in
the drive losing framing and reading
these "random" bytes until it sees the
next real '1' bit. Most nibblers can't
duplicate this, so protections checked
a byte purposefully on the disk
somewhere and if it reads the same
thing over and over, it knows it's a
copy. Later copy programs did try to
reproduce this-- Burst Nibbler detects
and writes a 0x01 byte in their place,
which is enough to fool most software
into working. It is also worth noting
that this is the same thing as
unformatted tracks, so you'll see this
a lot when imaging in new disks. Since
the disks aren't usually duplicated on
a 1541, and the tracks aren't always
as long as they could be, the machine
leaves unformatted data on the end of
all the tracks, causing a lot of
software to appear to have these on
every track, and making it difficult
to verify the tracks from disk to
disk, since the bytes will be
different from sample to sample. I
have several disks from Synapse that
have unformatted parts on all the
tracks, and none of the tracks above
25 are formatted at all! I've seen
this used in Rapidlok (all titles),
later Microprose disks, and Datasoft
(Bruce Lee, The Goonies, Mr. Do!)

Signature (key) Tracks This protection
is seen from time to time and revolves
around a track being mastered in a
non-standard way. It can be all sync
'1' bits (which we call a
'sync-killer' track), unformatted (or
all '0' bits), filled completely with
some other byte, or filled a special
byte sequence like EA's PirateSlayer,
or a combination of all of them. These
tracks generally foil most all copy
programs because they either cannot
handle all or long sequences of '1' or
all '0' bits, or they are just read
incorrectly/out of framing. We can
remaster most all of these with our
development version of 'mnib'. ;)

No SYNC The meanest protection that
came about used tracks on the disk
that had *no* sync marks. Most copiers
cannot read these tracks and most
times think they're empty. The later
Vorpal uses this. We believe there is
a way to find the track cycle in these
and reproduce them, as Maverick had
custom copiers for these titles. It
needs disassembled and examined.

...end..