Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!sol.ctr.columbia.edu!lll-winken!cert!netnews.upenn.edu!vax1.cc.lehigh.edu!lehigh.bitnet!KRW1
From: KRW1@Lehigh
Newsgroups: comp.sys.ibm.pc.misc
Subject: RE: Fast Timer Interrupts, anyone?
Message-ID: <14109019:48:54KRW1@lehigh.bitnet>
Date: 15 Oct 90 00:48:54 GMT
Lines: 24
To: lusysnz@VAX1.CC.LEHIGH.EDU
X-Envelope-to: lusysnz

It's fairly easy to speed up the timer.  Dealing with the consequences
is another matter.  You work with the system timer by issuing the proper
command to the control register at i/o address 43h, and reading/writing
data at 40h.  The basic timer tick is .838095 usec.  The largest number
of ticks in the countdown cycle is ffffh, which is about 55 msec - the
basic timer interrupt interval.  To change to something else, first
write 34h to port 43h to indicate that you will be sending first the
low and then high order bytes of the countdown cycle.  Write those to
port 40h in succession.  That's it.  Then you can try it again after
the system hangs.

It's generally not considered a safe practice to change the timer rate -
there are many potential eyes watching and depending on it.  If you've
taken care of those possibilities, however, the other thing to consider
is that a vanilla PC probably can't interrupt every 125 usec.  500 usec
would be a better figure to shoot for if the interrupt routine is
expected to have time to do anything.  Fast 286's and 386's can handle
it without any problem, but not 808x and slow 286's.  If you just need
high timing resolution, consider an alternate approach which involves a
non-interrupt driven process that reads the timer directly.  There are
various hi-res timer routines floating around on the net.  -- Kevin

------------------------------------------------------------------
Kevin Weiner   Lehigh University Computing Center   (215) 758-3991