>I just got off the phone with iomega technical support about the zip
>drive.

>Second, about 96MB versus 100MB: the official line seems to be that the
>100MB is unformatted capacity.  _I_ still think it's really metric
>megabytes instead of real megabytes.

	Actually this sounds more like the difference between formatted
floppy disks and unformatted disks: the capacity of an "unformatted" floppy
is two megabytes, but when you introduce sector gaps, address marks, CRCs,
and all that other whatnot that exists on floppies, pretty soon you've used
up 600k on a 2M floppy.

	(Having written drivers which talk directly to the floppy drive
controller on a TRS-80 Model III and re-format a disk by specifying where
on a track the CRCs, sector boundaries, GAP spaces, etc are supposed to go
I've seen how it is done. The TRS-80's floppy drives used the same FM encoding
scheme on the surface as the IBM disks. The challenge was writing a program
that would format 9-sector 512byte tracks in a machine whose default format
for the OS was 18-secotr 256byte tracks.. and THEN learn how to read MSDOS
files from a disk on a DOS PLUS machine..)

	I used to have a set of programs called FDFORMAT.EXE and FDREAD.EXE
which would re-format floppies and shrink the sector gaps to fit ten sectors
on a side rather than 9, and would also drive the head as many cyls beyond
cyl 79 as the drive mechanism would take it. This would get 5.25" disks up to
1780k and 3.5" disks up to (i think) 2M.

	Of course, that was at the risk of loosing more data....

	I think the encoding scheme on a ZIP disk is the same deal .. the
discrepancy in disk sizes is due to the amount of non-data encoding on
the surface to mark sectors, error correction, etc, etc ..

Cheers,
Phil
--
Phillip F Knaack               flipk@iastate.edu
Database Programmer, NCREMP    Student Development Group
ISU Extension                  Project Vincent, Iowa State University