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

Re: Whole track writing code?

Linards Ticmanis wrote:
First, I'd like to thank very much all people who answered; the code in "Beneath Apple ProDOS" is indeed very clear and ideal for this use. And luckily the DOS RWTS has a relatively straightforward path of execution, so it's also not that hard to understand. 

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? 

You are correct, for the encoding suggested to work, all 36-cycle
nibbles must have a low bit of one (which they do on standard disks).

Or, if you know all the sync nibbles to be 36-cycle, then you could
ignore the possibility of 40-cycle nibbles and just use the high bit
encoding.


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. 

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

Yes, it's a pretty usable trick--and equally applicable to a track
read routine.
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. 

Actually, any gap preceding an address field will work, though the
FORMAT convention is to have the variable-sided gap precede the
sector 0 address field.

The intent to represent potentially copy-protected disks complicates
things considerably, particularly with respect to nibble counting and
track synchronization (not even considering fractional tracking).
(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.) 

In that case, you may want to research just what copy protection
scheme is used, since nibble counting may well play a role.


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? 

The disk controller syncs up faster on 40-cycle nibbles, since the
"bit slip" is two bits per nibble.  This allows slightly shorter
sync fields, but the overall effect is negligible.

The use of 40-cycle sync nibbles was permitted by the new "16-sector"
state machine, since two consecutive zeroes were then allowed.

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