Mail Archives: djgpp/2004/12/18/11:21:32
On Sat, 18 Dec 2004 16:34:30 +0200
"Eli Zaretskii" <eliz AT gnu DOT org> wrote:
> > 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.
So what DOES disable() do if it doesn't disable interrupts?
> > > 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.
I have now tried this, it didn't work. It just hangs without notice.
pseudocode:
void my_handler(void) {
if(int_overflow) {
/* write '!' in lightred to screen memory */
abort();
}
disable();
int_overflow++;
/* the stuff... */
chain_or_ACK();
int_overflow--;
enable();
}
> > 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.
I don't know... Does the LFN driver chain this to smartdrv's int to tell
it to flush?
> 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?
But it shouldn't be ignored, if I call sync() I actually want my
smartdrv to flush buffers.
One way would be to use the smartdrv int call to tell it to flush, as I
have already detected if smartdrv is running or not...
> > 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.
I agree, but some people might not want to install a plain DOS just to
run my software, so it _would_ be great if it worked. But as I said,
I've tried it on W98 and it seems to work, regarding the PIT
reprogramming! Maybe windows is clever enough to trap the PIT hardware
ports and do something smart, becouse it worked and everything ran in
the right frequency, not slowed down or something like that...
PS.
I don't get my own messages I sent to this list, is this some setting on
the list server or is something wrong?
/Jonatan -=( http://kymatica.com )=-
- Raw text -