Extracting CDOS and CP/M) files

On Wed, 10 Oct 2007, Dave Dunfield wrote: 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): 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)! There are track(s) set aside for system and boot. Each DIRectory entry is 32 bytes. The first byte is "user number", 0 through 31, usually 0 - a crude substitute for subdirectories, from when disks were expensive, and multiple people might share a floppy :-). If that byte is E5, then that entry is unused or deleted. Bytes 1 through 8 are "filename", padded to right with 20h Bytes 9 through 0B are "extension", padded One of the bytes 0C through 0F (I forget which, sorry) is the "extent" number. 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. If you find alternating 00 and numbers, then it is normally a sixteen bit number. If a program is wrong about THAT, then it will think that block 0 is being crosslinked many times. 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. Later, with some more time, we can go back and clean this up to be readable. -- Grumpy Ol' Fred cisin at xenosoft.com