Date: Wed, 28 Feb 1996 08:31:23 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Andrew Szymkowiak <aes AT rosserv DOT gsfc DOT nasa DOT gov>
Cc: djgpp AT delorie DOT com
Subject: Re: pctime13 troubles/questions
In-Reply-To: <199602271736.MAA06762@rosserv.gsfc.nasa.gov>
Message-Id: <Pine.SUN.3.91.960228081039.11106B-100000@is>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Tue, 27 Feb 1996, Andrew Szymkowiak wrote:

>   When people ask here about interrupts and timer code, they are pointed
> to pctime13.zip.  I am trying to use this code with version 2, and have
> run into a few problems.

PCTIME13.ZIP was developed under DJGPP v1.12, so some problems might pop 
up under v2.0.

> (1) The subroutine never does anything about locking memory, nor does
> the test main set the magic crt0 flags.  It might be good to include
> an example of one of the above.

There was no memory-locking functions in v1.x (one of the causes that 
hooking hardware interrupts was unreliable in v1.x).  In v2.0, you sure 
need to use them.

> (2) Someone might want to point out that these routines will not allow
> really high interrupt rates, since the real mode routine has to perform
> two mode switches ( I think).

In v2.0, which is a DPMI-only environment, you don't need the real-mode 
handler at all, unless you must have a sufficiently high interrupt rate 
(the FAQ suggests 10KHz as the point where you should consider this).  
This is because under DPMI, hardware interrupts are always reflected to 
protected mode first, even if they happen while the processor is in real 
mode (explained in the FAQ, section 18.9).  In v1.x, which could run in 
non-DPMI setup, this was not necessarily true, so you *had* to establish 
a real-mode handler also, or you'd lose interrupts.

The FAQ list (faq200b.zip from the same place you get DJGPP) has more on 
the subject of when would you consider installing a real-mode handler, 
and how to do it, in chapter 18.

>                            If all one wants to do at interrupt time
> is count up the tick counter, wouldn't they be better off to
> allocate the tick counter out of DOS memory, and have the real mode
> routine increment it directly, and the pm mode routine increment it
> using far pointers?  (I will attempt to find time to experiment with

PCTIME is just an example, but usually people need to do some *real* work
in the handler, not just increment a counter.  If all you need to do is to
increment a counter, there are a few counters that already run on a PC and
wait for you to read them: no need for an interrupt handler at all.