In article ,
 pausch{at}saaf.se (Paul Schlyter) wrote:

> In article ,
> Andy McFadden   wrote:
> >All of this is in the context of Apple II CP/M on a 5.25 floppy.
> >
> >CP/M disks use 1K blocks, and have a directory starting at block 12 (track 3
> >on a 5.25" disk).  The first 3 tracks are reserved for the
boot image.  That
> >leaves 140K - 12K = 128 blocks.
> 
> All of those quantities are actually configurable - their values are
> stored in the DPB (Disk Parameter Block) in the BIOS, where each disk
> has its own DPB.
> 
> I hooked up 80 track DSDD disks to my Apple II in the 80's and made
> all of the disk into a 640K CP/M disk volume.  Then I had to make the
> CP/M blocks 2K large, since a CP/M disk with 1K blocks cannot be as
> large as 640K.
> 
> So you should really write: "All of this is in the context of an
> Apple II CP/M on a 5,25" floppy in its standard 140K configuration".
> 
> >I've been sent an apparently valid disk image that uses block numbers above
> >128.  It appears that such values wrap around, storing data in track 0-2.
> >
> >Is this the expected behavior?  This is of interest for the CiderPress
> >disk read routines, which are currently unable to extract such a file
> >in its entirety.
> 
> I would call that behaviour an undocumented bug.  The system tracks 0-2
> should be accessible only through BIOS calls, not through BDOS calls.
> The bug is probably in the BIOS.

Might this have been a patch to get more storage on a data disk? I 
recall tinkering with Apple's p-system BIOS and formatter utility when 
40-track drives became common.

Sorry if this is a naive question. I know next to nothing about CP/M 
except how loyal WordStar fans were--and perhaps still are! :-)

-- 
John B. Matthews
trashgod at gmail dot com
home dot woh dot rr dot com slash jbmatthews
--- SBBSecho 2.12-Win32