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

[Alexander Huemer]

On Sat, May 22, 2021 at 12:07:28PM +0200, Alain Knaff wrote:
> 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

Alain, thanks for the thorough analysis. This is all very interesting.
One thing I can offer is to try the logging facility of FlashFloppy[1], 
which is the firmware used on the GoTek floppy drive emulators commonly 
used in these 3174 controllers.
I haven't used this before, but I'd hope that this log provides insights 
into which sectors, clusters, tracks, etc. are accessed when (any maybe 
how?). I am happy to give this as a try during the next days. Maybe that 
helps.

-Alex

[1] https://github.com/keirf/FlashFloppy/wiki/Logging-To-USB-Drive