ks26+@andrew.cmu.edu (Kenneth Sykes) (01/23/88)
INT 8H is a hardware interrupt generated by the 8253 timer at a rate of 18.2 ticks/second (approximately). The code that traps this interrupt, does whatever it has to do (which should be nothing), and then calls INT 1Ch, the user clock tick. On return from the user clock tick, INT 8H issues an EOI (End of Interrupt) command to the 8259 interrupt controller and returns. Programs that wish to attach themselves to the system timer should do so with INT 1Ch. Doing so avoids the need to write a hardware-triggered interrupt routine. The problem you have is that the system timer is a constant value - 18.2 ticks/second. To get more accuracy you would have to speed up the system clock, then muck around with INT 8H and INT 1Ch to make sure the time of day is maintained correctly - very messy. If you are going to run this programs on AT-class machines or higher, I would recommend looking at BIOS INT 15H. This is a 'potpourri' interrupt that contains, among other things, a high resolution timer call. I believe the resolution of the timer is in microseconds, which should be accurate enough for most normal applications. It can be called just like any other interrupt using int86x() or the equivalent. Hope this helps, Ken Sykes
wtm@neoucom.UUCP (Bill Mayhew) (01/26/88)
To add some fuel to the Microsoft fire... A while back I wrote a hack to reprogram the 8053 in my AT&T PC6300 so that I could boot IBM DOS on it and not have the clock gain time. Lo and behold, while Windows was running, the clock gained time. When Windows exited, the clock was back to not gaining time. The ultimate solution was to get DOS 3.2 from AT&T, and then to eventaully kick out Windows. It'll be interesting to see what little offensive things Windows 2 has in store for us. --Bill