Mail Archives: djgpp/1999/11/02/11:27:59
> 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
- Raw text -