Re: DSK to NIB Instruction

[russotto@grace.speakeasy.net (Matthew Russotto)]

In article <434fd743$0$10235$9b4e6d93@newsread2.arcor-online.net>,
Linards Ticmanis  <ticmanis@gmx.de> wrote:
>
>Actually judging by the source code, most emulators seem to "nibblize" 
>the .dsk image internally and then feed it to the emulated controller.

Some trap RWTS calls instead, but that's obviously less compatible.

>I don't have any literature available on low-level disk operation. Do I 
>get this right:
>
>1.) the .nib format stores bytes in the same format that the Apple's CPU 
>sees when accessing the drive controller card (disregarding the .nib 
>overlap).

Pretty close, anyway.

>2.) this is not the format that is actually stored on the disk.

Right.

>3.) the purpose of sync bytes is: to tell where in the bitstream a byte 
>starts, so you don't get half of one byte and half of the next. So when 
>reading a disk on the Apple, you throw away what you read while waiting 
>for a sync byte, which will be aligned correctly, then the bytes after 
>that will also be aligned correctly, so you can use them.

Not quite.  All nybbles start with a 1 bit.  So you throw away 0 bits
at the beginning of a nybble.  You can start reading in the middle of
a byte and continue for a while doing so, but once you come upon a
certain number of self-sync nybbles in a row, you're guaranteed to be aligned

>4.) sync bytes are stored with some extra bits in front of the normal 
>bit pattern. These extra bits are not directly visible to the Apple's 
>CPU, only to the controller card itself.

They're at the end, and they're 0 bits.

>5.) when reading from a disk, there's a way to ask the controller 
>whether you've got a sync byte or not.

There's no easy way.  This fact is the basis of many a copy protection scheme.

>6.) when writing to a disk, there's a way to tell the controller to 
>write either a sync byte or a normal byte.

Yes.  Basically you just take longer between nybbles, allowing the
controller to write zeros at the end of your nybble.

>My point was actually not emulation, but making use of the large library 
>of already existing .nib images on a real Apple.

You'd have to analyze the track the way a nybble copier does, to
determine (heuristically) which bytes were the self-sync bytes and
where the true ends of the track were.  Then you could write the track
out to disk. Possibly you could modify an existing nybble copy program
to do it.