Re: [hatari-devel] DSP for Previous

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Attachment: dsp.zip
Description: Zip archive

Am 01.07.2015 um 23:37 schrieb 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
> 

I also rewrote the interrupt system of the DSP itself, because i got stuck DSP interrupts using the old method. It should be much more realistic now. I appended the files to this message. I think it can be adapted quite easily to Hatari. You will need to re-implement the SSI interrupts with the new method, but i think that won't be difficult.

I have used the updated DSP for some time now with Previous and I have no problems with the new interrupting system.


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/