OSDev.org

I am using Bochs 2.4.5 to write a boot sector code. I use the INT 13H to read sectors from floppy. But I found that if the sector count to read > 72, the INT13 will fail. And the return code is AH=1. Why??

Bochs is not wrong, it's actually being lenient: real hardware fails much sooner. Don't read across floppy track boundaries (FDD issue), or across 64K boundaries in RAM (DMA issue). BIOSes are pretty lazy in having workarounds for those issues, that is, when they are actually possible.

AFAIK, it's actually floppy cylinder boundaries you can't read across. On a 1.44M floppy, there are 36 sectors in a cylinder. So if you start a read at head 0, sector 1 (of some cylinder) you should max out at 36 sectors. Bochs is obviously using the maximum value from a 2.88M floppy.

Many thanks guys. Does that mean that I have to implement all the high-level disk reading functions based on this crippled BIOS routine? I am planning to go into Protected Mode as soon as possible, how could I read floppy/hard driver in protected mode when BIOS is no longer an option?
Some hardware specifications could be helpful. But currently I need a general idea more. Is it as simple as writing towards and reading from some control/data registers on the hardware?

Hi,

smwikipedia wrote:I am planning to go into Protected Mode as soon as possible, how could I read floppy/hard driver in protected mode when BIOS is no longer an option?

To use your own protected mode code instead of the BIOS, you'd need to start by scanning PCI buses and doing device detection and enumeration. Then you'd implement about 30 different device drivers (floppy controller driver, IDE/ATA controller driver, AHCI/SATA controller driver, 3 or 4 USB controller drivers, lots of SCSI controller drivers), then a bunch more drivers that handle different device's that are attached to different controllers (by relying on that controller's driver). For example, for USB you'd have 3 or 4 USB controller drivers, plus at least one "generic USB storage device" driver that uses whichever USB controller driver to talk to the specific device.

If you add it all up it's probably over 100 different drivers. Of course then you'd want to add features that the BIOS doesn't really support, like proper IRQ handling (APICs, MSI), caching, software RAID, hotplug (necessary for USB, nice for other things), asynchronous I/O, prioritised I/O, system monitoring, power management, encryption, etc.

If you start with several "driver templates" (e.g. where the framework is in place and you only need to add low-level device specific stuff to it), then you might be able average a driver every 2 weeks, and it might only take you about 2 years of work if you're lucky (well, 2 years after you've got the driver API, IRQ handling, memory management, etc and the templates themselves sorted out).


Cheers,

Brendan

And read the wiki. That is where we put the specs and other info we all need for writing the pmode drivers.
http://wiki.osdev.org/FDC
http://wiki.osdev.org/ATA_PIO_Mode

Brendan wrote:Hi,

smwikipedia wrote:I am planning to go into Protected Mode as soon as possible, how could I read floppy/hard driver in protected mode when BIOS is no longer an option?

To use your own protected mode code instead of the BIOS, you'd need to start by scanning PCI buses and doing device detection and enumeration. Then you'd implement about 30 different device drivers (floppy controller driver, IDE/ATA controller driver, AHCI/SATA controller driver, 3 or 4 USB controller drivers, lots of SCSI controller drivers), then a bunch more drivers that handle different device's that are attached to different controllers (by relying on that controller's driver). For example, for USB you'd have 3 or 4 USB controller drivers, plus at least one "generic USB storage device" driver that uses whichever USB controller driver to talk to the specific device.

If you add it all up it's probably over 100 different drivers. Of course then you'd want to add features that the BIOS doesn't really support, like proper IRQ handling (APICs, MSI), caching, software RAID, hotplug (necessary for USB, nice for other things), asynchronous I/O, prioritised I/O, system monitoring, power management, encryption, etc.

If you start with several "driver templates" (e.g. where the framework is in place and you only need to add low-level device specific stuff to it), then you might be able average a driver every 2 weeks, and it might only take you about 2 years of work if you're lucky (well, 2 years after you've got the driver API, IRQ handling, memory management, etc and the templates themselves sorted out).

Cheers,
Brendan

Thanks for the roadmap info. I have the feeling that device driver is the most complex part of the OS development. And this feeling is getting stronger. Anyway, I will go on with my little OS. To support so many devices is quite off target to me. My focus is on OS theory and implementation. So my current plan is to just support a 1.44M floppy drive, a hard drive, so that I can load my OS and install it on hard drive from floppy.

So sum it up, currently I can think of my OS as composed of the following drivers:

- floppy driver
- hard disk driver
- keyboard driver

Am I missing anything? Thanks for pointing it out.

I didn't bother with a floppy driver. A serial driver (very simple to implement) and a network driver (fairly easy) might be more useful. The serial driver can be used for remote debugging.

Instead of a keyboard driver, a multiple-console driver that includes screen and keyboard is nice. Like the one in text mode Linux.

gerryg400 wrote:I didn't bother with a floppy driver. A serial driver (very simple to implement) and a network driver (fairly easy) might be more useful. The serial driver can be used for remote debugging.

Instead of a keyboard driver, a multiple-console driver that includes screen and keyboard is nice. Like the one in text mode Linux.

Many thanks for your kind information. Currently, I have just finished using bios to load file from a floppy with FAT12 file system. I am very interested in serial driver and network driver as you mentioned. Could you provide some detailed info? Or some further readings?

As to multiple-console driver, I am totally new to it. Is it some 3rd party code? I want absolute source control of my OS. Could you give me some more info about it?

Again, I am very happy to learn these new stuffs from you. Many thanks.

Hi,

smwikipedia wrote:So sum it up, currently I can think of my OS as composed of the following drivers:

- floppy driver
- hard disk driver
- keyboard driver

The most obvious thing missing is video...

However, there probably should be some sort of "device manager" that tracks the relationships between different devices/drivers (what is connected to what) and which resources different devices are using (I/O ports, IRQs, memory mapped I/O areas, etc). For example, the device manager would handle the hardware auto-detection and build a hierarchical "device tree", then start device drivers for the detected devices, then handle things like power management (e.g. so you don't send a controller to sleep while you're still using a device attached to that controller) and hot-plug (e.g. so when the user unplugs a USB hub you know which other USB devices connected to the hub were also removed).

Of course an OS is built in layers. On top of the device drivers there's extra layers - things like the networking stack, file systems, virtual terminals, etc. Applications rarely use the device drivers directly. For example an application might ask the VFS to open a file, and the VFS might ask a file system to open a file, and the file system might ask the software RAID layer to read some sectors, and the software RAID layer might ask several hard disk drivers to read some sectors, and several hard disk drivers might ask their corresponding disk controller drivers to send some "read sector" commands. That's about 4 separate layers of "stuff".

The same happens for things like video, where an application talks to a GUI, which talks to some sort of a "virtual terminal" layer, which talks to one or more video drivers (which talk to one or more monitors); and the reverse happens for things like keyboard/mouse (where the keyboard driver talks to some sort of controller (PS/2 or USB?), which talks to the "virtual terminal" layer, which might talk to some sort of Input Method Editor, which talks to the GUI, which talks to the application).


Cheers,

Brendan

smwikipedia wrote:

gerryg400 wrote:I didn't bother with a floppy driver. A serial driver (very simple to implement) and a network driver (fairly easy) might be more useful. The serial driver can be used for remote debugging.

Instead of a keyboard driver, a multiple-console driver that includes screen and keyboard is nice. Like the one in text mode Linux.

Many thanks for your kind information. Currently, I have just finished using bios to load file from a floppy with FAT12 file system. I am very interested in serial driver and network driver as you mentioned. Could you provide some detailed info? Or some further readings?

As to multiple-console driver, I am totally new to it. Is it some 3rd party code? I want absolute source control of my OS. Could you give me some more info about it?

Again, I am very happy to learn these new stuffs from you. Many thanks.

By multi-console driver I meant a driver that supports multiple keyboard/screen consoles. Let's say /dev/con1, /dev/con2 etc. that the user may switch between using a hotkey. Different applications may run on each console. Maybe use Ctrl-Alt-1 to go to the first console, Ctrl-Alt-2 for the 2nd etc.

I'm a microkernel person so I put the keyboard and screen are in the same usermode driver. In fact, the keyboard and screen are the same conceptual thing. It's just that one is input and one is output.

Brendan wrote:Hi,

smwikipedia wrote:So sum it up, currently I can think of my OS as composed of the following drivers:

- floppy driver
- hard disk driver
- keyboard driver

The most obvious thing missing is video...

However, there probably should be some sort of "device manager" that tracks the relationships between different devices/drivers (what is connected to what) and which resources different devices are using (I/O ports, IRQs, memory mapped I/O areas, etc). For example, the device manager would handle the hardware auto-detection and build a hierarchical "device tree", then start device drivers for the detected devices, then handle things like power management (e.g. so you don't send a controller to sleep while you're still using a device attached to that controller) and hot-plug (e.g. so when the user unplugs a USB hub you know which other USB devices connected to the hub were also removed).

Of course an OS is built in layers. On top of the device drivers there's extra layers - things like the networking stack, file systems, virtual terminals, etc. Applications rarely use the device drivers directly. For example an application might ask the VFS to open a file, and the VFS might ask a file system to open a file, and the file system might ask the software RAID layer to read some sectors, and the software RAID layer might ask several hard disk drivers to read some sectors, and several hard disk drivers might ask their corresponding disk controller drivers to send some "read sector" commands. That's about 4 separate layers of "stuff".

The same happens for things like video, where an application talks to a GUI, which talks to some sort of a "virtual terminal" layer, which talks to one or more video drivers (which talk to one or more monitors); and the reverse happens for things like keyboard/mouse (where the keyboard driver talks to some sort of controller (PS/2 or USB?), which talks to the "virtual terminal" layer, which might talk to some sort of Input Method Editor, which talks to the GUI, which talks to the application).


Cheers,

Brendan

Thanks for reminding. Currently I am not planning to support graphic mode. I just want to provide some character UI. I think that could make my life easier. Please correct me if I am wrong. Cause I am green hand in OS development area.

Hi,

smwikipedia wrote:Thanks for reminding. Currently I am not planning to support graphic mode. I just want to provide some character UI. I think that could make my life easier. Please correct me if I am wrong. Cause I am green hand in OS development area.

Using text video mode/s (and not allowing graphics video modes) can make some things easier (displaying ASCII), can make other things harder and uglier (try this), and can make some things impossible (different font sizes, Chinese).

It also shouldn't be used to avoid the need for a video driver; and shouldn't be used to avoid the need for some sort of virtual terminal layer.


Cheers,

Brendan