Int13h question(Disks in general)

[Warmaster199]

I have heard that Int 13h can only touch memory regions below the 1MByte region... What about transfering kernels to beyond that memory area, such as the 16MByte region. What about loading device drivers such as disk drivers(I know - I/O is 16MBytes and below). How can your kernel load a disk driver into the "below 16MByte" if you want to keep conventional memory free(dos-emu) if Int 13h can only load the lower 1MByte. How does GRUB load kernels(An internal disk driver?)?

If I was to load a disk driver into memory, would I have to use Int13h to load it to Conv. mem., then use the disk driver to load it's copy into higher memories then delete itself?

I am very confused here. This last method of loading a disk driver seems very inefficient. I need to figure out how I am to do this...

Thanks in advance

[Tim]

If all you're doing is loading the disk and FS drivers and the kernel at boot time, it should be OK to load them into low memory (do you plan on having them longer than 64KB?). Failing that, you could switch to unreal mode, load a group of sectors into a buffer in low memory using int 13h, and copy the data to extended memory yourself.

I wouldn't recommend using int 13h outside of the loader; definitely don't use it inside the disk driver itself.

[Warmaster199]

I wrote up some stuff last night on paper. The plan I came up with was a v86 Int13h disk driver built into the kernel. This would be left in the vast expanse of kernel memory, replaced by the loaded disk driver.

With the memory manager installed, I guess I could use Int13h to load the disk drivers (As well as FS drivers) into low memory and then copy the pages into the higher memory. After loading the disk drivers and filesystems, I'll ditch the Int13h.

Is there another BIOS call I could use?(Don't feel like looking through 1000's of interrupts)

[Tim]

Better: ditch the V86-based disk driver and write one that talks directly to the hardware. Modify the boot loader to load not only the kernel, but also the disk and file system drivers. An int 13h-based disk driver isn't worth the effort. Writing an IDE or floppy driver is easier than writing a V86 monitor, and it will be faster (no real-mode code involved) and mode flexible (you'll be able to load data to anywhere in memory).

[Warmaster199]

That, my friend, is the problem. I can't write direct hardware drivers because what if someone has a SCSI-based disk? The IDE part will not run a SCSI drive. Int13h, however can access both IDE and SCSI disks. With a full IDE/SCSI Combo driver loaded in memory, sometimes it's too much space used.

I need to detect the disk-types installed and then load the driver for it. It's too much for the startup module(what the bootcode will load) to detect everything. I know it's a bit slower this way, but I will have more accurate disk drivers(various types of SCSI drivers, IDE drivers, floppy drivers...). It will only be slow by about 3 seconds even on a 486-based PC. I bet even windows loads the disk drivers this way(Not a good piece for an argument :-\)

[Tim]

That, my friend, is the problem. I can't write direct hardware drivers because what if someone has a SCSI-based disk?

Most people use IDE drives, so to begin with, an IDE driver will be sufficient. If you do come across somebody who doesn't own any IDE drives at all, you could write them a SCSI driver, or even one that used int 13h.

The IDE part will not run a SCSI drive. Int13h, however can access both IDE and SCSI disks. With a full IDE/SCSI Combo driver loaded in memory, sometimes it's too much space used.

The Windows 2000 IDE drivers amount to about 30KB. That's not big, even by DOS standards. I don't have any SCSI drives in this machine but I can't imagine them being much bigger.

I need to detect the disk-types installed and then load the driver for it. It's too much for the startup module(what the bootcode will load) to detect everything. I know it's a bit slower this way, but I will have more accurate disk drivers(various types of SCSI drivers, IDE drivers, floppy drivers...). It will only be slow by about 3 seconds even on a 486-based PC.

Keep a list of boot-time drivers in a configuration file. Have the loader read the config file and load them (using int 13h) at the same time as the kernel.

I bet even windows loads the disk drivers this way(Not a good piece for an argument :-\)

Windows NT/2000/XP do exactly what I've just described. Hey, even Linux does something similar, by having the boot drivers compiled into the kernel or in a ramdisk.

Here's why you shouldn't use int 13h in a protected-mode OS:

• Writing a good V86 monitor takes more time and effort than writing a floppy or IDE driver
• V86-mode code is harder to debug
• The BIOS code is written with a real-mode OS in mind; it will poll for I/O completion, which means that you can't do any other processing while the disk is in use
• You will need to vector disk controller IRQs to the V86 code
• Memory allocation will be a mess, since you will have to reserve memory in the bottom 1MB for any process that does disk I/O
• BIOS code is likely to use PIO instead of the much faster DMA modes

For an example of pmode operating systems that use the BIOS for disk access, look at Windows 3.x, Windows 95,98,Me and Atheos. Atheos in particular has suffered from using the BIOS for disk I/O (it's slow). The fact that Win9x lets you use DOS or the BIOS to access hardware is a major contributing factor to its instability.

[Warmaster199]

OK. Temporarily, I'll use just a floppy and IDE driver.

I'll need a V86 monitor anyways as I want to be able to run DOS programs on CTOS.

You just might have saved me alot of trouble... thanks