Michael J. Mahon wrote:
Look at the "Format" utility in Appendix A. Note that if you want to write a track which you've read in yourself, you'll have to detect auto-sync nibbles. The Format utility uses #$80 to represent these.Since you are writing out a track image that was read from a disk, you may also want to preserve the actual values of the sync nibbles. A good representation of sync nibbles is the actual read value with the high bit turned off (since it is always on).
Actually, I think that's what Nick meant, "eor #$80"; the Format utility in the book uses the high bit for exactly the purpose you describe.
If you need to represent both 36-cycle and 40-cycle sync nibbles, you can turn off the high bit for 36-cycle nibbles and turn off both the high bit and the low bit for 40-cycle nibbles. Stephen Thomas suggested this representation to me, since the low bit of any 40-cycle nibble must be 1 to avoid violating the "no more than two consecutive zeroes" rule for the disk controller.
a.) I guess that means that on 13-sector disks all the sync nibbles are always 36-cycle and have to end in a "1"?
b.) given the representation you suggest, how do you represent a 36-cycle nibble with a low bit of "0"? Or am I missing something here?
The track write routine is pretty simple, since its just a matter of preserving 32-, 36-, or 40-cycle timing while looping through the stored nibble image. Of course, the writing of the actual image must be preceded by writing a sufficiently large number of sync nibbles to ensure overlap.
Sure... but you can just add these to the front of the data to be written, and then write it all in one go. I assume $1C00 nibbles should be enough for any drive, given that $18EA is the number of non-sync nibbles that fit if the drive has the right speed.
And yes, the code in the book is indeed rather simple, simpler than I expected; obviously when you don't do any encoding or decoding on-the-fly, it's pretty easy to get the cycle counts right. The only small drawback is the fact that the last byte to be written always has to be at $7FFF, since the code uses a BPL on the high byte to decide whether it's got to do another loop. But actually $7FFF sounds like a good place, it's out of the way of all other important things.
Now I "only" have to code something that makes educated guesses about which bytes in .nib files are sync bytes (too bad .nib files don't use the representation you described above - but I think no emulator at present really emulates the Woz machine anyway), which bytes are overlap, and where in a track there is an expandable or shrinkable gap to start and end the track.
(BTW I'm not coding a nibble ADT, just something to build some standard .dsk images on the PC which when run on a real apple can rebuild a non-standard Disk. The only "real" (well, not *that* real) purpose ATM is to get the nibble images of the old "Ultima I" version to run on the real hardware since I don't like the cracked version.)
If you know that only one timing of sync nibbles is used, then it's even simpler.
For those programs that can run from .nib images it obviously doesn't matter, so one might as well use only 36-cycle syncs. Or is there any drawback to 36-cycle sync nibbles? Does the drive sync faster on 40-cycle nibbles, for example?
-- Linards