DOS 3.3 400k volumes

["Joel" <joelbuckley54.nospam.@hotmail.com>]

"Lazarus I. Long" <me@lazilong.com> wrote in message
68a2ec1b.0212031533.58b2ffca@posting.google.com">news:68a2ec1b.0212031533.58b2ffca@posting.google.com...
> I know they split into "drive 1" and "drive 2" each 400k.
>
> but is it really exactly 400k?  by my calculations it is: 368640
> bytes.
>
> 256 (bytes/sect) * 16 (sect/track)  * 97 (tracks/disk) = 368640
> (bytes/disk)
>
> do i have that wrong?  does this leave a gap between volumes or are
> they separated by the "sides" of the disk?  if the disk is separated
> by "sides" that would mean, since i must access it as a block device,
> when I read block 0, i'm getting 2 sectors, side 0 sector 0 and side 1
> sector 0 right?
>
> anyone got any more format info on this?

While I haven't used the 3.5" Disk versions of DOS 3.3, I am familiar with
the DOS VTOC (volume table of contents).

DOS 3.3 allocates 4 bytes to each track. Each bit stands for 1 256 byte
sector.
A 5.25 disk only uses 16 sectors per track out of 32.
The older DOS 3.2.1 uses the same technique using only 12 sectors per track.
But DOS 3.3 will support 32 sectors per track.
A standard 5.25 disk uses only 35 tracks.
But the VTOC will support 50 tracks.
This bitmap is stored in the VTOC (volume table of contents) at track 17
($11) sector 0
starting at byte $38. From $38 to $FF is 200 bytes, 50 tracks max at 4 bytes
per track.
So maximum disk size is 50 tracks x 32 sectors x 256 bytes = 409,600 or 400
x 1k (1024) bytes.

Even before 3.5 disks, hard disk versions of DOS 3.3 used this big volume
(400k) mapping.
Programs that use standard DOS file commands or the DOS file manager will be
able to use almost all of this space.
(It won't normally uses track 0).
Programs that use low-level RWTS (read/write track sector) routines and
which do not read the VTOC to determine maximum track and sector values may
fail.

Conveniently, exactly two of the big volumes can be mapped on to a 3.5 800k
disk.

I haven't heard of anybody mapping DOS 3.3 onto a 1440k superdrive, but that
would hold 3.6 400k volumes or 10 regular volumes.
While it is possible to remap the extra volumes as extra slots or drives
(even going beyond 2 drives per slot), hard drive versions usually used the
otherwise seldom used V(volume) parameter to select from multiple volumes.

It would be possible to map each 400k volume to one side of an 800k disk.
This would even provide compatibility with the rare 400k single-sided 3.5
disks and drives.
But I think it more likely that the mapping was to map the first 400k ProDOS
blocks to the first big volume and and from 400k to 800k to the second
volume.

IIRC, Apple described a similar 2 400k volume format for Apple Pascal in one
of its tech notes.

Joel