Re: Zip Chip programming info / disk image?

["Michael J. Mahon" <mjmahon@aol.com>]

Linards Ticmanis wrote:
> Jorge Chamorro Bieling wrote:
>
> > > No... usually the loop runs forever, until data is there.
> >
> >
> > Is that what happens when you power it up without disk ? (keeps 
> > waiting there forever)
>
>
> Yes and no. It waits for D5 AA 96 to appear. If it doesn't, it'll just 
> run on and on and on. But...
>
> > But, if you boot and then remove the disk you'll get i/o errors..?
> > So somehow it quits instead of entering an endless loop.
>
>
> ....if the drive motor is running but there is no disk in the drive, 
> you'll read back random data. It's unlikely that the random data will 
> ever match D5 AA 96 unless you keep it running almost forever. But the 
> random data is enough to terminate the simple LDA ... BPL... loop that's 
> normally used to wait for a single byte.
>
> > I though a nibble image was the raw data, as read from the read
> > register:
> >
> > 0.- Turn on drive, move to a track, setup for reading
> > 1.- Is msb set in the read register ? if not set goto 1
> > 2.- Save this byte
> > 3.- been reading long enough ? if not long enough goto 1
> > 4.- You've read during more than a whole revolution of the disk, so
> > you've got all the data in this track.
> >
> > More or less, that's how I thought it worked.
>
>
> This is enough to get a NIB image for an emulator. A NIB image stores 
> bytewise data, as you'd read it back from the controller hardware. But 
> for a real nibble copy to a physical disk, you have the problem that the 
> data that's physically on the disk is a stream of bits, not a stream of 
> bytes.
>
> What a NIB image doesn't store is at what point in time you'd see each 
> byte arrive when reading the controller hardware. But this information 
> is needed to reconstruct the low-level stream of bits, as required for a 
> truly authentic nibble copy.
>
> The point is that the Apple uses "self-sync bytes" to allow the hardware 
> to find the beginning of bytes in the bitstream. Self-sync bytes are 
> bytes written at a slower speed than the usual 32 cycles per byte; 
> they're 36 or 40 cycles per byte. In the low-level format, they're 9 or 
> 10 bits long.
>
> There's not enough room on a disk track to make every byte a self-sync 
> byte in the copy, but on the other hand, if the self-sync bytes aren't 
> there in the right places, the copy won't work.
>
> Thus a nibble copier has to detect which bytes are self-sync bytes and 
> which aren't, and the only way to do this in software is to count the 
> number of cycles it takes for the next byte *after* them to arrive.

And, FWIW, the difference (4 cycles) is not enough to discriminate all
three possibilities (8, 9, or 10 bits) with certainty in a single loop.
Taking multiple latch samples in-line is helpful, but since the drive
data is not synchronous with the Apple clock, the determination is
tricky.

Self-sync need not even be done by writing nibbles longer than 8 bits,
since the only thing that matters is the bitstream, and *any* nibble can
be *written* to the disk.  When the bitstream is read back, of course,
each sampled nibble will have its high bit set, with any "leading
zeroes" skipped and following bits shifted in behind.

External hardware (like a shift register clocked at 2MHz) is a good way
to get all the information on the head bitstream, as EDD 4+ does.

-michael

Music synthesis for 8-bit Apple II's!
Home page:  http://members.aol.com/MJMahon/

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