On Thu, 05 Jul 2007 02:45:50 -0000, Jim Leonard <spamtrap@[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!
>
I don't have an answer to your problem, but I am curious about
your statement that the interrupt handler is told to "do nothing"
until data is again available. SB data is normally transferred via
DMA (except for a crappy old 8-bit mode), and the interrupt is
just to tell you that the DMA block is done. I don't recall how
the SB interacts with the DMA if you don't acknowledge the
interrupt to the SB... it might stall, or it might just loop on the
old contents of the DMA buffer. Is it possible that the
"do nothing" is causing the SB and the motherboard DMA
controller to get out of sync somehow? Still, I wouldn't
think this would lock up, just output garbage data to the SB.
Just a thought...
Bob Masta
D A Q A R T A
Data AcQuisition And Real-Time Analysis
www.daqarta.com
Scope, Spectrum, Spectrogram, Signal Generator
Science with your sound card!
|
