aaron@jessica.Stanford.EDU (Aaron Wallace) (08/31/90)
I'm working on a low-level DLL that has to accelerate the system clock (INT 8h) to 22 KHz for a short time. Basically, the DLL redirects the INT 8H interrupt (using DOS call 25h), reprograms the appropriate timer channel, runs for a bit, restores the timer frequency and interrupt and exits. The interrupt handler is contained within the DLL's code segment. This works wonderfully under Standard mode--and it may be worth mentioning that the interrupt routine is run in protected mode, so accessing a lot of memory, etc, doesn't require GlobalDOSAlloc and such. Under 386 Enhanced mode, it also works--kindof. The clock runs at a much slower pace than 22 KHz. I assume that this has to do with running in a virtual machine, but it could also be that the interrupt routine is just run- ning too slowly for 22 KHz and thus interrupts are being dropped. My question: is there a bug in the virtual timer that prevents accelerating the clock to this speed (it *does* run faster than the normal 18.xx Hz.), or does it take too long for the virtual I/O handlers to run at this speed. I should mention that the interrupt routine does some very simple I/O (two port outputs to reset the timer countdown). Further (unrelated?) question: In Standard mode, within the interrupt handler I can access BP-relative parameters and locals with no problem (the BP is not changed by me ever). In Enhanced mode, accessing such variables results in an Unrecoverable System Error (*very* unrecoverable since almost all interrupts are masked off). Does Enhanced mode run interrupt handlers from a different stack, a different stack frame, or what? I'd hate to have to write a DOS-level driver for this since it seems to *almost* work as a simple DLL. Maybe I'll just live with Standard mode :-(. Aaron Wallace