Hallo Leo,

> The msdosfs-code is maintained by mycroft. I read your (next) mail
> about the msdosfs bootsector values and I think that it is best
> to work it out a bit and forward it to mycroft. For the time being
> however, I think our best bet is to get the 'NHEADS' and 'SectPerTrack'
> in line with the checks.

I looked at the bootsector of the partition carrying the mess-dos fs,
which was rejected by mount, and it turns out that SCSI-tool did set
the correct values for NHEADS and SPT, it's just that my disk has
111 sectors per track (the test was <= 63). Actually, the number
of sectors per track varies between cylinders. This reminds me of
a certain 640 limit. :-)
 
After changing that, I was able to mount an msdos fs. However, when I
entered `ls' I got a lot of `pcbmap() returned 0' and `dos2unixtime()
month value out of range'. Ls just shows some garabage, most question
marks, while ls -l reports filesizes between 0.5 and 4 GB, quite
remarkable on a 256 Meg filesystem. :-) This was the same for all
four msdos fss.

So it seems that the msdos fs driver is reading the FAT or data sectors
when it should be reading the rootdirectory sectors. Maybe because it
relies on the MEDIA byte (meaningless under Gemdos), or maybe it can't
handle 1 sector per cluster / 4096 bytes per sector, or whatever.

I suppose the only way to get it going is to get the sources and fix
them. Would you happen to know a cross-compiler/binutils for either
MiNT or Linux?

> I was referring to his memory config. The problems you have with MSDOS
> fs depend probably on the version of AHDI who made the fs'. On my
> filesystems, the unused values are zero.

Those filesystems were not created by HDX. I tried HDX only once, it could
not handle non-BGM partitions correctly (same for AHDI) and didn't allow me
to choose sector sizes etc. I used SCSI-tool to format/partition, and after-
wards created the filesystems manually.


Waldi