X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
Date: Sat, 18 Dec 2004 16:34:30 +0200
From: "Eli Zaretskii" <eliz AT gnu DOT org>
Sender: halo1 AT zahav DOT net DOT il
To: djgpp AT delorie DOT com
Message-ID: <01c4e50e$Blat.v2.2.2$d4772f20@zahav.net.il>
Content-Transfer-Encoding: 7BIT
Content-Type: text/plain; charset=ISO-8859-1
X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 2.2.2
In-reply-to: <20041216170806.5292b039.lijon@kymatica.com> (message from
	Jonatan Liljedahl on Thu, 16 Dec 2004 17:08:06 -0200)
Subject: Re: Problems with timer interrupt chaining and SmartDrv
References: <20041215011234 DOT 44376f01 DOT lijon AT kymatica DOT com>
	<01c4e2e9$Blat.v2.2.2$7ba22de0 AT zahav DOT net DOT il>
	<20041215234645 DOT 6d15ae95 DOT lijon AT kymatica DOT com>
	<01c4e32a$Blat.v2.2.2$a3b07a80 AT zahav DOT net DOT il>
	<20041216170806 DOT 5292b039 DOT lijon AT kymatica DOT com>
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

> Date: Thu, 16 Dec 2004 17:08:06 -0200
> From: Jonatan Liljedahl <lijon AT kymatica DOT com>
> 
> > Yes, I saw that you called `disable', but as you
> > might know, this not necessarily actually disables the hardware
> > interrupt from happening.
> 
> Ok, No, I didn't know that. So how do I actually disable interrupts?

The first thing to try is a special variable, see below.  If that
doesn't help, call `__dpmi_get_and_disable_virtual_interrupt_state' in
addition to `disable'.  If that doesn't cut it either, try sending a
command to PIC to disable the IRQ0 line, and enable it before you
return from the handler.

> > I'd suggest to check whether the interrupt
> > happens while the previous one is still being processed.
> 
> How could I check this? (It hangs, so it's hard to report anything to
> the user)

Increment a static flag variable at the beginning of your handler, and
decrement it before you return.  Then, as the very first thing the
handler does, even before it increments the flag, check for its value
being non-zero.  If it is, do nothing except reporting this somehow (a
special character written to some screen position via direct access to
video memory is one possibility), and return immediately.  This might
solve the original problem, but even if it does not, you might be
lucky to see that character written before the machine hangs.

> Btw, I see there that it checks for _USE_LFN and thinks this means that
> it's running under W95, but this isn't true as I'm running under DOS
> 6.22 with a LFN driver loaded (which also sets _USE_LFN):

Doesn't the LFN driver support function 710Dh?  AFAIK, it's part of
the AH=71h family that an LFN driver should support.

In any case, calling an unsupported function of Int 21h should do no
harm: the Int 21h dispatcher should simply disregard it.  Can you
verify that in a simple test program?

> Does anyone know If it's OK to just turn the write-cache off, or should
> I tell smartdrv to flush it's cache first? (I assume it does so
> itself...)

IMHO, it's better to flush the cache explicitly.  It's so easy
programmatically to do this that I'm not sure you should even consider
not doing it.

> I don't have Windows at home, but a friend of mine has tested my program
> on a couple of windows versions. It runs on 95 and 98, but with similar
> problems. On XP it just hangs almost right away.

It figures.  Reprogramming the PIT on Windows is a tricky business,
since Windows virtualizes the PIT.

I'd consider Windows as unsuitable platform for your software.