Hi fre, 06,.01.2006 kl. 00.18 +0100, skrev Salvo Isaja: > On Thursday 05 January 2006 10:32, Hanzac Chen wrote: > > So, can it sense the pit has been reprogrammed by external > > application automatically, and recover from that? Or we have to ask > > the > > application to support us? > > Reprogramming the PIT is such a common practice for DOS applications > that I guess the only solution is to either use the default PIT > frequency, and hope our handler will be called by the application evem > of it sets its own handler (as DOS does), This wouldn't be good enough for many (native) RT applications, though one could maybe switch to the low DOS frequency before running a DPMI app and switch back when exiting, and hope that no one needs to multitask a native RT app and a 16-bit/DPMI app.
> or virtualize the PIT. I think it would be hard to implement PIT virtualization that would be good enough for everyone that might want to write/run DPMI RT apps. I am planning to add APIC timer support to the kernel, in which case the apps could mess around with the PIT as they liked, but it doesn't even exist in old 386 and 486 processors. The HPET is available on even fewer computers, and I'm not sure if the PIT would be available independently of the HPET. I suppose we should rely on configurability to try to make as many users as possible happy. Nils ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ freedos-32-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-32-dev
