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
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

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?

- Raw text -