Hi, I have browsed the CVS kernel a bit, and got the impression that it would not be too hard to support sector sizes below 512 bytes (32, 64, 128 and 256 bytes should be possible). For sector sizes above 512 bytes (e.g. 1024 and 2048), each element in BUFFERS and the DiskTransferBuffer would have to be bigger. Are there DOS versions which support big sectors? How do they solve the buffering problem? I think sector sizes below 64 bytes cannot contain enough of a BPB to be useful. Sector sizes below 32 bytes are definitely not useful, not even a single dirent fits in them. Sector sizes above 512 bytes are at most useful for the 1024 byte (far-east 1.2 MB diskette format / drives which support full 64 MB of a single XMS2 handle as ramdisk without having to support the DOS3.x+ 32bit sector number calls) and 2048 byte (raw sector size on CD-ROM and maybe on magneto-optical drives) cases.
Comments about useful sector sizes would be welcome: Smaller (64, 128, 256), normal 512, Bigger (1024, 2048, others). Next part: I believe that the BIOS / kernel drives (diskette, harddisk) only have to handle 512 bytes per sector. Otherwise, you would have to adjust: CalculateFATData, DosDefinePartitions, the kernel driver IOCTLS (e.g. "format track"), LBA_Transfer, max_transfer (the DMA wrap checker) and maybe floppy_bpb (and -_bpbs). In case you have wondered, directory handling already reads the current sector size from the BPB, so it is flexible. If you want drives with bigger sectors to be detected at boot time, you not only have to get BUFFERs and DiskTransferBuffer bigger and adjust _maxbksize (in the global SDA data structure, which is, by the way, not yet read by FreeDOS itself, as only 512 bytes per sector are supported anyway) but you also have to make InitDiskTransferBuffer bigger as well. For boot purposes you just have to make SYS able to pad unused parts of the boot sector to allow bigger sector sizes - BUT you also have to make SYS able to adjust the boot sector code to that, I remember that not all our boot sectors actually used the BPB bytes-per-sector value (there was not enough space to process it). Smaller sector sizes are simply too small to be bootable anyway. I wonder if you should be able to boot from nonstandard sector sizes at all - for example a CD- ROM does not even have a FAT filesystem, so why would you boot from a (raw!) CD-ROM then? So I suggest to support nonstandard sector sizes ONLY for drives which are connected to separate drivers (e.g. ramdisks, USB drives, ZIP...). To make that possible, BUFFERS and DiskTransferBuffer handling would have to get better (even for smaller sectors - for bigger sectors, the BUFFERS and DiskTransferBuffers themselves, being only _maxbksize big, will be the problem). In addition, getbpb and dskxfer (THE central "send/receive a sector to/ from a device driver" function) have to be made independent from the hardcoded SEC_SIZE. Instead, they have to use the sector size from the BPB of the drive. Hint: getbpb assumes that the boot sector magic word is at offsets 1fe and 1ff. This IMPLIES a sector size of 512 bytes, too. The GOOD part is that FreeDOS hardly uses anything else than getbpb and dskxfer to communicate disk contents (for which it uses BUFFERS and DiskTransferBuffer as intermediate storage places). rqblockio does call block device drivers directly, too, but not to access sectors, for example, and the other functions all use dskxfer or getbpb directly or indirectly. I hope I have not overlooked things in this review... Summary: - To support bigger sectors, raise _maxbksize and make each element of BUFFERS and DiskTransferBuffer bigger - To support nonstandard sector sizes at boot time, CalculateFATData, InitDiskTransferBuffer and DosDefinePartitions have to be modified - To support nonstandard sector sizes for harddisk / diskette (kernel built-in drivers), you have to adjust the IOCTLs (format track...), LBA_Transfer and max_transfer - To support nonstandard sector sizes at all, you have to modify dskxfer and getbpb and the BUFFERS and DiskTransferBuffer handling has to accept sectors in other sizes than SEC_SIZE, including e.g. sectors which are smaller than _maxbksize... - SYS and boot sectors can only support bigger, not smaller, sector sizes, and SYS might have to do extra patching for those of the boot sectors which do not actually use the boot sector BPB sector size info We should probably start by using _maxbksize in BUFFERS and either only DiskTransferBuffer or both DiskTransferBuffer and InitDiskTransferBuffer to get things a bit clearer... Then we should make SYS and boot sectors able to support bigger sector sizes (not because it is really useful but because this part is more self-contained / easier to maintain than the rest of the kernel). Then the first WORKING support for nonstandard sector sizes can be added by making BUFFERS and DiskTransferBuffer handling aware of the CURRENT sector size and making dskxfer and getbpb able to support all of the sane (64, 128, 256, 512, 1024, 2048 bytes) sector sizes and aware of the current sector size. Only as a bonus step we could modify the kernel drivers and IOCTLs to support nonstandard sector sizes for harddisks and diskettes. See above. Please comment. Only having to modify 2 buffering systems, 1 variable and 2 core disk access functions to get support for RAM / ZIP / USB drives with nonstandard sector sizes somehow sounds too good to be true. Support for booting big-sector drives and for nonstandard-sector-size- harddisks and diskettes would be an extra but probably not too useful? Thanks for your comments! Trying to wake up the kernel list a bit :-)). Eric PS: If there are no comments, conserve this as technote and wait for comments from reappearing or new kernel people in the future... But I think that there ARE still people around here (as opposed to the fd-doc- list, freedos-devel-net and freedos-freecom: I really recommend to move the remaining members to freedos-user and freedos-devel to get out of the current "frozen" state in which only from time to time somebody pops up, asks a question, and gets no answer on doc-list, devel-net, freecom). ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
