OSDev.org

Well... that is pretty much what I needed to ask... right now any way...

Detecting IDE hard drives is relatively straightforward. If you already know what controllers are present -- i.e. primary/secondary, and also, potentially, tertiary and quarternary -- then you can send IDENTIFY commands to the master and slave drives and see which drives respond. Attempt to send the command in the normal way, and put in a timeout; if you hit the timeout then the drive doesn't exist.

The best way I've found of differentiating between hard disks and CD-ROM drives is to try it as a hard disk (sending the IDENTIFY command), then, failing that, as a CD-ROM drive (sending the ATAPI IDENTIFY packet). If both of these fail then the drive isn't there and you can move onto the next one.

Detecting controllers is also easy if you're using PCI. The IDE 'chip' will appear under one PCI bus/device/function combination, with a base class = 1 and sub class = 1. This seems to imply the presence of both primary and secondary IDE controllers, but as far as I can tell, you have to assume the normal 0x1f0/0x170 port addresses and interrupts 14/15; these don't seem to appear at all under the PCI information.

If you're using ISA then you should be able to probe the ports at 0x1f0 and 0x170 (and possibly others) and see if there's anything that looks like a controller there. Or you could just ask the user to specify the controllers they have installed, or try both anyway.

As far as detecting floppy drives go, I don't know of a general method. Normal floppy drive controllers are ISA devices so you aren't going to get any PCI information out of them; you're not even going to get any luck from PnP ISA. You could probe the ports and see what works (e.g. trying to spin up every drive on the controller -- standard chips support up to 4) or, as I said before, you could ask the user what they have installed. I have to admit I've hard-coded my driver so far for a single floppy drive A.

Anyway, hope this is of some help; detecting hardware is not one of the easiest OS tasks...

When the computer boots up, the value (set value) of the drive is loaded into DL, the GPR...

Get number of floppy drives to register DL:
mov dl,0
mov ah,8
int 13h

Get number of hard drives to register DL:
mov dl,80h
mov ah,8
int 13h

This is 16-bit code, of course, and it detects only
those drives known to the BIOS.

Chris Giese wrote:
This is 16-bit code, of course, and it detects only
those drives known to the BIOS.

BTW, if you're in pmode and need this, just read
0x0040:0075 (one byte with number of HDD)
0x0040:0010 (two bytes with generic PC infos)

on AT computers (all PC are except if your PC reboot at 1980 everyday ,
the last "configuration word" is a bitfield with following infos:
bit 0: are there some floppies (if yes, see bits 6&7)
bit 1: is FPU present (should be 1 on all pentiums)
bits 4-5: video mode at boot (none, COL40, COL80, MONO80)
bits 6-7: how much floppies: (00=1, 01=2 .. 11=4)
bits 9-11: count of RS232 (COMx) interfaces
bits 14-15: count of printer (parrallel ports) installed

other bits are reserved according to my doc ("La Bible du PC, M.Tischer")

This (NASM) code is similiar to the one above but assumes that data in RAM is "random" (altered by OS stuff) at best.

Floppy Drive:
----------------
mov al,0x14 ;Command 14h of I/O port 70h is "Equipment Status Check"
out 0x70,al ;Port 70h is the RTC Command Port (CMOS access via RTC) (write only)
in al,0x71 ;Port 71h is the RTC Data I/O Port (read/write)

;Bit 0 of AL is 0h if there are no drives installed and 1h if there are drive's' installed.
;Bits 6 and 7 of AL contain the "number of installed drives", assuming Bit 0 of AL = 1h... 0x00 = 1 drive, 0x01 = 2 Drives, 0x10 = 3 Drives, 0x11 = 4 Drives

Hard Drive:
--------------
mov al,0x12 ;Command 12h of I/O Port 70h is "Hard Drive Type"
out 0x70,al ;Port 70h is the RTC Command Port (CMOS access via RTC) (write only)
in al,0x71 ;Port 71h is the RTC Data I/O Port (read/write)

;AL is divided into two significant nibbles (4-bits), nibble one (AL bits 7-4) is for "Fixed Disk 0" (C:), nibble two (AL bits 3-0) is for "Fixed Disk 1" (D:). If a nibble is 0 (0x0000), then that Fixed Disk doesn't exist. The rest of the info for the CMOS Fixed Disk is more or less useless these days (more advanced Hard Disks).

How reliable is the CMOS fixed disk info on moderns PCs? Does it still correspond to the two drives on the primary IDE channel?

How reliable is the CMOS fixed disk info on moderns PCs?

Not very, it still assumes the original IDE (Primary IDE now), the only use it really has is to quickly assertain if a drive exists at Primary Master/Slave, the specific drive info returned by that port call is obsolete. It is still enough to build a base on all x86 machines without using architecture-specific code.

Certainly it sounds more reliable to query the PCI IDE controller as to which channels are available, then detect the drives on each channel. Talking to the PCI doesn't necessarily mean calling the BIOS, since in my experience it's just as effective to probe the PCI ports directly.

You are assuming that there is a PCI to query. Like I said, this is a BASE to work on, the rest can be built up from there (PCI, DMA, etc...)

If the OP is targetting machines without a PCI bus, then he has my respect and should do whatever hacks he needs to achieve his goal. However, using PCI on machines that have it is a lot easier and more effective than the alternatives. I'd say that querying PCI for what IDE controllers are installed is only slightly more work (in terms of number of instructions) than reading the CMOS. I have some code if you want to copy-and-paste.

So you are saying that virtually all BIOS chip programmers use "hacks" to see what drives are installed?

To detect the IDE controller(s) installed, I'm betting they either use PCI, or they talk directly to the hardware. It's not really feasible to copy the way the BIOS does a lot of things because the BIOS is often very closely integrated with the chipset.

As far as detecting the actual drivers on each controller goes, I think the BIOS and the OS are in pretty much the same boat. If what's reported in the CMOS (i.e. presence/absence of drives C and D) is enough then fine. But that doesn't get you very far because you still need to check for the third and fourth IDE drives, and you need to issue the IDENTIFY command (for hard drives) or IDENTIFY packet (for CD-ROM drives) to find out what kind of device it really is. There you've got no choice, because the alternatives (looking at the BIOS settings -- 512MB limitation, or boot sector -- FAT only) really aren't feasible.

DynatOS wrote: So you are saying that virtually all BIOS chip programmers use "hacks" to see what drives are installed?

I think what he is saying is that virtually all machines (x86) today have a PCI bus.

First of all, thank you all for your replies.

Tim Robinson wrote: I have some code if you want to copy-and-paste.

That would surely be helpful. Actually, any information at all is helpful

You spoke about IDENTIFY packet for CD-ROM drives. Do you have some information on that, along with READ packet? Since I haven't found any good information about reading from a CD-ROM...