|Re: [hatari-devel] DSP for Previous|
[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]
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/|