OSDev.org

Steve the Pirate wrote: I find that in bochs, when I run my OS, the PIT is 2 or three times faster than usual. It works fine in a normal PC. Why is this happening? It doesn't matter yet, as at the moment it just makes the splash screen pop up for about half a second, but later when I do a floppy driver, the delays will be important, as I use a real floppy when testing in bochs.

AFAIK this is normal, it has something to do with timer calibration in bochs. Some time ago there was a thread on this board that explained how to set up bochs for real time.

About the floppy drive: I don't think you'll experience problems. Even when you configure bochs to use your real floppy drive, your OS will never touch it *directly*, bochs just forwards the requests to the host OS' floppy driver.

cheers Joe

personally i prefer to use a realy machine for tests now i get debug information when it faults, i might dig out my old serial line code for remote guru meditation to my main machine if i get bored though

The results came down without any adjustment hacks like my two instruction wrap around code, on average, 12 PIT clocks slow per second. This means within an hour (12*60*60)=43,200, rough estimate of (43,200/1,193,182)=36.2ms slow per hour, and within a day, 868.8ms. I'll give it 1 second slow per day. Worst then what I had but I have spent some time to ensure accurate results this time around, more or less. I'm just going to leave it at that. The test was based on dividing the my SystemCounter by 1193182 evenly with no fixed point or floating point used. I am too lazy to do floating point math in assembly.

blip wrote: I checked the OSFAQ and it talks about all the frequency divisions in hardware: http://www.osdev.org/osfaq2/index.php/PIT and it has some cool (though untested) example code for further accuracy on frequencies the hardware doesn't directly support but the code approximately emulates.

When I read the OSFaq it didn't have that much information about the PIT... but now I can't go back in that page for some reason. I do remember that example, and I found some considerations the author didn't take to make it most accurate.

I'm actually confused to make of all these divided-by-numbers. I have more sources that say to use 1,193,180 so I did. Sadly enough, the datasheet doesn't say anything about this. Hmm oh well.

No need to do floating point math, just A = 3579545 / ( 3 * B ) which is naturally equivalent to A = 1193181.666... / B. Either way thanks for the results.