Re: DSK format specification

[pausch@saaf.se (Paul Schlyter)]

In article <hcEQa.1743$dk4.87984@typhoon.sonic.net>,
Andy McFadden  <fadden@fadden.com> wrote:
 
> The part I couldn't figure out is the part you labeled "number of
> 128-byte records used".  The values I'm finding don't quite match up
> with what you show.
 
OK, it appears the book I looked this up in (Andy Johnson-Laird's
"The Programmer's CP/M Handbook") wasn't quite accurate here.  That
book probably defines the contents of the FCB instead (which is more
or less a mirror of the first 16 bytes of the directory entry;
however there are some differences).  FCB = File Control Block, a
data area the application provides to CP/M when dealing with files:
you fill in the filename when opening the file, and give a pointer to
the FCB to CP/M, and then CP/M uses that area as a "scratchpad" for
its file operations.  This is vaguely corresponding to the "buffers"
in Apple DOS, with the difference that the application, not the OS,
provides space for these buffers (a separate buffer must also be
provided for the data read from and written to the files).  This had
the disadvantage of more trouble for the application, but also had
the advantage that there was no limit of concurrently open files in
CP/M, since the application could provide as many FCB's and buffers
as it needed.  All within the 64K limit of RAM for the application
plus CP/M itself, of course.....
 
 
I did a Google search for "CP/M directory entry", and found a site
with info which agrees with your findings:
 
http://www.seasip.demon.co.uk/Cpm/format22.html
Describes the format of CP/M 2.2 disks
 
http://www.seasip.demon.co.uk/Cpm/formats.html
Has links to similar descriptions of CP/M 1.4, CP/M 3 and CP/M 4.
Ver 1.4 and 4 were never used on the Apple II, and ver 3 was
rarely used (by "The CP/M Card", which had its own 64K RAM _and_
used Apple's RAM, which that card could access from the Z80 as well,
by bank switching.  CP/M 3 could use more than 64K of RAM, through
bank switching, and put the CCP, BDOS and part of BIOS in the other
memory bank if available).
 
http://www.seasip.demon.co.uk/Cpm/
Look under "Technical information" here.....
 
On http://www.seasip.demon.co.uk/Cpm/format22.html
you can find this info (note: exm=0 on all Apple II CP/M floppies,
including my own 80-track double-sided 640K Apple II CP/M floppies):
--------------------------------------------------------------------
CP/M 2.2 directory
The CP/M 2.2 directory has only one type of entry: 
 
UU F1 F2 F3 F4 F5 F6 F7 F8 T1 T2 T3 EX S1 S2 RC   .FILENAMETYP....
AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL   ................
 
UU = User number. 0-15 (on some systems, 0-31). The user number allows
     multiple files of the same name to coexist on the disc. 
     User number = 0E5h => File deleted
Fn - filename
Tn - filetype. The characters used for these are 7-bit ASCII.
       The top bit of T1 (often referred to as T1') is set if the file is 
       read-only.
       T2' is set if the file is a system file (this corresponds to "hidden"
       on other systems). 
EX = Extent counter, low byte - takes values from 0-31
S2 = Extent counter, high byte.
 
      An extent is the portion of a file controlled by one directory entry.
    If a file takes up more blocks than can be listed in one directory entry,
    it is given multiple entries, distinguished by their EX and S2 bytes. The
    formula is: Entry number = ((32*S2)+EX) / (exm+1) where exm is the 
    extent mask value from the Disc Parameter Block.
    (my note: on Apple II, exm=0)
 
S1 - reserved, set to 0.
RC - Number of records (1 record=128 bytes) used in this extent, low byte.
    The total number of records used in this extent is
 
    (EX & exm) * 128 + RC
 
    (my note: since exm=0 on Apple II, this will always be equal to RC.
     exm will be different from 0 only on large disks such as harddisks)
 
    If RC is 80h, this extent is full and there may be another one on the
    disc.  File lengths are only saved to the nearest 128 bytes.
 
AL - Allocation. Each AL is the number of a block on the disc. If an AL
    number is zero, that section of the file has no storage allocated to it
    (ie it does not exist). For example, a 3k file might have allocation 
    5,6,8,0,0.... - the first 1k is in block 5, the second in block 6, the 
    third in block 8.
     AL numbers can either be 8-bit (if there are fewer than 256 blocks on the
    disc) or 16-bit (stored low byte first). 
 
 
-- 
----------------------------------------------------------------
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/