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