Re: [hatari-devel] DSP for Previous

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 04/06/2015 11:42, Andreas Grabher a écrit :
> Luckily it turned out that the mode bits in the system control register
> are inverted. So mode 2 is mode 1 and that is the one that is implemented.
>
> With some additions to the code (some bits in ICR seemed to be ignored)
> now at least it does something.
> Maybe some of these changes are useful for Hatari too (see appended
> file). I'd be glad if someone could check them for correctness.
>
> btw. It seems to me that Hatari is releasing the HREQ interrupt in a
> wrong way. DSP should release it, not CPU.

Hi

I confirm the way HREQ was handled so far was wrong. It worked before 
when using the old UAE cpu core, but that's because this cpu used a 
simplified shortcut for the DSP level 6 interrupt.

When rewritting MFP and DSP level 6 interrupt for the recent WinUAE cpu, 
the method used in the DSP didn't work, because as you also noticed, the 
hreq signal is not correctly cleared.

Previously, hreq was set when bits 0/1 were set in both ISR and ICR, and 
it was cleared when the exception was processed.

But in the game "Chainz" for example, the mp3 dsp player will set 
RXDF=1, so the cpu gets an exception. But during the exception the 
received data is read (so RXDF=0), but we receive another data (so 
RXDF=1) which set another level 6 pending interrupt that was not cleared 
after the RTE, even if the interrupt handler read the data and RXDF was 
back to 0 again.

This means that after the RTE a new level interrupt was immediately 
started, but there was nothing to read anymore on the host port, so the 
cpu was waiting forever.

As described in the DSP doc, the correct way to update HREQ is to set it 
when bit 0 or 1 are set in ISR and ICR, and to clear it when both bits 0 
and 1 are cleared in ISR (or masked in ICR). It's not the fact that the 
DSP exception is processed in the CPU that clears HREQ, it's when bits 
0/1 are cleared in ISR.

Also, the HREQ signal should only be updated when we have a 0->1 or a 
1->0 transition.

Hopefully, this doesn't break anything.

Nicolas