Message-Id:	<199911020932.RAA25646@westgate.cyberway.com.sg>
From:	"Rob Kramer" <robk AT cyberway DOT com DOT sg>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Date:	Tue, 2 Nov 1999 17:33:05 +0800
MIME-Version:	1.0
Subject:	Re: DMA despair.
CC:	djgpp AT delorie DOT com
References:	<199911011050 DOT SAA01756 AT eastgate DOT cyberway DOT com DOT sg>
In-reply-to:	<Pine.SUN.3.91.991102095601.19809E-100000@is>
X-mailer:	Pegasus Mail for Win32 (v3.01b)
Reply-To:	djgpp AT delorie DOT com

For some reason I don't see my original mail or your reply in comp.os.msdos.djgpp.
Ah, never mind, perhaps delayed at delorie.com or elsewhere.

> Details, please!  What do you pass as SIZE to the above functions? did it
> return an error indication? how did you check that the hardware ignores
> the data? does the on-board DMA controller need any programming beyond the
> buffer address?  It is very hard to help you without these details (and
> everything else that might be relevant).

Size is 256k (262144), and the allocation works OK. The DMA controller 
only needs to know about the buffer's physical address (bit 0 & 1 hardwired 
to zero), the buffer size, whether it should be cyclic or not, and what 
stepsize I would like to use. Each 'step' report should result in a PCI INTA# 
interrupt. The chip is ignoring my data, so I haven't had a single interrupt so 
far. (You're supposed to initially fill the entire buffer from a MPG file, and 
then fill the DMA buffer out with little chunks at each report step).

> One gotcha is that _go32_dpmi_allocate_dos_memory is not documented to
> return -1 on failure: the docs says "non-zero", and it says so for a
> reason.  Perhaps the function fails, but your code doesn't know that?

Thanks, that's right. Changed it - no difference of course :)

> > Physical address equals linear address
> > in this case, right?
> Yes.

My buffer is allocated starting at DOS segment 0x320c. So I initially fill the 
buffer at 0x320c0 (linear) and pass that address to the DMA conroller. I 
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 guess this means that I'm doing something wrong in setting up the DMA 
controller and the rest of the hardware. *sigh*!

Thanks!

	Rob Kramer
	robk AT cyberway DOT com DOT sg

- Raw text -