[Info-mtools] What does it take to support FAT12 dialects?

[Alexander Huemer]

Hi

I own an IBM 3174 controller. For those unfamiliar with the device, it's 
a machine that uses one or two 5.25" floppy drives to load software into 
it. These drives are either of the common 1.2M variant or a pretty 
uncommon 2.4M variant.
In the very small community of people who operate such machines today, 
several people have replaced the floppy drives with GoTek emulators, to 
make it easier to interchange data with modern computers via USB flash 
drives.
The disk image files coming from an 3174 are recognized by minfo with 
correct results as far as I can tell, though e.g. mdir cannot list the 
content, see output below. Hence i figure that the image format is not 
an issue, but the filesystem layout.
Somebody (not me) had a look at the format, here is what they found:

> Has anyone else tried making sense of the filesystem present on the 
> disk images here?
> I'be spent a couple days looking at it now and and it's very clearly 
> based on FAT12. There's only a couple of things that have thrown me 
> off. First, the number of reserved sectors at offset 0xE is 32, even 
> though I can see the FAT starting at the second sector. Second, on 2.4 
> Mb disks I'm convinced the first cluster starts at 0x3C00 as opposed 
> to right after the root directory which is at 0x3A00. Part of the 
> reason I think this is because the file here is usually VOLUME.LAB 
> which is mostly EBCDIC text and only 512 bytes long. So starting at 
> 0x3A00 wouldn't include this. Starting at 0x3C00, makes the volume.lab 
> files consistent across all the images I've looked at, 1.2 and 2.4 Mb.  
> My best guess is that the clusters are aligned to start at offsets 
> which are multiples of the cluster size, which is two 512 byte 
> sectors. Perhaps this is expected behavior? I will confess I did not 
> know any implementation details of FAT12 before a couple days ago, but 
> I have not seen this phenomenon mentioned anywhere.

Assuming these findings are correct, I wonder what would be involved in 
making mtools support this dialect of FAT12.
I did a quick grep in the source code but couldn't find the offsets that 
are mentioned in the quote above.

Any suggestions how to approach adding support for this dialect would be 
appreciated.

> $ minfo -i 12.img
> device information:
> ===================
> filename="12.img"
> sectors per track: 15
> heads: 2
> cylinders: 80
> 
> media byte: f9
> 
> mformat command line: mformat -t 80 -h 2 -s 15 -i "12.img" ::
> 
> bootsector information
> ======================
> banner:"N3174KGN"
> sector size: 512 bytes
> cluster size: 1 sectors
> reserved (boot) sectors: 1
> fats: 2
> max available root directory slots: 224
> small size: 2400 sectors
> media descriptor byte: 0xf9
> sectors per fat: 7
> sectors per track: 15
> heads: 2
> hidden sectors: -2071789568
> big size: 20132486 sectors

> $ minfo -i 24.img
> device information:
> ===================
> filename="24.img"
> sectors per track: 30
> heads: 2
> cylinders: 80
> 
> media byte: f0
> 
> mformat command line: mformat -T 4800 -h 2 -s 30 -H 1710948352 -i "24.img" ::
> 
> bootsector information
> ======================
> banner:"N3174KGN"
> sector size: 512 bytes
> cluster size: 2 sectors
> reserved (boot) sectors: 32
> fats: 2
> max available root directory slots: 224
> small size: 4800 sectors
> media descriptor byte: 0xf0
> sectors per fat: 7
> sectors per track: 30
> heads: 2
> hidden sectors: 1710948352
> big size: 21172290 sectors

> $ mdir -i 12.img
> Volume in drive : has no label
> Directory for ::/
> 
> No files
>                             469 504 bytes free
> 

> $ mdir -i 24.img
> Cluster # at 36 too big(0xce9)
> Probably non MS-DOS disk
> Cannot initialize '::'
> $ 

Thanks,
-Alex