Message-Id: <199911021448.WAA19846@westgate.cyberway.com.sg>
From: "Rob Kramer" <robk AT pop1 DOT cyberway DOT com DOT sg>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Date: Tue, 2 Nov 1999 22:46:12 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: DMA despair.
CC: djgpp AT delorie DOT com
References: <199911020932 DOT RAA25646 AT westgate DOT cyberway DOT com DOT sg>
In-reply-to: <Pine.SUN.3.91.991102140455.21122A-100000@is>
Reply-To: djgpp AT delorie DOT com

> I'm confused.  How does the controller know that the data is there? 
> In other words, how do you tell it that it can begin working on the
> data?

Ah, for that there's a control register which I failed to mention..

> Perhaps the problem is with receiving the interrupts, rather than
> with your buffer setup.  What interrupt (which IRQ) does the board
> trigger?  (I'm not sure I understand what do you mean by ``PCI INTA#
> interrupt''.)

The IRQ is determined by the BIOS, and can be queried through a PCI 
register. The MPEG chip is the first PCI device, which is usually IRQ 
10h. I think the lack of interrupts is a symptom of my DMA-problems..

> Are you sure the call to dosmemput is okay?  How exactly is that
> coded?

(See further)
 
> > never get to refill the buffer since there's no interrupt. The controller seems 
> > to be cycling through the buffer over and over, but it doesn't do anything 
> > with it. I made a little real-mode program that dumps data to the screen, and 
> > if I run that after killing the MPEG application, it shows correct MPEG 
> > header data at 0x3000:20c0. (It's not overwritten yet, running on vanilla 
> > DOS).
> 
> I'm not sure I understand the meaning of this.  Are you telling me
> that a real-mode program that uses essentially the same code does
> work, while the DJGPP version doesn't?
> 
> Or am I to understand that the first buffer seems to be processed
> and the results put at 0x3000:20c0, but there's no interrupt for
> your application to know that it can fetch the processed data?
> 
> By ``MPEG application'' do you mean your DJGPP program that doesn't
> seem to work, or some other program?

Sorry about being unclear, the MPEG app. is the main DJGPP progam 
that fails, the real-mode thingie is just to hex-dump a bit of 
conventional memory - no DMA or MPEG involved. (I could have used 
'debug' :)

The DMA controller is programmed to DMA-read data in a cyclic way, so 
at the end of the 256k buffer it retarts at the base. Which implies 
that I have to fill the buffer in a cyclic way (a little 32k chunk 
at every IRQ 10 interrupt). 

Ignoring the issue of missing interrupts alltogether, the DMA 
controller will keep cycling through the buffer at a frequency that 
is too high. It seems the controller is scanning for a valid MPEG 
header but can't find it. So I was doubting the validity of my 
physical buffer address. But if I didn't do anything wrong in 
obtaining the 0x320c0 address, then that can't be it. It might be 
the hardware registers are set up improperly. :(

The dosmemput() call must be OK, since the correct data is still at 
the correct place after killing the MPEG app. 

Sorry, I realise my question is spinning out of control, in order for 
anyone to give me the ultimate clue he/she would need to have 
in-depth knowledge of the hardware in use. If I could  just be 
certain the I'm doing things right with the DMA physical address.. 
sigh. 

Thanks for all your help,

	Rob Kramer
	robk AT cyberway DOT com DOT sg