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

Re: Whole track writing code?



Linards Ticmanis wrote:
Michael J. Mahon wrote:

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.


Ok, I thought maybe my logic wasn't up to this... but since I know that the game I'm talking about was advertized as working on 13- *and* 16-sector controllers, I'm sort of convinced it uses only 36-cycle syncs, except possibly in the single 16-sector (boot) block to be found in track 0.

And that wouldn't matter, since *any* sufficiently long (>6) string
of sync nibbles will do the job, for either controller.

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.


That should be easy enough to find out - the disk changes around the sector header's first and third byte a lot, but the "aa" 2nd byte is always there.

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


Given that the game runs very well off a .nib image, neither of these should apply, since .nib can't represent them anyways.

True.  A very restricted set of images helps a lot.  ;-)

<snip>

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.


I see... but eight sync bytes in a row should always be enough to sync up reliably, shouldn't they?

Correct.

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