Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
int is_fdd_present(){ // check if a valid floppy drive is present
unsigned char check;
outportb(0x70, 0x10);
check = inportb(0x71);
check = check >> 4; // Get the master fdd state
if(check==0) // if c == 0, no floppy drive found..
return 0;
else
return 1; // else, floppy drive is present
}
This works perfectly on Bochs/Qemu/Virtualbox, but on some real computers it always detect a floppy drive (even if the machine doesn't have it!)
Why ? maybe there is a better way to detect if fdd is present ?
Thank you very much
Note2: It is probably a good idea to have a reasonable delay after selecting a CMOS register on Port 0x70, before reading/writing the value on Port 0x71.
iansjack wrote:It could well be a timing issue. From the Wiki::
Note2: It is probably a good idea to have a reasonable delay after selecting a CMOS register on Port 0x70, before reading/writing the value on Port 0x71.
First of all thank you iansjack for your reply.
Well, I'm not sure how much time should I wait.. will 20ms be enough ?
EDIT: Damn, it is not a timing issue I tried to sleep for 500ms, and still get the same result on my laptop :/
That's strange because on all emulators, and on my desktop pc it works perfectly.....
Because the CMOS "belongs" to the firmware and is mostly used for storing the firmware's settings. The only CMOS locations you can really trust are the ones used by the RTC.
Luca91 wrote:maybe there is a better way to detect if fdd is present ?
Like a lot of optional legacy/ISA devices there is no good way. The "least bad" way is a combination of manual probing and expecting the user to provide correct information.
Mostly, I'd find out about all devices you can first (e.g. PCI devices), then check that nothing else is using the floppy controller's default IO ports, then see if those IO ports respond like you'd expect a floppy controller's IO ports to respond. For the first floppy controller (where there are known/default IO ports) I'd do it without asking the user. For any other floppy controllers I wouldn't do it at all unless the user has told the OS that the extra floppy controller/s exist and which IO ports (and DMA channel, IRQ, etc) they use (and then I'd still make sure no other devices are using the IO ports first, then test that the IO ports respond like they should, before assuming that the user is right).
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
...I'd also check if the ACPI tables have the "legacy free" flag set as well. If that is the case, there won't be a floppy controller (or most of the other legacy stuff either).
...I'd also check if the ACPI tables have the "legacy free" flag set as well. If that is the case, there won't be a floppy controller (or most of the other legacy stuff either).
thank you too. Can you please tell me more about the legacy free flag ? very sorry, but I haven't mess with ACPI tables yet.
...I'd also check if the ACPI tables have the "legacy free" flag set as well. If that is the case, there won't be a floppy controller (or most of the other legacy stuff either).
thank you too. Can you please tell me more about the legacy free flag ? very sorry, but I haven't mess with ACPI tables yet.
There are two bit flags.
One tells you whether you have a keyboard controller or not (If it tells you that you don't, it means it. Trying to talk to the keyboard controller will very likely hang the machine)
One tells you whether the rest of the legacy hardware (PIC, PIT, Floppy controller, DMA controller, RTC) exist. If it tells you they don't exist, they very probably don't (Unless the ACPI meat of the tables tell you otherwise - hypothetically the system might have a PIT, floppy controller, DMA controller and RTC on a Super-I/O chip, but be missing a PIC because it has some possible future PIC-less CPU/"Northbridge"/"IO Controller hub")
Hello,
I checked the exact value of the cmos response of those motherboards, and it is 4 (1.44MB 3.5'' floppy present).. I was hoping to get some inconsistent response to easily check if there is a real floppy drive connected
I read a lot about ACPI on the wiki, and if I understood correctly the only way (apart manually writing a acpi driver) is to port ACPICA.. That's cool, but I can't do it at this stage yet..
What a nasty problem....
Or perhaps realize floppies are untechnology today and purge your OS of all support? If you boot your OS from a floppy in 2014, you are doing it wrong.
Eventually I've fixed this problem in that way: I've added a timeout counter, if the floppy-ready irq doesn't arrive in a reasonable time, then disable it
I tried to sleep for 500ms, and still get the same result on my laptop :/
