From: broeker AT physik DOT rwth-aachen DOT de
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Allegro and interrupts
Date: 29 Mar 2000 21:18:29 GMT
Organization: Aachen University of Technology (RWTH)
Lines: 24
Message-ID: <8btrv5$5ds$1@nets3.rz.RWTH-Aachen.DE>
References: <38E25F10 DOT BA510A01 AT tiscalinet DOT it>
NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de
X-Trace: nets3.rz.RWTH-Aachen.DE 954364709 5564 137.226.32.75 (29 Mar 2000 21:18:29 GMT)
X-Complaints-To: abuse AT rwth-aachen DOT de
NNTP-Posting-Date: 29 Mar 2000 21:18:29 GMT
Originator: broeker@
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

night DOT walker AT tiscalinet DOT it wrote:
> I must call sin() inside an timer function (i can't use a LUT, would be
> too inaccurate...)
> I don't know how can i lock the function code (without knowing the size)

Not reliably or easily, but you can always lookup the size of the
sin() function, once, multiply it by a factor of 2, for a safety
margin, and lock that amount of memory.

> However the program runs very well, even if i force it to swap
> filling all the ram, and even under w95 in background with lots of
> other programs running...  On my computer, setting a timer and
> locking all but a single int makes a full crash...

Which probably means that your calls to sin() didn't actually touch
any unlocked memory. I'm not sure about the details, but this *might*
be because sin() is inlined to a single fsin assembly
instruction. Check your interrupt function's assembly output generated
by the compiler. Or it could be in the same page locked by some other
part of the code that happens to be close to it. Checking the locked
adresses agains that of sin() should help to test that.
-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.