Hi, > while hacking on FDISK and having some thoughts about different > sector sizes I stumbled upon the problem that the extended INT13 > function 48 may return a sector size != 512 while the INT13,0X > functions always seem to operate on „virtual“ 512 sector sizes.
all INT13 functions operate (for a given hard disk) on the same sector size as reported by INT13.48 > Unsure how to handle this case I tried to find some hints in the > FreeDOS Kernel source. In INITDSK.C the sector size returned by > INT13,48 is simply ignored and only the total sector count is used > to determine the size of the disk. the kernel *should* work with sector sizes != 512 (as MSDOS reportedly does), but it simply doesn't. I Think PerditionC tried to make this work, and was successful for 256, 512, 1024 and 2048. unfortunately he didn't succeed for 4096 (I don't know the reason) so the FreeDOS kernel is stuck at 512 byte. no need to support anything else (in the context of freedos). > This may be because in reality it > is a non-existent problem (values other than 512 are not encountered > „in the wild“). there *are* 4096 byte sector disk out in the wild: (a) 4kn (4knative) disk export their 4k sector size to the OS and don't emulate 512 byte sectors. (b) some external USB disks export 4K sector size even when the internal disk has 512 byte sectors. I think they do this to be able to have 16 TB external disks, even with MBR partitioning. > There is also a MAX_SEC_SIZE 512 definition leading > me to the conclusion that sector sizes of > 512 are not supported at all? right. > My initial idea for how to handle this in FDISK until a better > solution is found was to sort of work-around it by reverting to CHS > functions - with all the drawbacks this has - if the sector size > returned by INT13,48 is not 512. Then at least the first ~8GB could be > supported. there is no point in this; CHS addresses the exact same sectors as LBA. > But I would be glad if someone with more knowledge in that area > could point me in the right direction, especially under the assumption of > staying compatible. I hope I could help. Tom _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
