| Nibble copy is a low-level copy technique, that copies raw data from
one floppy to another. It was used to defeat copy protection on Apple
II systems, which sometimes used non-standard nibbles to represent
data. Copiers would convert to standard nibbles, and the program would
check for the non-standard values.
It's been a long time since I used an Apple II, but here is a made-up
example. The rules of recording data on floppies say you cannot have
too many transitions too close together (because you would exceed the
media's bandwidth, and thus get unreliable results) so in the serial
data from a floppy, you can have two or three 0 bits in a row, followed
by two or three 1 bits, but you cannot have the sequence 010, for
example. So, the allowable values are:
00110011..., 000111000111..., 001110011100111..., etc.
Given this restriction we can derive a binary data stream by saying
that 00 and 11 means binary 0, and 000 and 111 means binary 1. Thus,
to encode a 0 we emit two bits, and to encode a 1 we emit three bits.
It doesn't matter what bits we emit, just so they're of the opposite
polarity as the previous bits. For example, to encode 0100, we would
emit 001110011.
This is a pretty ugly system, since it doesn't use the available
bandwidth very ,effectively, and the number of bits it writes on a track
depends on the data values. However, it's just an example, intended to
illustrate the principle. A real system would use a cleverer
technique, but the idea remains the same.
Now consider a program that wants to do copy protection. It knows that
the software that reads from the controller will be looking for
sequences of two and three bits to determine binary values, and it
knows that the writing software always starts a track with a 0, but
that the read software doesn't care what value you start with. So,
to verify that it is running on its original disk, it encodes the data
on the disk starting with 11 or 111 rather than 00 or 000. After it
starts up, it reads the raw data from the disk and checks the first
bit. If that bit is 0, the disk was written by a copier.
A nibble copier doesn't copy binary data (thus writing standard
nibbles) but does raw reads and writes, thus copying the nibbles
directly. A program that checks for non-standard nibbles will thus see
them.
On your second point, I just used Workbench to copy my Falcon disks.
They don't appear to be copy-protected at all.
John Sauter
|
|
That's correct, FALCON is protected via code wheel only. I
understand there is a file called nib.arc that breaks the code
protection of FALCON. If you use the wrong codes your plane will
work only for a little while, and then crash. I don't know how
effective the nib.arc utility is... it may do more damage than good.
Does anyone know? I have FALCON, and I'll tell ya the code wheel
stinks! Sometimes I can't determine which symbols it wants me to
align...
M. Gaines
|
| To my knowledge all the U.S. versions of Falcon use the code wheel for
copy protection. I have used the NIB parameter copy to disable the
code wheel protection, and it works great for me. I have the new
version and mission disk on order, I am looking forward to running
from my hard disk.
I think I reported this in a previous note, but when I bought Falcon,
the boot disk had the SCA virus on it. There was no doubt that it
arrived with the virus, because I tested it with VIRUSX before I played
it. I would expect that they have corrected this, but I still plan to
test the upgrade when I get it.
|