Date: Sun, 23 Jul 2000 16:12:36 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Erik Berglund <erik2 DOT berglund AT telia DOT com>
cc: djgpp AT delorie DOT com
Subject: Re: GPF with system() and clock int.
In-Reply-To: <KyAe5.2195$652.79573@newsc.telia.net>
Message-ID: <Pine.SUN.3.91.1000723160854.3824B-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Sun, 23 Jul 2000, Erik Berglund wrote:

> > > Anyways, my 16-bit Turbo
> > > Pascal TSR does the same job, and it seems to work well
> > > together with gcc.
> > 
> > There's overhead associated with hardware interrupts in PM, as you
> > well know.
> 
> Do you mean that a 16-bit TSR runs slower because of overhead in
> the foreground gcc program?

No, I meant that timing considerations are different when interrupts are 
caught in RM and PM.  When a real-mode TSR catches the timer tick, it 
doesn't suffer from any slow-down.  But if a protected-mode program, such 
as your tu20, catches a timer tick, it goes to CWSDPMI, then to your 
program, then back to CWSDPMI (when you chain), which switches to RM, and 
finally to the BIOS handler.

> In order to trig the error more easily, I have modified tu20.c
> so the clock tick frequency is 256x 18.2 Hz (normally I would
> use 1x 18.2 Hz).

Does the problem happen if you don't speed up the clock?