OSDev.org

hi gaf,

Actually what I meant by 2 secs was that it is damn fast (probably it is around a few millis or micros). Yea I have changed my r60 - Ill mail u my code. And I found another bug - If u see my Header file u will notice that I have MOBF bit as 0x32 instead of 32 or 1<<5.

Well u read the bytes one by one. So in effect u need 3 INT's to read a single movement set(3bytes). In that case the Controller gets time b/w two INT's - so it properly sets the OBF. So try doing this - Read 0x60 and print status immediately(OBF will not be clear), then wait for sometime and again read status and u will find OBF set - That means u could get all ur bytes in 1 INT.

In my ISR by just waiting a bit u could get 3 bytes - I think that is better.

waiting for ur response.

rgds
Gandalf

Hi Gandalf
Well, I never thought about getting all 3 bytes at once because there are 3 interrupts, but now that you told me about it doesn't look like a bad idea at all to me.

I ran a small test today to see whether OBF gets set instantly:
    // Waiting for the response; print 'a' until it arrives
    while((Port::ReadByte(0x64) &output_buffer + mouse_buffer) != (output_buffer + mouse_buffer))
    console() << "a";

    // Empty the Outport
    Port::ReadByte(0x60);

    // Print 'b' until OBF gets cleared
    while(Port::ReadByte(0x64) &output_buffer)
    console() << "b";

I get quite a lot of 'a' but no 'b', so it really seems to me that the OBF gets set immediately. I somewhat got the feeling that there might be a problem with your port procedures. Could it be that you forgot a "volantile" and therfore the port value gets cached by the optimizer ?
Here's one of the trion port-class methodes:

unsigned char Port::ReadByte(unsigned short portNumber)
{
unsigned char ret;
asm volatile ("inb %%dx,%%al":"=a"(ret):"dN"(portNumber));
return(ret);
}

ragards,
gaf

wait  for all  3 bytes on one int? that doesnt sound like a good idea to me
unless  you want to restrict yourself to 386 systems

remember the controller works at (close to) the same speed on the latest P4 as it did on 386 systems but sometime that wait between bytes may sometimes be long enough for your system to task-switch through every running program and still idle before the next byte comes in

a better way(imho) is to check and see if its ready and if it is take as many as are availible and if not return and wait for another int this will minimize context-switching while also avoiding costly busy-waits (also busy-waiting in an ISR is  NOT good as a faillure could easily lock-up the computer