Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!hellgate.utah.edu!helios.ee.lbl.gov!nosc!crash!pnet01!jca
From: jca@pnet01.cts.com (John C. Archambeau)
Newsgroups: comp.sys.ibm.pc
Subject: Re: 16-bit FAT
Message-ID: <640@crash.cts.com>
Date: 2 Nov 89 06:16:21 GMT
Sender: root@crash.cts.com
Organization: People-Net [pnet01], El Cajon CA
Lines: 85

unkydave@shumv1.uucp (David Bank) writes:
>     Hmmm...this certainly is an interesting question. Grabbing my IBM
>PC-DOS TEch Reference, I think I'll look in Chapter 5 and try to answer
>it.
>
>     Paraphrasing, the Tech Ref has several things to say:
>
>       1) The FAT consists of a 12-bit entry (1.5 bytes) for each
>          cluster ... or a 16-bit entry (2 bytes) when a fixed disk
>          is larger than 10 MB (# sectors > approx. 20K)
>
>       2) The FAT can be 12-bit or 16-bit format. DOS determines
>          which one a given disk is by looking at the total # of
>          allocation units on the disk. For  all diskettes and
>          fixed disk partitions of < 20740 sectors, the FAT uses
>          12-bit entries; 16-bit entries are used in all other
>          cases.
>
>     I am not able to find a "descriptor byte" or similar construct that
>tells DOS in one fell swoop what size FAT it is dealing with. Perhaps I
>am overlooking something, but I don't think so.
>
>     It does not seem to me to be immediately feasible to "convert" a
>FAT from 12-bit to 16-bit. I would seem to me that such an operation
>would destroy the FAT's information unless one took measures to copy
>the information and then re-enter it in a converted form (I shudder to
>think of the mapping algorithm).
>     Also, remember that DOS maintains TWO copies of the FAT. Both would
>have to be converted.
>
>     Anyway, to me it seems that the only way to do what you want is to
>record the present FAT and then re-write it byte-by-byte, remapping as
>you go. At least, that's what I get from the Tech Ref. Howintheheck you
>did it previously I really can't imagine.
>
> P.S. You could, of course, just backup the drive, reformat it and
>      using FDISK only give 10 MB of it to DOS.


I know that I'd have to backup my data, reformat the drive, et. al.  In fact,
the process to convert a 10 Mb PC-DOS 3.30 partition is the following (with a
Seagate ST225 (or other 4 headed drive it seems):

1. Backup the drive/partition.
2. Cold boot DOS.
3. FDISK
4. Format partition using NO parameters.
5. Make the appropriate changes with Norton Utilities (or equivalent) to
   the partitions boot sector.
6. Exit Norton (or equivalent) and cold boot.  This is critical since the boot
   sector (and the BIOS parameter block) is read only once by PC-DOS
7. Reformat the drive using whatever parameters desired.  Reformating does
   NOT destory the work done in step 5.
8. Restore files prior to the 12-bit to 16-bit FAT conversion.

The idea is to have 2K clusters instead of the wasteful 4K clusters.  I know
this will work with MS/PC-DOS 3.1, 3.2, and 3.3.  I just don't know what
numbers to plug in step 5 to make it work with an ST151.  The BIOS Parameter
Block is hard drive parameter dependant (which is not surprising).  The
modifications for an ST225 do not work on an ST151.
 
Since I have a stockpile of DS/DD 3.5" disks and DS/HD 5.25" disks, backing up
is no big deal for me since I never will have any intention of giving more
than 10 Mb to MS/PC-DOS regardless of how big of a hard drive I get.
 
This process is very effective on Seagate ST225's and I know it will work
with ANY drive given the proper numbers are placed in the BIOS parameter block
of the DOS partition's boot sector.  The FAT is constructed at format time, so
that takes care of that mess.
 
In the ST225 boot sector editing, only two bytes need to be changed and that's
it.  Simple process, just a matter of knowing what bytes to change to what
values and DOS is fooled and creates a DOS file system with 2K clusters and a
16-bit FAT.

 /*--------------------------------------------------------------------------*
  * Flames: /dev/null (on my Minix partition)
  *--------------------------------------------------------------------------*
  * ARPA  : crash!pnet01!jca@nosc.mil
  * INET  : jca@pnet01.cts.com
  * UUCP  : {nosc ucsd hplabs!hd-sdd}!crash!pnet01!jca
  *--------------------------------------------------------------------------*
  * Note  : My opinions are that...mine.  My boss doesn't pay me enough to
  *         speak in the best interests of the company (yet).
  *--------------------------------------------------------------------------*/