Re: 5.25 Drive Nibbler Question

["Charlie" <charlied@NOSPAMbboard.com>]

"Bryan Parkoff" <BParkoff@satx.rr.com> wrote in message
Id2dnUf3nr1y4zKgXTWc3Q@News.GigaNews.Com">news:Id2dnUf3nr1y4zKgXTWc3Q@News.GigaNews.Com...
> 5.25 Drive Nibble Question
>
>     I understand that all copy-protected software and non-copy-protected
> software are stored in 4-4 encoded format.

No this is not true.  DOS 3.3 and ProDOS use 4-4 (also known as odd-even)
encoding only in the address field.  The data field uses a 6-2 encoding scheme.
The prologue and epilogue bytes are not encoded at all.
Copy-protected software may use whatever encoding the author wanted.

> Are they always 384 bytes

No, in any one sector there is:

Address field:
3 bytes --- prologue
2 bytes --- volume #
2 bytes --- track #
2 bytes --- sector #
2 bytes --- checksum
3 bytes --- epilogue

Data field:
3 bytes --- prologue
342 bytes - volume #
1 byte ---- checksum
3 bytes --- epilogue

363 bytes - total

There are also gaps between the fields but the number of bytes in the gaps can
vary.
The bytes in the gaps are often sync bytes (10 bit bytes).

> (normal 256 bytes) in the order of bit from the beginning through the end.
>     Does copy-protected software change the sector order within 256 bytes,
> but it never change 384 bytes?

Copy-protected software can do whatever the author wanted. There isn't a set
way to protect disks.  If there was it wouldn't be much protection.

> For example, GCR software is supposed to
> read 256 bytes on track 2 sector 5, but it only reads 128 bytes in one place
> and another 128 bytes in place such as half track or sector, but GCR
> software has ability to read all 384 bytes before it can become valid in 256
> bytes.
>     Do you know what I am talking about?

Not really.  ProDOS and DOS 3.3 read 342 data bytes from the disk and decode
them into 256 bytes of usable program code and data.

>
>     Is it true that Copy II Plus CAN COPY 384 bytes in nibbles from track 0
> sector 0 through track 22 sector 15 from the source to the destination, but
> without reading 384 bytes, it will not be possible to copy 256 bytes?

I'm not sure how Copy II Plus works, but if you mean that it reads the nibbles
and then writes them without first decoding them, I would imagine that is
correct.  If I remember correctly Copy II Plus reads a full track of nibbles at
once.  It then analyzes the nibbles and writes the full track to the
destination disk, synchronizing and maintaining the nibble count if necessary.

Charlie