Re: Zip Chip programming info / disk image?

[bieling@terra.es (Jorge Chamorro Bieling)]

Linards Ticmanis <ticmanis@gmx.de> 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 see... although it is an endless loop it won't lock because sooner or
later the msb is going to be set, by the data in a disk or by noise if
there's not a disk in the drive.

Then, I guess, if it was not because of the head stepper, a zipchip (or
anyother accelerator) at full speed could probably use a Disk II for
*reading* without any (timing) problems... right ?

> > 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.

Isn't that called bit-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.

Great explanation, really. Thanks. I'd have to understand the disk II
sequencer...