Re: How to debug inside the BIOS and/or interrupt?

On Jul 10, 6:36 am, NoS...@xxxxxxxxxxx (Bob Masta) wrote:
Unfortunately, I'm already doing this (changing overscan color), and
it locks up during the DOS INT 21,3F (read data from file handle)
call. It just never comes back.

I should clarify this is NOT in the interrupt; this is the mainline
code. No doubt it is the interrupt firing in the middle of the disk
transfer that is doing this, but I'm at a loss as to how to prevent
the read from locking up the machine, since the interrupt has a fixed
amount of time it *must* take to execute.

Can you reduce the time the interrupt handler needs, even
as a test that doesn't yield normal functionality, to see if that
reduces the problem?

That's a good idea; I hadn't thought of that. I will do that and see
if the lock-ups still occur. I suppose I can also try testing the
"InDOS" flag (undocumented?) and NOP if DOS is active, although that
will cause significant disruption to the program (see below).

As I recall, the interrupt handler should just acknowledge the SB IRQ
and the system IRQ, and possibly change a pointer to the new
buffer the main code just filled from disk. Are you trying to
do significantly more than that?

Yes -- it's a video player, so the video data is updated during that
interrupt as well. The video update always runs in fixed time (ie. it
doesn't take longer or shorter based on input from disk) so the
current scheme -- very short disk transfers (no more than about 4K at
a time) interleaved with the audio/video update interrupt fired by the
sound blaster -- works perfectly. The problem only occurs when I
attempt better disk read speeds using larger disk transfers, such as
10K or more (ie. several chunks in one large request). This results
in the lockup after a few seconds.

One of the goals for the player was 100% perfect audio/video sync, so
that's why the video is updated in the audio interrupt. If I moved
the video update portion to the mainline disk read loop (ie.
interleaving updates with disk reads), it would undoubtedly suffer
from significant jitter, although I suppose I could offer that mode to
the user as a compatibility option.

More coding for me tonight :-)

.

Relevant Pages

  • Re: Program really slow..
    ... Then when you inside and you scroll ... low disk space and the program used to work fine. ... Sysinternals Process Explorer, and see what percentage of time is ... Interrupt related issues tend to be ...
    (microsoft.public.windowsxp.general)
  • Re: Program really slow..
    ... Then when you inside and you scroll up and down through your code it'll be REALLY slow.. ... My system has always had this low disk space and the program used to work fine. ... Sysinternals Process Explorer, and see what percentage of time is ... Interrupt related issues tend to be ...
    (microsoft.public.windowsxp.general)
  • Re: Program really slow..
    ... of the disk, and 40MB/sec near the end of the disk. ... For a simple performance benchmark, ... Sysinternals Process Explorer, and see what percentage of time is ... Interrupt related issues tend to be ...
    (microsoft.public.windowsxp.general)
  • [PATCH 2/9] V4L/DVB (5020): Fix: disable interrupts while at KM_BOUNCE_READ
    ... This means that if a disk interrupt occurs while vivi.c is using this ... that the fixmap slot now points at a different physical page. ... The net result will probably be rare corruption of disk file contents, ...
    (Linux-Kernel)
  • Re: GX1-CS5530 sound problem !!!
    ... the geode interrupt stack gets confused. ... it does take up much more system memory. ... > much CPU time and has to serve much interrupts and does video output. ...
    (comp.os.linux.embedded)