[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Zip Chip programming info / disk image?



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.

--
Linards Ticmanis