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

[Alain Knaff]

Hi,

On 20/05/2021 14:39, Alexander Huemer wrote:> On Thu, May 20, 2021 at
12:32:20AM +0200, Alain Knaff wrote:[...]>> 2. For the 2.4M image, there
is an actual inconsistency. The number of>> "reserved" sectors (boot
sectors) is set to 32, but actually only one>> boot sector is used.
Hence everything is shifted by 31 sectors.>>>> Hardwiring this to 1 in
init.c results in a readable directory:[...]
> I am relaying a message from Chris, who did the initial investigation.  
> He has issues subscribing to the list.
> 
>> I'm skeptical that the reserved sectors is the only difference with 
>> 2.4 MB media. For context, the floppy drive spins at a slower speed 
>> after the first cylinder in order to fit 30 sectors per track. The 
>> first cylinder spins at the normal speed and has 15 sectors per track.

This is interesting. This works out to exactly 30 "missing" sectors on
the first cylinder (15 on each side), very close to 31.

What if data actually started on first sector of second track, and first
track only contained boot sector, FATs and root directory, and one
unused sector? That would make the number of reserved sectors correct
after all (even though these extra reserved sectors would be "misplaced"
in the image file: one such sector between root directory entries and
data, rather than before FAT, and 30 others not really present on disk)

To confirm this hypothesis of one extra sector skipped on first track
(31 instead of 30), I compared files copied off the image by mtools with
files copied by ucode3174, and indeed contents is shifted by 512 bytes.

In ucode3174, this sector is "sneakily" skipped by enforcing alignment
of data start on an integer multiple of cluster size:

int data_offset = (... + (bytes_per_cluster-1)) / bytes_per_cluster *
bytes_per_cluster;

This works out to no sector skipped for 1.2M disks (because cluster size
is one sector), and one sector skipped for 2.4M disks (cluster is 2
sectors, and boot + 2 * FAT + root dir = odd number of sectors => so one
sector is skipped to make offset of first data sector even). In real FAT
format, no such alignment constraint exists, and smaller disks do indeed
usually have their first data sector at an odd-numbered offset, even
when an even cluster size is used.


So all this means that overriding the number of reserved sectors in
mtools wouldn't make sense, as the number of reserved sectors is correct
after all.

It might be interesting to know how the image was gathered from the
physical floppy disk, because that image copy tool would for certain
somehow have managed the switching of the numbers of sectors per track
on first cylinder.

Also, I'd be curious to hear about the sector sequence on first cylinder:

https://fdutils.linux.lu/disk-id.html

Head 0:
fdrawcmd readid 0 rate=0 need_seek track=0

Head 1:
fdrawcmd readid 4 rate=0 need_seek track=0

With rate ranging from 0 to 3.


>> When inspecting the images you can see that the first file is always 
>> VOLUME.LAB (and usually resides in the first cluster). These files are 
>> very distinct in their formatting. For example, they always start off 
>> with three letters that match the purpose of the disk (CTL, DSL, UTL), 

Indeed. First as EBCDIC (Offset 0), and then again as ASCII (Offset 0x18)


>> followed later by EBCIDIC text which matches the print label on the 
>> disk itself.

Apparently after offset 0x68

>> I can see in the image that this file starts at offset 0x3C00, which 
>> is one sector after the expected location. This offset also 

Exactly. That skipped sector on the first cylinder!

>> corresponds to the start of the second cylinder, and I believe this is 
>> where the data area actually begins. If the data area did actually 
>> start in the typical place then a single sector would be left to spin 
>> slower.
>>
>> Chris
> 
> Maybe this is worth a bit further analysis?
> Please let me know if I can help.
> 
> -Alex
> 

This indeed makes it no longer appropriate to simply ignore the number
of reserved sectors. To properly read those disks, some more complex
geometry switching would be needed to be put into place, in order to use
a different geometry on first cylinder (different data transfer rate and
different number of sectors per track).

Regards,

Alain