On Wed, May 29, 2013 3:23 pm, email@example.com wrote: > > 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? > Certainly you "could" do it. I figured by the name of the extension and the intro to the document, that it was always just designed as an alternate/extension to the D64 format. Calling it "G64" when used for 1571 or certainly Apple images makes less sense. You could use the same format, though, just with a different signature. GCR-1571, GCR-APL2, or whatever. In the Apple emulation world, they use "NIB" for raw files, which is unrelated to NIB from mnib/nibtools. On the Apple disk drive, they basically ripped out the Shugart board and made a simple circuit controlled by software, so you have direct software control over the actual field coils which move the heads. While their "official" DOS only uses 35 tracks (0-34) like CBM, it is possible to manipulate the heads to move not only 1/2 way in between tracks, but also 1/4. It is still a wide head like the 1541, though, so it will destroy data for 1.5 tracks when you write. - Pete Rittwage C64 Preservation Project Message was sent through the cbm-hackers mailing listReceived on 2013-05-29 23:00:03
Archive generated by hypermail 2.2.0.