Variable sector size and INT 13/AH=02h calls

[0b00000000]

On how much hardware can we assumer a sector to be of size 512 bytes for INT 13/AH=02h calls?

I'm sure I've seen references out there to floppys with sectors of varying sizes. What about other media (hard disks, usb, CD, DVD etc.)? How wide ranging/restricted is an assumption that the sector is 512 bytes? Is there a way of detecting how many bytes have been loaded?

[neon]

Never assume when writing software that executes in kernel mode. With that said however, 512 bytes are fairly common on most devices, and CD's use 2048 byte sectors.

[Techel]

For a bootload it suffices to assume sector sizes = 512 Bytes. Of course you should retrieve the correct chunk size of the drive later when writing a driver.

[0b00000000]

Never assume when writing software that executes in kernel mode. With that said however, 512 bytes are fairly common on most devices, and CD's use 2048 byte sectors.

How might one test the number of bytes that have been loaded?

Is there some return value that I'm missing somewhere? Or is it necessary to check for strategically laid signatures at the end of each section of binary loaded?

[neon]

Hello,

You can obtain it from the Bios Parameter Block. When writing actual drivers later on - For floppy devices, you set the sector size when sending controller commands for reading and writing. For disk devices, you can obtain it through the ATA IDENTIFY DEVICE command.

For what you need, I'd recommend just getting it from a BPB and using an actual file system. This gives you the bytes per sector; your software is required to keep track of how much actual data is read or written when copying buffers larger then a sector.

[Brendan]

Hi,

Never assume when writing software that executes in kernel mode. With that said however, 512 bytes are fairly common on most devices, and CD's use 2048 byte sectors.

How might one test the number of bytes that have been loaded?

You can use "Int 0x13 extensions, Get Drive Parameters" to determine the bytes per sector for hard disks, CD-ROM, etc. This will be the sector size that "int 0x13" functions use (which can be completely different to what the underlying hardware uses); and because there's probably a lot of software that assumes 512-bytes (for hard disks) or 2048-bytes (for CD) it's relatively safe to assume BIOS emulates 512-bytes (for hard disks) or 2048-bytes (for CD) if/when the underlying hardware uses something different. For an OS (e.g. a native driver that can't use BIOS's emulation) you'd ask the device itself (e.g. the "Identify Device" ATA command).

For floppy disks it's different - you can't use "Int 0x13 extensions, Get Drive Parameters" (to determine what BIOS does), there's no "Identify" command, and the floppy drive hardware itself (excluding USB floppy drives) supports a variety of sector sizes (from 128 bytes per sector up to 16 KiB, if I remember right), and even allows different sector sizes on different tracks (e.g. you can have a first track that use 512-byte sectors then use 8 KiB sectors for the rest of the disk if you really want to). Note that there are multiple non-standard "clever schemes" designed to squeeze more data on a floppy, where one technique is to waste less disk space for gaps between sectors (and fit more data on a disk) by using fewer larger sectors, and where leaving the first track as 512-byte sectors avoids compatibility problems. The only reliable way to determine what the BIOS does is to fill a large (16 KiB?) area with zeros and read a sector, then fill the area with 0xFFFFFFFF and read the same sector; so that you can determine how many of your bytes were overwritten.

For a native floppy disk driver; you have 4 choices for floppy:

• assume 512 bytes per sector (which is extremely common, and the only choice that most USB floppy drives support)
• Rely on other information that could be wrong and/or not present (e.g. BPB)
• Use a "manual probing" approach (e.g. try to load a sector using various sizes and see which one works without error).
• Ask the user

Note that the same applies to determining number of sectors per track, data rate/density, etc. Also, asking the user is almost always a very bad idea, but is probably the best idea when the user is formatting a disk (because the format they want may be completely different to whatever format the floppy previously used).

Of course very few people still use floppy disks and almost all floppies are 512 bytes per sector anyway, so worrying about (and supporting) floppies with other sector sizes is most likely a waste of time.


Cheers,

Brendan

[onlyonemac]

I'm sure I've seen references out there to floppys with sectors of varying sizes. What about other media (hard disks, usb, CD, DVD etc.)? How wide ranging/restricted is an assumption that the sector is 512 bytes? Is there a way of detecting how many bytes have been loaded?

I have not heard of floppies with sector sizes other than 512 bytes. There are some unorthodox floppy disk formats that use different numbers of sectors per track, or different numbers of tracks, but not different sector sizes, and unless you're explicitly wanting to support and/or use those then there's no need to worry about them.

Other media tends to use larger sectors these days, but it's always a power of two greater than 512 (1024, 2048, 4096, 8192, etc. - I think most hard drives these days have 4096 bytes in each sector). For most purposes, you should abstract the device as a byte array where sector size doesn't matter any more, and working in blocks of 512 is guaranteed to not exceed one sector on any but the most obscure hardware. Nevertheless there are times when sector size matters, and in such situations you can read up about how to determine the sector size of various storage devices.

[iansjack]

If it's your operating system then you can determine what sector size to use; just write your own formatting program. 512 bytes is certainly the most common, but it's not a given. For example, 8 inch floppy disks had sector sizes ranging from 128 bytes to 1024 bytes.

Personally I would say that support for any floppy disks is as unnecessary nowadays as support for 8 inch floppies. As for hard disks, CD ROMs etc., we know that they don't necessarily have 512 byte sectors.

[onlyonemac]

Personally I would say that support for any floppy disks is as unnecessary nowadays as support for 8 inch floppies. As for hard disks, CD ROMs etc., we know that they don't necessarily have 512 byte sectors.

I disagree. While floppies may be obsolete, they're still the easiest to use when starting out as they are easily re-writeable and relatively easy to write a driver for; burning a CD or re-imaging a hard drive every time you want to do a real-hardware test (which should be done more frequently than some OSdevvers see the value in) just doesn't seem reasonable. If one's operating system is well structured, it should be fairly simple to expand it to support other storage devices (as simple as writing a driver for those devices can be), and in such a case there's no point in removing the existing support for floppy disks as they're still useful for testing even once you've written the code to support more advanced storage devices.

[iansjack]

You don't need to re-image a hard disk to try out your new kernel; you just write the new kernel file to it. Much easier, and much more useful, than messing about with floppy disks. Most computers nowadays don't even support this outdated technology.

[onlyonemac]

You don't need to re-image a hard disk to try out your new kernel; you just write the new kernel file to it. Much easier, and much more useful, than messing about with floppy disks. Most computers nowadays don't even support this outdated technology.

So what. I have to reboot the computer into some other operating system where I can write a kernel file, fuss with writing a kernel file over the network (oops the wifi on my laptop dropped again), then reboot again? How is that better than popping a disk into one computer, writing the kernel file, popping the disk into the other computer, and pressing the reset button? No long reboots required, no fussing with the network, or anything of that sort. When your OS can't even read a partition table, it's not like you can even dual-boot the testbed - you'd have to boot it from a Linux live CD every time you want to update the kernel. Now suppose I want to test it on my other computer, so I have to get a test hard drive for that computer, dismantle the thing to put the test hard drive in, and reinstall the operating system again?

You may be insistent that floppy disks are obsolete, and I don't dispute that they are, but they still offer the simplest learning curve for a beginner and by supporting floppy disks from the outset you're in no way limiting the future capabilities of your operating system. On the other hand, you're allowing the newcomer to get to the parts that they enjoy, without having to fuss with SATA and dedicated testbeds from day one, and then once they've got a stable operating system platform they can add support for whatever hardware they want. Maybe for someone who's writing their second, or third, operating system there's no point in supporting floppy disks - after all, they've already got their testbed and a bunch of SATA driver code that they can re-use - but for a newcomer you can't dispute the attractiveness of floppy disks.

Case in point: I would not have started OSdev if I wasn't allowed to use floppy disks. At the time, I had only two computers, and one was my development machine while the other was the testbed, which had on the hard drive an existing Windows installation that I still used on a fairly regular basis. It was a simple, and enjoyable, exercise to fire up an assembler, write code to print "hello world" directly to the video memory, and write it to the first sector of a floppy disk. That's what got me started with Osdev. Nowadays I have two testbeds, one with a test hard drive and the other with a Linux installation that I use as an experimental server, but I still don't see any need to move on from floppy disks just yet.

[iansjack]

You have the boot partition for your os on your development machine. It's not rocket science.

If your OS can't read a partition table the answer is obvious.

[FallenAvatar]

...

Using an emulator is way easier, and provides much better debugging capabilities.

- Monk

[Combuster]

Using an emulator is way easier, and provides much better debugging capabilities.

every time you want to do a real-hardware test (which should be done more frequently than some OSdevvers see the value in)

I see we have a volunteer! Thanks for being our friendly example

[onlyonemac]

For your information, I do use an emulator as well. But I've seen far too many hobby OSes that *only* work on emulators because the developer didn't do enough testing on real hardware.

And implementing the reading of partition tables really shouldn't be the first task, nor do I want it to be the first task. I want something that I can call an operating system. I'd rather have an operating system that can only read floppy disks than an operating system that can boot off of anything but has nothing to do once it has booted.