Hi Christian, I remember that eltorito.sys tries to autodetect whether the BIOS lets you access the CD/DVD as 2048 byte per sector drive or rather as 512 bytes per sector, so the idea of different sized sectors is not new... Floppy supported 128 to 1024 bytes, for example... Yes, FreeDOS only supports 512 bytes at the moment. For unknown reason, this became even more hardcoded than it was before short ago. As far as I remember, the biggest that MS DOS supported was 4096 for WORM, but only with driver.sys? Blu-Ray seems to have 8192 here. Another source mentions 2048 bytes used for MO drives... And wasn't there some far-east floppy format with 1024 byte sectors, too?
http://support.microsoft.com/kb/67321 writes that sector sizes other than 512 bytes are exotic apart from for some ramdisk. http://www.computerhope.com/formathl.htm says that Win9x FORMAT supports up to 128 sectors per cluster but that sector sizes can be between 512 and 2048 bytes in this system (implicitly). Note that supporting bigger sectors will need bigger buffers at some point and some way of detecting actual sector size. I do not know whether MS DOS ever could BOOT from drives with big sectors. >> LARGE SECTOR DRIVES: There is also the issue of large-sectored disks >> coming after the 2TB drive, if anyone plans on purchasing one of those. >> by large-sectored I mean drives that have 1024, 2048, 4096 byte sectors. Note that we should also check whether kernel, FORMAT, FDISK, DOSFSCK and maybe other tools have "sign overflow" problems for 512 byte per sector drives above 1024 GB. Can anybody test that? Of course as long as FDISK is happy (or you simply use Linux FDISK) you can limit your self to drive letters of at most 1024 GB each, avoiding any problems. >> Microsoft has warned of this. large-sectored drives allow you to use >> the existing 32-bit-LBA MBR until the UEFI+GPT becomes established as a >> standard. Talking about GPT and UEFI: Tom often mentioned that we should add GPT handling to our partition table parser (initdisk.c). Note that this might make the parser significantly more complex - not sure. >> what large sectors affects is disk management utilities such as fdisk >> and chkdsk and defrag, and partition growing utilities that have >> hard-coded 512-byte sectors into their code (like I used to). > FreeDOS's kernel also has 512 byte hardcoded as sector size for some > reason. I don't know about the Int13 low-level stuff yet, but the > DOS-internal buffer structure is fixed to 512 byte data and DOS's list of > lists field which specifies the maximal sector size is initialized as 512 > and never used by any code. As said above - int13 can do other sizes, but FreeDOS became lazy and ignores other sizes. On the other hand, not THAT many places would have to be changed to make FreeDOS aware of other sector sizes, at least if only block devices loaded AFTER boot would have to support other sizes. Eric PS: I think LinuxBIOS (however it is called at the moment ;-) has a plugin to provide legacy BIOS services (int 10, 13, that stuff) to classic systems such as DOS. PPS: A list of BIOS services needed by FreeDOS can be found here: http://fd-doc.sourceforge.net/faq/cgi-bin/viewfaq.cgi?faq=General_Information/277 www.mail-archive.com/freedos-u...@lists.sourceforge.net/msg07697.html www.nabble.com/Running-Free-DOS-on-the-OLPC-XO-td17286577.html (int 11, 12 - simple / int 14, 17 - only if COM/LPT used / int 19 - only reboot / int 1e - only floppy / int 1a - CLOCK / int 10 - VGA / int 16 - KEYB / int 13 - DISK ... See the URLs for exact info :-) ) ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel