On 5 Jul, 03:45, Jim Leonard <spamt...@[EMAIL PROTECTED]
> wrote:
> Some of you may remember me with my 808x questions from a while back.
> I've put all that into an audio/video player for an old IBM PC (google
> "8088 Corruption" for more info). I'm now trying to improve the
> performance of the player, and running into some very odd things that
> I can't figure out and was hoping someone might have some advice on
> how to debug my program.
>
> Background: The basic method of operation of the program is to drive a
> Sound Blaster off of IRQ 2 (hard drive is IRQ 5), and the SB interrupt
> handler pulls video and audio data out of a queue and displays/sounds
> them. In the foreground, the main program is in a loop that
> constantly tries to pull data from the hard disk and stuff it into the
> queue. If memory fills up, the main program loop pauses. If memory
> empties, the interrupt handler is told to "do nothing" until memory is
> full with video/audio data again. There is unfortunately some shared
> code (memory handling) between the main loop and the interrupt
> handler, so I prevent re-entrancy problems by wrapping the shared
> pieces in the main disk load loop with CLI/STI.
>
> Currently, only one audio/video chunk is read per disk access, and the
> program works. I tried to optimize it today by having the disk
> ****tion read more than one audio/video chunk at a time. This
> dramatically improves disk performance, but now the program locks up
> after a random period of time seemingly INSIDE the INT 21,3f call to
> read data from a file handle. I know this because I stuck various
> "printf"s (not really, but you get the idea) before certain sections
> of code, and the last thing I can see is the "marker" right before the
> disk read.
>
> How can I debug this sort of thing? I've tried to break the operation
> of the program when it hangs in both D86 and Turbo Debugger, but being
> on the 8088 there's no hardware virtualization and the machine does
> not respond to my keypress. How did people debug interrupt handlers,
> BIOS functions, etc. "back in the day"?
>
> I can provide full source to anyone who's willing to look at it, if it
> will help... It's Turbo Pascal 7.0 with inline assembler and highly
> commented. Any advice is appreciated!
What kind of signaling are you using to determine when your buffer is
empty and full? Are you sure you are not getting a classic producer/
consumer semaphore contention where it is possible for the buffer to
think its both full and empty at the same time? When you are dealing
with single chunks its essentially an asynchronous operation but once
you start reading multiple chunks into a buffer and then extracting
from a buffer it introduces synch problems. The shared code section is
probably the danger zone. You should separate file read and buffer
read operations into critical regions to avoid any possibilty of
contention - see Tannenbaums Fundamentals of OS's for a full
explanation.
P.S. are you the same Jim Leonard I remember from the IBasic bbs/
Einstein club?
|
