Re: Whole track writing code?

[Linards Ticmanis <ticmanis@gmx.de>]

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.

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

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

I think it probably won't -- see above.

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

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

--
Linards Ticmanis