Re: DSK format specification

[pausch@saaf.se (Paul Schlyter)]

In article <tqAQa.1678$dk4.84051@typhoon.sonic.net>,
Andy McFadden  <fadden@fadden.com> wrote:
 
> Paul Schlyter <pausch@saaf.se> wrote:
>> The structure and contents of the CP/M system tracks are indeed
>> completely implementation specific.  It doesn't even have to be 3
>> tracks: om the classic CP/M disk format (8" SSSD) the system tracks
>> were only 2 tracks; otoh each track on 8" SSSD disks contained more
>> than each track on an Apple II 5.25" disk.
> [... lots of stuff removed ...]
> 
> So it sounds like a program that processes disk images needs a set of
> DPBs, from which it chooses one based on the physical characteristics of
> the drive.  For the Apple II world there are separate DPBs for 13-sector
> and 16-sector disks.
 
Yes.  But in practice you can forget about the 13-sector CP/M disks
because they were rarely used.  Early versions of the Z80 Softcard
came with a 13-sector floppy (I still have it), but all subsequent
Apple II software I ever saw for sale came on only 16-sector disks.
 
>> Above the BIOS level, the file system area (i.e. everything except
>> the system tracks) on the disk are regarded just as a data area of
>> some specific size.  CP/M doesn't care where a new tracks start; that's
>> a business only for the BIOS.
> 
> CiderPress has to be the BIOS as well as the operating system, which is
> part of what makes all this so much fun. :-)
 
Otoh in a disk image there are no tracks and sectors either, only a
data area of some specific size.
 
>>> (Oddly enough, there is the equivalent of a "Beneath SSI RDOS".)
>>> There are some bit fields in the catalog entries that I still
>>> don't understand.
>>  
>> Consult the CP/M Alteration Guide in the CP/M manual:
>>  
>> http://www.cpm.z80.de/manuals/archive/index.htm
>> http://www.cpm.z80.de/manuals/archive/cpm22htm/index.htm
> 
> This one I have seen, but I couldn't find details of filesystem structure
> or directory layout in it.  It has command references, boot loaders, and
> what amounts to an RWTS system, but none of that helps much.
 
OK -- a directory entry has the following structure:
 
 1 byte     User number, or E5h if it's a free entry
11 bytes    Filename + extension: 8+3 characters
 2 bytes    Extent number of this entry
 2 bytes    Number of 128-byte records used in last alloc. block
16 bytes    Allocation map for this directory entry
 
A few comments:
 
Extent number: large files in CP/M receives several directory
entries, called "extents" - as many as needed to store the
full allocation map for the file.  On Apple CP/M (with 1K
allocation blocks and singe bytes in the allocation maps),
each directory extent is enough to define 16 Kbytes if the file.
Thus, any file larger than 16K will get more than one extent,
any file larger than 32K more than two extents etc.  If 2K
allocation blocks had been used instead, each allocation
map would define 32K of the file, etc.  The extent number
defines the order between the different directory entries with
the same name (e.g. MBASIC.COM on an Apple CP/M master diskette).
 
Number of 128-byte records used in last allocation blocks: the
CP/M file system defines the file length only in units of
128-byte "records" or "logical sectors".  Since an allocation
block usually contains several 128-byte records, this field
defines how many records are in use in the last block allocated
to that file.
 
Allocation map of directory entry: single bytes of the disk has
256 allocation blocks or less, double bytes (little endian order)
if the disk has more than 256 allocation blocks.  In the latter
case, each directory extent will only be able to map 8 allocation
blocks to the file.
 
Note that CP/M allows spares files -- these are marked by 00 in the
corresponding position in the allocation map and since allocation
block 00 always contains the directory, it cannot be a valid file
allocation.  Interestingly, the CP/M utility PIP fails to properly
copy a sparse file -- only the data up to the first "hole" in the
allocation map is copied.
 
>> http://home.tiscali.se/pausch/apple2/CPM.ref.txt
>> http://home.tiscali.se/pausch/apple2/Apple.CPM.ref.txt
> 
> The DPB info is useful.  Now, if somebody has a .NIB of a 13-sector CP/M
> disk, I can try to make that work...
 
Don't bother.... the 13-sector CP/M disks were almost never used.
 
Instead, try to make CiderPress able to also transfer files to CP/M
disk images - that would be immensely more useful.
 
-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://www.stjarnhimlen.se/
         http://home.tiscali.se/pausch/