CF 'Formatting' creates an empty SSSD disk named VOL[X] with X 
being the volume number. the CF7 FORMAT command also uses a maxed out
sector-per-track count of 32, as well as the standard max
sector count of 1600, when writing the disk header.

So bytes 10-11 will ALWAYS indicate a size of 1600 sectors ($06 $40).
And bytes 12 will ALWAYS indicate 32 ($20).

The bytes for TracksPerSide and Number of sides (17 and 18) will be
correct ($28 $01).

The bitmap starting at byte 56 is $03

Untill a CALL MOUNT is issued the bytes that specifiy volume mounts are
blank; after the first mount they goto the AA 03 00 XX 00 YY 00 ZZ with
the latter bytes indicating the volume numbers mounted in those locations

--------------------------------------------------------------------------------

If you use DM or some other device to FORMAT a disk it will have the standard
sector count for whatever format parameters you provide. So if you make
a blank DSDD work disk it will be 1440 sectors in size.

If you copu a disk image from the CF to a PC the sector count is not altered,
but if you copy a diskette file to the CF it ALWAYS sets the sector count
to 1600, without altering the sector size, track count, etc. SO you end up
with a diskette header that is inconsistent: 40 tracks/side, 18 sectors/track,
2 sides. But 40*18*2=1440, while the header says 1600. 


So if you copy a CF7 '1600 sector' disk image back to a PC the odd header
info comes with it. WHat happens if you then copy that image to a 'real'
diskette? 

And So what? Well, if you're going development on physical diskettes, but
copy your work to a CF card to work on a CF system becauseo f its portability
or for whatever reason, then retrieve your disk from the CF, it will have
been changed. You could I suppose rip each file from the PC image and then
copy them back to your 'true' image. Yuch.

---------------------------------------------------------------------------------

So to 'format' programmatically we create a sector 0 and write it and then
write all zeros to the other 1559 sectors. The first sector should use
a bogus sector-per-track count of 32 at byte 12, as well as the
standared bogus sector count of 1600 at bytes 10 and 11.

to write from a PC TIDisk file to the CF we read it into sector array and then
write each sector plus (1600 - true sector count) of zeros

to read a CF volume into a PC file we write all sectors.
BUT CORRECT SECTOR COUNT AND DO NOT PAD!!!
   
--------------------------------------------------------------------------------

expose file list box and implement drag & drop????

--------------------------------------------------------------------------------   