[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hardware musings

mdj wrote:

Michael J. Mahon wrote:



In principle, but I'm not aware of any complete "catalog" of the
methods used, and often the same title was protected in different
ways in different "printings".



Well, the Copy II Plus database is a good start, and would cover the
majority of titles.


Actually, I think it may cover only the "most popular" titles,
and not the majority.  It's updating was very spotty, and often
new schemes on later releases of programs were not tracked.

Further, as I pointed out (elsewhere?) the Copy II Plus parms are
not the best way of getting at what is really important, since
culling out unnecessary steps was seldom done.


The problem is that only human intelligence can determine which way
a particular disk is *actually* used.

If you want to save a minimal amount of data, then you'll have to
manually determine--through extensive testing, since a failed copy
may not show up until later in a game--exactly what needs to be on
the disk (or image) to satisfy the program.

The only practical way to avoid this hard work is to save everything
that could *possibly* be used by a program, and that takes considerably
more space and time (to create).

If you want a "general purpose" tool, then I think the latter approach
is the only one that will work.  As I've said, I think that involves
saving every nibble readable on every quarter-track, together with
lists of all the "soft" bits on those tracks.



I agree in terms of creating the images, unfortunately you couldn't
transfer that data successfully back to a disk without knowing which
track positions were actually written, as writing to each quarter track
would trash its neighbours.


Right.


I suppose though, that the method would suffice for preservations sake,
and Copy II Plus data can be used to eliminate known spurious data for
the majority of titles. The rest could be done 'by hand' by those who
have the determination to do so.


The safe thing to do is capture everything, then rely upon later
experience with the program's behavior to "prune" any unneeded info.
Remember, it's easy to drop something, but impossible to get it back!

Or, maybe the community is now comfortable with much larger image files,
with huge hard disks, DVDs, and broadband connections...


The only automatic way I can see of getting around this would involve
sampling the read head directly in analog, and compare the signal
amplitude of adjacent tracks, but this would involve a hardware hack to
the drive and much more sophisticated software.


No matter what you "measure" about the characteristics of the disk, it
will still be mostly human judgement that decides what is "relevant".
(Though I still have some hope for an emulator that "observes" what the
protected program does with the disk, assuming that some human is able
to "drive" the program through all its states--solving the game, looking
in all rooms, picking up game pieces in every possible order....  Hmm,
sounds hard.  ;-)

-michael

NadaNet networking for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."