[hatari-devel] DSP host interface interrupted mode : help needed

[Thomas Huth]

On Sat, 12 Sep 2009 00:21:55 +0200
Laurent Sallafranque <laurent.sallafranque at free.fr> wrote:

> I'll probably need help as the problem seems to be into the MFP (if
> I'm right).
> 
> I'm trying to let run graoumf tracker, 3d-kart, and many other
> programs that freeze.
> 
> I've detected that these 2 programs are based on graoumf tracker code.
> I've spent time trying to understand what happens and I think I've
> found something.
> 
> 1) First part : The DSP Host Interface interrupt mode:
[...] 
> The IVR is an 8-bit read/write register which typically contains the 
> exception vector num-
> ber used with MC68000 Family processor vectored interrupts. Only the 
> host processor
> can read and write this register. The contents of IVR are placed on
> the host data bus
> (H0–H7) when both the HREQ and HACK pins are asserted and the DMA
> mode is dis-
> abled. The contents of this register are initialized to $0F by a 
> hardware or software reset,
> which corresponds to the uninitialized exception vector in the
> MC68000 Family.

Ok, but that means that the 68k interrupt is triggered by the DSP
itself, so the MFP chip is not involved here!?! But then I wonder:
Which Interrupt Priority Level does this interrupt have?


> move.b #DSP_EXCEPTION, DSPIVR.w ; Number of the exception when
> move.l #soundtracking_kernel, DSP_EXCEPTION*4.w ;Host Port send a
> data to the 68030
> move.b #1, DSPHCR.w ; allow the interrupt
> move.l #DSP_EXCEPTION*4, adr_adr_inter
> 
> So, if I understand correctly, if Hreq goes to 1, 68030 should
> interrupt and jump at the address located at vector address $3F8. In
> graoupf tracker, it would jump to "soundtracking_kernel" code.
> 
> That's why Graoumf Tracker , 3d-kart and some more programs are 
> freezing, because 68030 never interrupts.

I agree with you, this really looks like there must be an interrupt
that we don't emulate yet...

> 3) What should we do ? (help needed here)
> 
> I think that we should add to the MFP a new interrupt detection :
> Hreq = 1 (bit 7 at address ($FFA202))
> In this case, value at address $ffffa203 should be read and 68030
> should interrupt at address (value * 4).

As a quick-n-dirty hack you could try to call something like this
whenever you want to trigger the interrupt:

 Exception(IoMem_ReadByte(0xffa203), m68k_getpc(),
	   M68000_EXCEPTION_SRC_INT_MFP);

For a clean solution (interrupts can be masked out and the
requests become pending), we need to know whether the interrupt is
handled via the MFP or directly. In the latter case, we need to know
the correct interrupt priority level of this interrupt.

 Thomas