[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: annc: GS/OS AppleDisk5.25 Project
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