Hi, on
http://www.coli.uni-sb.de/~eric/stuff/soft/by-others/ format-0.91h.zip
(102k) you can now find a new FORMAT release.

Changes:
- fixed a few printf format strings
- fixed an integer overflow when creating the FAT32 root directory
- fixed FAT32 surface scan (not tested that much)
- surface scan on harddisk can be skipped after 34 MB with ESC key now
- surface scan will only happen on harddisks if explicitly requested
  (format /u). Otherwise, even for unformatted disks, only the metadata
  will be initialized. Surface scan can take ages on big FAT32 disks...
- sequential formatting of several floppy disks should now check each
  disk for existing format properly...
- displayed free space now matches CHKDSK / DOSFSCK values: In /D mode,
  the difference (slack: partial cluster after last usable cluster) will
  be mentioned (old FORMAT displayed size INCLUDING slack, new FORMAT 0.91h
  now EXCLUDES slack in the statistics).
- displayed TOTAL space now is total disk / partition size based on sector
  count. For some strange reason (BUG?), CHKDSK does not count FAT / root /
  reserved / slack but simply displays "total" size as "same as size of
  data area" (cluster size * cluster count). There still is NO special SYS
  processing for the statistics display, though. I did not check whether
  the cluster count and the available space include and exclude the FAT32
  root directory in their respective values - I think they should.
- if bad sectors are found on FAT32, they will still not be marked in the
  FAT, but at least there will be a list of them displayed.

Tyler found some interesting problem: int 21.440d.?860 does return cluster
size ZERO but an otherwise correct BPB on some systems. Maybe a kernel
oddity? Some other program assumed a cluster size which led to FAT32 with
only 62k clusters for that drive, but "get ext. free space" as used by
my WHICHFAT reports > 64k clusters / FAT32 correctly. So kernel seems to
know the correct cluster count but still does not return BPB cluster size
field correctly? Happened on a SCSI system. On other systems, Bernd and Tyler
could properly format FAT16 and FAT32 with FORMAT 0.91g+ / 0.91h. Bernd seems
to have found a SYS bug in the course of the experiments: SYS fails to read
the FAT32 magics and assumes that the root dir starts at
"FAT start + (ZERO FAT size * 2 FAT copies)", while the
"zero FAT size" is just a flag to mark FAT32. The created boot
sector therefore does not load the kernel, but hangs.
By the way, I hope Imre can do some magic and add FAT32 sector READ
function to DOSFSCK for DOS... Thanks! (He already has updated it to 2.10!)

Fritz reports that FORMAT B: /4 /U gets a timeout error at about 45%
(trying to format 360k disk in 1200k drive) - can you reproduce? Do
720k / 1440k / 1680k formatting in 1440k drive still work?

TODO list:
- preserve existing bad cluster list if drive already formatted, and
  avoid re-checking bad clusters in that case (to be controlled by /C flag)
- re-structure code to avoid too long / too short source files and to
  improve readability / maintainability (long term TODO...)
- add FAT32 bad cluster list writing
- change mirror map creation code to use buffers more dynamically, to
  allow saving FAT32 UNFORMAT data (anybody having FAT32 UNFORMAT for that yet?)

- add debug output: floppy controller baud rate / double stepping flag
- make ASCII_CD number output (1,234,567) NLS-aware
- explain which sector is bad when aborting due to broken boot/fat/root sector
  (make error message more detailed)
- improve formatting abilities for various floppy sizes in various drive types
- long term TODO: add i18n support with help of KITTEN (> 300 printf to be
  changed, not planned before 0.93 or later)

Have fun with the new FORMAT, and please tell me what works and what does not
work yet for you with FORMAT 0.91h, thanks!

Eric.