OSDev.org

I found some code that someone wrote that directly
accesses the floppy drive (via ports 0x3f2, 0x3f4, etc.)
I took that code and modified to work with my o/s that is currently under development. I have my own IRQ6 handler and I use the timer interrupt to know when to turn the motor off. The rest of the code was (for the most part) a rip from a working driver. I finally got it working on Virtual PC *AND* my real computer. The problem is..... The seek fails EVERY time on my laptop computer!! It's very weird. There isn't much to a seek... You just send a 0x0f to 0x3f5, followed by a 0x00, followed by the track (cylinder) number. (And
I am checking 0x3f4, which is the status register to
make sure it is ready for the byte.)

Any ideas?? It seems as though there is hardware damage to the floppy drive in my laptop but I know there isn't because Windows 2000 and Linux can use the drive just fine! This problem is probably the most evasive of any problem I've encountered so far. What can be more simple them sending 3 bytes to the FDC?

Please let me know if anyone has a solution. Thanks very much.

Well, the fact that Windows and Linux access the drive OK (and that presumably the BIOS power-on floppy drive test passes) implies that the hardware works but that you aren't programming it correctly.

In what sense doesn't the seek work? Is the controller giving you an error code, or are you timing out waiting for an interrupt?

Tim,

What I meant by that is "you would think there was hardware damage" because the SEEK command fails. And there is NO error code. After the seek fails, I try to read the 7 status bytes and get nothing back. If it passes, I get all seven... Here is what they are (in decimal) if it works: 32,0,0,0,0,3,2

I don't get it though. How could I be programming it wrong if a seek is that simple.

What happens is the head never moves so my comparison to see if the FDC's track matches the track it should be on fails.

I just tried my code on yet another computer (not a notebook) and it worked. So, it is only my notebook computer. If you'd like, I could email you some ASM code that resets the drive and does a seek. (I have a C version and an ASM version.)

Thanks for your help.

have you taken a look at Linux's floppy driver? it seems to work well enough on laptops.

Laptops are notoriously non-standard: it is easy to write code that works on a normal PC but not a laptop. The Linux and NT drivers will have been tested extensively on all kinds of machines. If these drivers work on your laptop but yours doesn't then it definitely points at a problem with your code.

Total shot in the dark, but could it be spin up time for the disk. Kinda makes sense (As I think about it ;D) that a lap top would use lower energy cost motors, therefore spinning up slower. So maybe your command fails because the drive hasn't got up to speed yet. As I said, a total shot in the dark, it's just something that occured to me when I read the post.

Curufir

I found the problem! It is nothing any of us would ever suspect. It turned out to not be a floppy problem at all. It was a STACK problem that is only prevelant on AMD processors!! I don't know exactly why but local variables were getting messed up. I called a function with some pointers to integers to have the function fill them. (I'm using DJGPP) These values were LOCAL variables. When the function that populated them returned, the values were corrupt!! And one of these values was the TRACK number to seek to!
Here is some code:

void somefunc(int block)
{
int head,track,sector;
block2hts(block,&head,&track,&sector);

//variables (head,track,sector) are WRONG here
}

void block2hts(int block,int *head,int *track,int *sector)
{
*head = (block % (geometry.spt * geometry.heads)) / (geometry.spt);
*track = block / (geometry.spt * geometry.heads);
*sector = block % geometry.spt + 1;

//variables are OK here
}

So, the only way I was able to fix this problem was to make the variables STATIC:

static int head,track,sector;

Any ideas what happened here? There was NO problem on Intel processors! I didn't need to make these variables static on Intel processors.

Paul

Check your stack setup code in the kernel initialisation. Maybe it's wrong but the problem doesn't show up on Intel processors.

Can you tell us where you found this code or is it top secret?