Toinet wrote:
> Thank you All,
> 
> The following address summarizes all the necessary information, I
> believe. Can you please validate that it is correct?
http://www.dcast.vbox.co.uk/cpm.html
> 
> I like the usage of the eighth bit on the three extension letters!
> 
> My understanding is:
> - standard GCR encoded disk
> - 35 tracks / 16 sectors with a specific interleave

Yes

> - a block is a set of 4 sectors
> - a block is 1024 bytes long

It depends, although this sounds correct for Apple CP/M

> - block number 0 starts on track 3, sector 0
> - blocks 80 to 8F are reserved for cp/m (tracks 0 to 2)

For the majority of cases, yes.  Some of the Microsoft Softcard CP/M systems 
recognize a so-called "data disk" mode that wraps around from
track 34 to use 
0, 1 and 2 as additional data storage.  There is some trickery involving a 
fake directory entry to flag this situation, but I don't remember all the details.

> - two blocks reserved for the directory (blocks 0 and 1)

Correct, but specific for the Apple implementation

> - a deleted file entry holds $E5 at offset 0
> - there are no load address nor file length

Load address or other handling (batch file invocation) is implicit, based 
(usually) on the type of the file as determined by the extension.

> - file length can be determined by the number of blocks)

All true as far as I know.  Files are always modulo 128 in size.  Text files 
are terminated with ^Z to indicate the actual end of data, but the sector is 
padded with junk as required to even out the size.

> 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?

I don't remember this level of detail any more, but here is a good, concise 
explanation of the CP/M directory and disk structure:

http://manpages.ubuntu.com/manpages/feisty/man5/cpm.html

Steve
--- SBBSecho 2.12-Win32