Re: DSK format specification

[pausch@saaf.se (Paul Schlyter)]

In article <S_gQa.1437$dk4.64825@typhoon.sonic.net>,
Andy McFadden  <fadden@fadden.com> wrote:
 
> In comp.sys.apple2 Paul Schlyter <pausch@saaf.se> wrote:
>>> CiderPress looks for DOS, ProDOS, Pascal, CP/M, and RDOS filesystems in
>>> "DOS", "ProDOS", and "physical" sector ordering every time you open a
>>> disk image.
> 
>> Then how do you determine the sector interleaving on a blank Apple CP/M
>> disk images (no files ever written to the disk, no CP/M system on the
>> system tracks)?  Such a disk will have all bytes in each and every
>> sector set to hex E5.  Perhaps in such a case you just assume DOS 3
>> sector order, since that's what works best with those Apple II emulators
>> which also emulates a Z80 ?
> 
> I scan the volume directory and look for weirdness.  If the disk were
> completely empty there'd be nothing to scan and I'd get the wrong answer,
> but since CP treats CP/M as read-only it's not like you'll miss out on
> anything. :-)
 
> I would have preferred to examine blocks in the boot area (the first 3
> tracks), but it looks like AE and Microsoft had different implementations.
 
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.
 
CP/M Plus (CP/M 3) decreased the number of system tracks by one and
instead put the CCP (Console Command Processor) in the file system area.
MS-DOS carried this process even further, and decreased the "boot area"
to one single sector, keeping everything else in the file area (BIOS,
OS, CCP) although with some limitations (these files had to reside
at the very beginning of the disk and had to be unfragmented).
 
> The saving grace with CP/M is that it does allocations in 1K blocks,
 
That is configurable in the DPB (Disk Parameter Block); see the "CP/M
Alteration Guide".
 
> it appears to start allocating from the front, and it doesn't fill the
> entire "catalog track".
 
There is no "catalog track" on CP/M.....
 
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.  The directory always resides at the
start of the file system area, and then it contains a specific number
of directory entries (64 entries on an Apple CP/M disk, but again
that can be altered bu changing the DPB appropriately).

The DPB does not reside on the disk though, but in memory at a specific
place (there's apointer there among the pointers at the start of the
CP/M BIOS).  Each disk volume has its own DPB, thus different volumes
can be disks with different characteristics (you could have one 8"
floppy, one 5.25" floppy, one 3.5" floppy and one harddisk for instance).
The CP/M DPB can descripe disks up to 8 MBytes large.

On CP/M disks with a bootable system the DPB of course resides on the
floppy -- somewhere on the system tracks, in an implementation specific
way.  But if the disk is not a bootable "system disk", then the disk
itself contains no info whatsoever of the specifics of the disk format.
 
> This means that the first file you create will
> have data on the catalog track itself.  So if you load the entire catalog
> into memory, scan it, and find anything other than valid entries and 0xe5
> values, you know you have the order wrong.  (If the files stored in the
> catalog track happen to be filled with 0xe5 or look like valid catalog
> entries, then you're in trouble.  In that case, having the correct label
> on the disk image is essential, or you're going to have to use "query
> image format" to override the automatic detection.)
> 
> Overall the CP/M code in CiderPress is the weakest of the filesystems,
> since nobody ever wrote a "Beneath Apple CP/M".
 
There was the official "CP/M Alteration Guide" by Digital Research, who
gave enough BIOS details to let anyone implement their own BIOS.
 
However, as opposed to Apple DOS, CP/M ran on a wide variety of hardware
platforms, each having its own BIOS.
 
And there was actually a book giving details of the Apple SoftCard
CP/M BIOS --- don't remember the title, but important details from
it have been summarized in:
 
http://home.tiscali.se/pausch/apple2/CPM.ref.txt
http://home.tiscali.se/pausch/apple2/Apple.CPM.ref.txt
 
http://www.stjarnhimlen.se/apple2/CPM.ref.txt
http://www.stjarnhimlen.se/apple2/Apple.CPM.ref.txt
 
which also gives details from the standard CP/M documentation.
I also describe the 640K diskette format I implemented for
my own Apple II in the early 80'ies, using 80-track double-sided
diskette drives from Teac.  I compare that disk format with
the Apple CP/M standard 13-sector and 16-sector formats, as
well as the CP/M standard 8" SSSD format.
 
So, yes, there have been plenty of docs about the Apple II CP/M
format, although it wasn't that wellknown in large parts of the
Apple II community.
 
> (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
 
(the latter is the CP/M manuals online in HTML format),
or my summaries:
 
http://home.tiscali.se/pausch/apple2/CPM.ref.txt
http://home.tiscali.se/pausch/apple2/Apple.CPM.ref.txt
 
http://www.stjarnhimlen.se/apple2/CPM.ref.txt
http://www.stjarnhimlen.se/apple2/Apple.CPM.ref.txt
 
 
> Fortunately I was able to find some large text files and compare
> the output on an Apple II to the output from CP to verify that
> all was well.
 
-- 
----------------------------------------------------------------
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/