> At this time there are no plans to explicitly support 4K block sectors
> directly in the kernel. The kernel itself does not support any block
> devices directly, it relies on the BIOS interface, though additional
> drives or support may be added through device drivers.
Unfortunately, FreeDOS does not support device drivers with other
sector sizes than 512 bytes either. There were discussions about
this a few years ago, mainly because a RAMDISK can in some cases
be more efficient with other sector sizes, in particular smaller.
As BUFFERS and the transfer buffer in "low" memory (below 640k) and
possibly other structures (in SDA?) all have to be at least as large
as the biggest supported sector size, I think it would not be very
nice to support 4 kB sector size in a default FreeDOS kernel...
> I would like to review the FreeDOS utilities to ensure we are
> optimally using 4K sectored drives when emulation is being used (i.e.
> 4K aligned read/writes where feasible), but can not provide...
FORMAT, in the FAT32 case, has a command line option to align the
data clusters to multiples of 4 kB. I think that got added because
Windows also introduced the feature and it felt useful for SSDs.
Not sure about FDISK and similar tools. In general, I recommend to
use the more comfortable and also free open source GPARTED from a
bootable CD / DVD or USB stick for partitioning, not classic DOS.
I have a strong intuition that neither CHKDSK nor DOSFSCK for DOS
support other sector sizes than 512 bytes.
Basically all software which acts only on files does not care for
your sector size anyway, only low level tools are an issue here.
> (512 byte emulation) - for data purposes. The boot code is currently
> limited to 512 byte sectored devices, but actually 4K sized sectors
> could be supported with a different boot sector if the computer's BIOS
> would support booting such a device. I would need to research...
Maybe somebody else can report experiences about booting ANY system
from disks with 4 kB sector size: I guess only newest BIOSes work.
Talking about new ways of booting, it would be very interesting to
have a CD / DVD / BD boot loader for DOS. However, after you loaded
the kernel, you still need some "initrd" from which you can load a
CD/... driver pair like UIDE + SHSUCDX or ...CDROM + MSCDEX. As we
use MEMDISK (a bootable RAMDISK which can be loaded by any bootmenu
which can load Linux) for that now anyway, the only gain would be a
little bit of memory saving: Instead of booting a ramdisk, the boot
loader itself would somehow give access to a FAT diskimage on CD/...
> while since I read the cluster to sector code, I believe since DOS
> works at cluster level primarily, accessing 4KB drives is feasible
> without breaking too much compatibility assuming minimal of 4KB
> cluster size; though for many DOS programs 512 byte access is expected
> and would either need to be provided via some emulation or...
Luckily most programs do not work with sectors or clusters at all,
they only care for files and directories. But you are right that
tools like FORMAT / CHKDSK could break if they fail to check size.
Interestingly, even MS DOS DRIVPARM and DRIVER.sys do not let you
change sector sizes and "MS" UNFORMAT only goes up to 2 kB sizes,
but MS RAMDRIVE and free ramdisks (TDSK) do support other sizes.
In RAMDRIVE, 128 to 1024 bytes were possible, in TDSK 32 to 2048.
To reply to another mail:
>> 1) emulation with aligned 512byte sector emulation
>> > 2) emulation with non-aligned 512byte sector emulation
>> > 3) native 4K (especially USB bridges apparently)
Depending on your BIOS, you may need a driver for USB disks in
DOS anyway, so that driver can easily be extended to give you
a "512 byte sectors" view of the disk. The "easily" comes from
the interesting situation that we have 2 free drivers from DOS
fans but none from mainboard manufacturers. Self-driven DOS :-)
According to an ancient (2002) post by Matthias Paul (hi :-)),
MS DOS 7.1+ and DR DOS 6.0+ and DR DOS 3.31+ support up to 2 kB
sector sizes (and min 32 bytes, or for DR DOS 3-5 min 128) and
Win 95/98/ME have a minimum of 512 bytes but still max 2 kB. I
would guess this is somehow related to using FAT on CD-RW/WORM?
Some versions of DR DOS might support up to 16 kB sector size.
Apparently pre-2003 FreeDOS DISKCOMP tried to support all sizes.
The Microsoft fatgen103.pdf specs of the FAT32 filesystem say
that sector sizes must be 512, 1024, 2048 or 4096 bytes, while
some other aspects of pre-Win9x DOS suggest that small sectors
of 32 bytes and more and maybe large up to 8 kB (maybe 16/32?)
were also supported at least for e.g. ramdisks...
Note that you cannot have more than 2^32 sectors in one drive
and max 2^28 clusters in FAT32. So you need some drive letters.
In a 2003 FreeDOS 1.0/after thread, Aitor considered COUNTRY-
support, MS DOS style config.sys menu system, FASTOPEN, more
than 1 UMB area, variable sector size, DRIVPARM, DOS for ROM.
Also in 2003, I mentioned that block device drivers according
to RBIL, int 2f.0802, tell DOS about BPB and sector sizes and
mainly the DOS BUFFERs system would have to explicitly support
other sizes than 512 bytes. The int 21.52 table, offset 10h in
DOS 3.1+, states what the largest sector size of all open FAT
drives is which determines the BUFFER size. Sectors must be at
least 32 bytes to hold at least 1 directory entry but booting
usually only works for 512 byte sectors (or larger) at all. It
seems that CP/M disks sometimes had 128 byte sector sizes, and
even DOS and some compilers still have 128 byte default record
size in some old interfaces. Sectors cannot be more than 8 kB
without breaking SFT: each sector can have max 256 dir entries
as Bart pointed out in 2003.
Talking about which, before ...DOS 3.3, some variants used a
larger (logical) sector size because they only supportes 2^16
sectors per disk. Which is why even now, FAT16 has a partition
type for less than 32 MB and another for more :-) Even TDSK
back then had issues with 2^16 sector limits. I guess today,
a FAT32 RAMDISK with up to 4 GB size would be easy and good.
My 2003 mail also says that it was a year or two ago that I
had looked at sector sizes and that Tom and Bart know more.
Ralf Quint also knows more about this and about other DOSes.
Lucho wrote in 2003 that only Japanese NEC style floppy let
large 1 kB sectors work with FAT, but not in bootable ways.
For not-actually-sectored systems, smaller sectors are good
to reduce overhead: RayeR can probably explain a RomOS view.
You can load the kernel from a non-FAT space and then let a
patched FreeDOS kernel access a minisector FAT image in ROM.
The non-free ROM-DOS supported 128, 256, 512 and 1024 bytes.
Lucho wrote "ROMDSK" to combine this with compression, too.
The 21 Jul 2004 post "Optimization idea: DIV/MODULO never full
32=32/32bit" also discusses some sector size related calc...
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Freedos-user mailing list