Re: annc: GS/OS AppleDisk5.25 Project

[Steven Hirsch <snhirsch@gmail.com>]

Andy McFadden wrote:
> In comp.sys.apple2 Toinet <antoine.vignau@laposte.net> wrote:
> > My understanding is:
> > - standard GCR encoded disk
> > - 35 tracks / 16 sectors with a specific interleave
> > - a block is a set of 4 sectors
> > - a block is 1024 bytes long
> > - block number 0 starts on track 3, sector 0
> > - blocks 80 to 8F are reserved for cp/m (tracks 0 to 2)
> > - two blocks reserved for the directory (blocks 0 and 1)
> > - a deleted file entry holds $E5 at offset 0
> > - there are no load address nor file length
> > - file length can be determined by the number of blocks)
> >
> > If I understand correctly, the rc byte (offset +F) holds the number of
> > 128-byte records in a file. I would have thought it held the number of
> > 1024-byte blocks. Am I wrong?
>
> Source code for the CP/M disk reader in CiderPress:
>
>   http://ciderpress.cvs.sourceforge.net/viewvc/ciderpress/CiderPress/diskimg/CPM.cpp?revision=1.1.1.1&view=markup
>
> We discovered that, on some Microsoft Softcard, disks, blocks 80-8f can be
> used to hold data.

Yup, the BIOS automagically wraps those around to tracks 0,1 and 2.  Microsoft 
refers to this as a "data only" diskette.  There are options to the system 
utilities for creating the format.

I don't remember all the details, but I think disks with system tracks create 
a dummy file to make those overflow sectors look like they're being used by a 
file (to prevent the OS from being scribbled over).