Re: Why won't the Unidisk 3.5 work with . . .

[dempson@atlantis.actrix.gen.nz (David Empson)]

In article <hy7d5qL.rogtha@delphi.com>,  <rogtha@delphi.com> wrote:
> Why won't the Unidisk 3.5 work with the 3.5 Bit Copy on Copy II Plus?

Because bit copying requires direct access to the data on the disk.

The UniDisk 3.5 has its own microprocessor, and data is transferred to
and from the drive in formatted packets containing one disk block.
The microprocessor within the drive accesses the disk.

The computer cannot directly access the raw data on the disk (it can
with an Apple 3.5 Drive connected to the Universal Disk Controller or
IIgs disk port; I'm not sure about the IIc+; the SuperDrive card also
isolates the computer from the raw disk data).

The only way Copy II+ could do a bit copy with a UniDisk 3.5 would be
to download code into the memory of the drive's microprocessor to do a
direct track read.  Unfortunately, it can't do this, because the
UniDisk doesn't have enough memory to hold an entire raw track dump.

This is actually a design feature - UniDisk programming documentation
talks about how the limited memory and code download capabilities are
good for copy protection engineers, who can defeat bit copy programs
by downloading simple modifications to the disk structure into the
UniDisk.  This is no longer the case, now that the Apple 3.5 Drive is
available, since any disk written on a UniDisk 3.5 can be read on an
Apple 3.5 Drive and vice versa.  What is more, Apple no longer does
anything to encourage copy protection.
-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand