🚀 go-pugleaf

I just finished using Teledisk in the attempt to copy the copy-protected
disks.  The analysis section of Teledisk told me some interesting stuff:

Apparently the scheme is to put "funny business" in track 39 past all of the
files.  The two descendents are indeed different from each other, and also
from the original.  I still don't know why COPYIIPC can't just make a
direct copy, but in any case I at least have a slight handle on what's being
attempted:

The Broderbund disk apparently has sectors 1-9 everywhere but on track 39.
On 39 you get something like most of 1-7 and then something like sector 222
and 242.  On side 2 of track 39 you get 1-8 and then 45.  Additionally,
45 is a 256 byte sector, not 512.  Further, all of the "funny" sectors have
a non-standard CRC in them so disk copiers will complain the data is
corrupted.  Since Teledisk can't copy bad sectors, it creates "good" ones
there and the copy-protection can't be thwarted.

When checking the two variant COPYIIPC-created descendents, they are both
subsets of the above, which I don't understand, and also they do have the
variant CRC property, thus perhaps this aspect of the copy protection has
been overcome.  But since it is also not a correct copy of the overall
sector scheme in either version, this is a likely reason why it doesn't
work either.  So, perhaps the COPYIIPC quirky message indicates that there
is a mis-recognition of just what's going on due to a bug, or just that
Broderbund has something nastier at work here.  (Maybe this is one of
those disks with a laser hole in it; they read differently every time as
part of the scheme; in which case there is no way to copy it; it has to
be patched to be brain-dead in this way instead.)

In any case, this points out further nice frills in Teledisk, since it can
be used to notice any format variations.  This helps to document how to make
DECmate and/or Rainbow variant RX50 formats correctly regarding stagger and
interleave zone issues.

As a consequence of the apparent mechanism in Teledisk, it does seem capable
of getting around certain forms of copy protection.  Potential candidates are
programs like PC Flight Simulator which are merely non-standard enough to
be distasteful to DISKCOPY and DISKCOMP.  Also any disk that isn't a
standard MS-DOS disk where the low-level format is compatible such as a CP/M
diskette or the backup disks from certain packages, etc.

If the data compression feature of Teledisk could be totally defeated, then
it would lend itself to data compression from other utilities.  This could
produce more desirable results since the two options are either essentially
quick and dirty or slow and thorough.  There are other packages available
that perhaps compress better in terms of either size (marginally) or speed.
Since data compression isn't a stagnant issue, Teledisk bucks that trend by
offering an arbitrary (albeit useful) compression method.  Further, since
compressed data can't be further compressed, this means that when you
attempt to archive these files with another utility such as LHARC or PKZIP,
there are some problems:

LHARC has no mechanism to turn off its compression mechanism.  Thus, when
using LHARC to archive Teledisk files, they invariably get larger in the
archive.  Thus Teledisk files are not an attractive candidate for archiving
using LHARC (from which the compression algorithm was acknowldegeably lifted
from).

PKZIP attempts to compress the file and invariably takes quite awhile in the
attempt because of the semi-random appearance of the already compressed data,
so it *eventually* gives up and does a straight store into the archive, but
this wastes some time.  There is a switch option to make it always just store
without a compression attempt, but then it applies to all files being added
at once.  The best workaround is to invoke the switch and add all Teledisk
files first, then do an unrestricted file add for the rest of the files in
the archive, etc.

cjl