From: michael DOT mauch AT gmx DOT de (Michael Mauch)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: PCTIME13
Date: Mon, 27 Oct 1997 18:56:44 +0100
Organization: Gerhard-Mercator-Universitaet -GH- Duisburg
Lines: 41
Message-ID: <3454a78b.5869285@news.uni-duisburg.de>
References: <3453BC56 DOT 55A6 AT nospam DOT usa DOT net> <3455600a DOT 1637974 AT news DOT uni-duisburg DOT de> <34548FFF DOT 4CF4 AT nospam DOT usa DOT net>
NNTP-Posting-Host: ppp82.uni-duisburg.de
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

On Mon, 27 Oct 1997 06:58:39 -0600, Mark Slagell
<bald_soprano AT nospam DOT usa DOT net> wrote:

> Michael Mauch wrote:
> > > What I'm trying to get, ultimately, is a reliable 200hz interrupt.
> > 
> > On plain DOS you can use the libc function uclock(), on Windows/Win95
> > you can use the puclock() function that is in the DJGPP mail archives
> > at www.delorie.com (search for puclock()).
> 
> That would provide a high-resolution timer, but not an interrupt per se,
> or would it?

Yes, uclock() is only a timer function, but that is no real difference
if the interrupt handler function only updates a timer variable to make
high resolution timing possible. And IMHO there's not much more that you
can do safely and easily inside a timer interrupt handler. I doubt that
all of the libc functions are reentrant; most DOS functions are not
reentrant unless you look at the InDos flag.
 
> I can get PCTIME running at the right speed by removing this line from
> pm_new8h():
>   ++ticks_8h;
> 
> So it would seem that under Windows, both the protected mode and real
> mode handlers get called with every timer tick, and under DOS only the
> real mode handler gets called.

On my machine I get illegal instruction message boxes from Win95
when/after using test8.exe, so it seems to be not very safe anyways. I
don't know in which case which of the handlers (real mode or protected
mode) is called, but one thing that is obviously a no-no in Windows95 is
trying to reprogram the timer chip like it's done in the init8h()
function. Windows95 reprograms the timer chip itsself every now and
then, so attempts from user programs to do so will fail or at least give
no reliable results. The uclock() function has this same problem, but
puclock() uses a Windows function so it doesn't have to reprogram the
timer chip.

Regards...
		Michael