Re: 1571 images as G64

On 2013-05-29, at 18:44, Pete Rittwage wrote:

>> If I understand correctly the specs of the G64 format, it should be
>> flexible enough to accommodate any (?) GCR based disk image data, even if
>> it is signed as "GCR-1541". If that is correct then the question is - has
>> anyone seen this being put into some use? Like GCR images of 1571 disks?
>> Or Apple ][ (?)
>> --
> 
> It's never been used for anything except single-sided Commodore disks, so
> anything else would be non-standard.  It would make much more sense to
> extend the header and make it G71 for 168-track double-sided disks to
> prevent confusion.  However, there are less 1571 disks that have copy
> protection and need GCR images than you can count on one hand, that I know
> of.

Pete, thank you for explanations. I haven't seen this format being used for 1571 (or other) either. But when reading the docs from "formats-20051127" [*] I understood that the file format could handle it, even without extending anything as number of tracks is a parameter in the header and then the data comes as GCR streams, plus it allows for speed-"zone" variations even on a per byte basis.

> As for Apple, the specs aren't made for that. Technically, their GCR is
> different than CBM- there is only one density, and the way the data is
> constructed on the disk vs. what is read is odd (no sync marks per se,
> every byte is a sync) AND they can have quarter-tracks.

That's interesting ;-) So they used 80-track mechanism to access 20 tracks or what?

But this should not break the format either, should it? One speed is fine and whatever is the structure of the GCR data should not be relevant either if only the GCR bits (read with proper speed) are stored. Or am I missing something?


* - I don't remember where I got this set from and a quick google didn't return anything useful, but I am wondering who was maintaining this set of very good docs and whom send some updates (typos corrections and co.)? Or maybe there is a newer set that I haven't seen yet.

-- 
SD!
       Message was sent through the cbm-hackers mailing list