Extracting CDOS and CP/M) files

Dave Dunfield dave06a at dunfield.com
Thu Oct 11 06:27:50 CDT 2007


> I can't immediately find one to point you to, so here is an off the top of
> my head rundown of the CP/M DIRectory structure (which may be completely
> indecipherable without illustrations or more careful wording):

Fred, thanks for the useful info.
 
> CDOS had one or more bytes in the first physical sector of the disk to
> identify which format.  There ARE multiple (user modifications?) variant
> formats that may have the same ID byte(s)!

Anyone have more info on this? - One of my main problems is determining
exactly what format these disks are in.  

> The remaining sixteen bytes, 10h through 1Fh contain a list of blocks
> occupied by the file.  That can be up to sixteen 8 bit entries, OR up to 8
> sixteen bit entries, OR even four sixteen bit entries. Depending on
> how many records per block there are, there might be more than one
> "extent" represented within that block list.  Unused block
> numbers in the list are set to 00.  Once the list is full, then the OS
> starts an additional DIRectory entry with a larger "extent" number.

Does each entry represent a cluster? The CDOS manual does have tables
relating physical sectors to clusters, which can be represented with an
8-bit value. These are listed for "large disks" and "small disks", although
it's not clear where a DSDD 5.25" disk fits (it's large for a 5.25,
small compared to 8") - I'm guessing the "small disks" means any 5.25,
but I'd love to be corrected if anyone knows differently.
 

> If the last 8 or 12 bytes are all 00, then either it is a short file, or
> that  particular variant is using an 8 byte, rather than sixteen byte long list.
> (and not putting more than one extent in the block list)
> Obviously, the number of records (128 byte "sectors") per block makes a
> difference in whether the block numbers will be 8 or sixteen bits.

Is there any information recorded on the disk which will indicate the size
of a cluster?  Or the logical interleave?  Or are these quantities that the
OS "just knows"?

Dave

--
dave06a (at)    Dave Dunfield
dunfield (dot)  Firmware development services & tools: www.dunfield.com
com             Collector of vintage computing equipment:
                http://www.classiccmp.org/dunfield/index.html



More information about the cctech mailing list