Real mode BIOS routine and Protect Mode

Question

I am doing some OS experiment. Until now, all my code utilized the real mode BIOS interrupt to manipulate hard disk and floppy. But once my code enabled the Protect Mode of the CPU, all the real mode BIOS interrupt service routine won't be available. How could I R/W the hard disk and floppy? Do I need to do some hardware drivers now? How could I start? Is this one of the reasons that an OS is so difficult to develop?

I know that hardwares are all controlled by reading from and writing to certain control or data registers. For example, I know that the Command Block Registers of hard disk range from 0x1F0 to 0x1F7. But I am wondering whether the register addresses of so many different hardwares are the same on the PC platform? Or do I have to detect that before using them? How to detect them??

Since I am not sure about how to R/W floppy or hard disk in Protect Mode, I have to use the BIOS interrupt to load all my necessary kernel file from floppy into memory for now. But what could I do if my kernel file exceeds the real mode 1M space limit?

For any responses I present my deep appreciation.

Update

I vaguely recall that there's a way to switch Protected Mode first and then switched back to real mode. And then we could use the BIOS routine in Protected Mode. Maybe I remember wrong. Did someone remember it right?

Answer 1

ATAPI devices use the same ports. You can emulate DPMI in order to get past the 1MB+64k limit, but yeah, learn Protected Mode.

Answer 2

If you're writing an operating system, it really needs to have device drivers for any hardware it needs to use, including the storage devices. If you want to avoid needing drivers at such an early stage, you could consider using an existing bootloader like grub, but eventually you'll need them anyway.

Answer 3

If you use legacy IDE, all of the hardware will communicate in the same fashion - you don't have to worry about writing custom drivers (though should you get far enough, you will find that even though they all say they follow the same spec, they all have their fun quirks)

http://www.t13.org/ and http://www.t10.org are where you'll find the relevant specs - if you're feeling brave, you could also write a SATA driver - you'll find the AHCI spec on Intel's website (http://www.intel.com/technology/serialata/ahci.htm)

Answer 4

It seems that your question is not how to talk to hardware (the problem device drivers would solve) because the BIOS interfaces are sufficient for you.

Rather, you need to know how to communicate between protected mode ring 0 (which has unlimited access to BIOS calls and all other privileged instructions) and protected mode ring 3 where application code usually lives. This is a system call. Pretty much all architectures run interrupt handlers in privileged mode so a software interrupt is one way of implementing system calls, x86 also provides a syscall instruction which is optimized for this purpose.

Of course, you could just run everything in ring 0 with a flat memory model where you can access all memory directly.

Ring 0/ring 3 is the x86 terminology, but all systems with an MPU support some concept of a privileged mode which allows access to memory by physical address (and for split memory-I/O architectures, access to all of I/O space).

Answer 5

While it's possible to switch between protected mode and real mode, it's almost certainly not what you'd want to do. This is how things were done on the 286 (quite clumsily, since it didn't intentionally support switching from protect mode back to real mode t all). Starting with the 386, however, they added a V86 mode which can run as a task in protected mode.

If you want to use the BIOS from protected mode, this is almost certainly the way to do things. You can basically create a V86 task, switch to it to use the BIOS, then switch back to another task to execute protected mode code.

If you want to play with this, you might want to take a look at DJGPP, which is a DOS extender (basically, a program like I just described to handle the switching into/out of a V86 task as needed to handle disk I/O and such) along with a port of a rather old version of gcc so you can write code that runs on it.

The commercial market for DOS extenders is now essentially dead, so at least one formerly commercial DOS extender (HX) is now available as open source. If you're going to play with that, you'd probably want to use it with the OpenWatcom compiler.

Edit: As far as how you read a file of more than 1 MB (for example), it's simple but clumsy: read the data in chunks, and when you've finished a read you either re-map the memory, or copy the contents, to get what you read to where you really want it, then read another chunk.

As far as talking to the hardware goes: a lot depends on whether you just want something that works to some degree, or if you want to take full advantage of the hardware that's present. Just using the basic IDE ports will let you talk to almost any hard drive that isn't really ancient -- but getting the most out of the hardware is quite a bit more work. IDE/ATAPI drives have used about a half dozen different DMA modes, each of which has to be set up slightly differently. Quite a few of those are old enough you probably don't care about them, so you might want to directly support only a couple of the newest, and for anything else fall back to basic (non-DMA) transfers.

Answer 6

The project is now an old one, but the OSKit project at Utah — which might still run on modern machines, since other late-1990s operating systems can still find the RAM and disk drives on today's PCs? — was a device-driver stack build separately from any particular operating system so that you could develop your own kernel just by writing C code.

It was kind of neat; you could compile "Hello, world." in C against OSKit and get an OS you could boot that came up and printed "Hello, world." and then halted. :-)

Anyway, if you are really doing an "OS experiment", you might want to try it out — or at least use its code as a guideline for how to get up and running with some drivers. Of course, if you're really doing less of an "OS experiment" and more of a "learn obscure facts about x86", then it might do more than you want. :-)

http://www.cs.utah.edu/flux/oskit/

Answer 7

If you'd like code to read the harddrive (or USB key) from 32-bit mode, you can find some from my OS project PwnOS. It doesn't support DMA or anything, but the basics work. Specifically, trunk/Core/IO/ATA Driver.asm contains the code for reading an ATA device, e.g. harddrive (without magic numbers! :D)

I decided not to write the code for writing a device, since I didn't want to risk it, but it's very similar. The specs can be found at the first google hit for "cottontail os dev" (you'll want the ATA/ATAPI-6 document), but they're a bit hard to follow.

If you have any more questions about it, feel free to ask. I've got code to get set up into 64-bit mode as well, as well as an assembly language editor that I specifically designed for OS development (search for Inventor IDE), in that it has built-in assembling and linking of 16-bit, 32-bit, and 64-bit code at defined addresses and file offsets. That way, you can focus on the part you're interested in, instead of the fluff.