Re: [hatari-devel] DSP long interrupts fix

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 24/06/2024 à 22:40, Laurent Sallafranque a écrit :
> Hi,
>
> I've worked again with long interrupts instruction into the DSP emulation.
> I exchanged with Tat and Mikro on DHS.NU forum about VOXXX.PRG that 
> doesn't work.
> I also exchanged with Andreas from this list.
>
> The question I asked them :
> I've got a question about SSI interrupts and stack underflow.
>
> I'm trying to improve the DSP emulation of Hatari.
> I'm playing with a program called "VoxxFree" a 16 bands vocoder.
>
> This program is built like this :
>
> SSI interrupts (Send / receive sound)
>
> p:000c jmp p:$02bb
> p:000e jmp p:$02bb
> p:0010 jmp p:$02c4
> p:0012 jmp p:$02c4
>
> p:02bb jclr #3,x:$ffee,p:$02c0
> p:02bd movep x:$ffef,x:$0001
> p:02bf rti
> p:02c0 movep x:$ffef,x:$0002
> p:02c2 bset #1,x:$0000
> p:02c3 rti
>
> p:02c4 jclr #2,x:$ffee,p:$02c9
> p:02c6 movep x:$0003,x:$ffef
> p:02c8 rti
> p:02c9 movep x:$0004,x:$ffef
> p:02cb rti
>
>
> The Motorola doc describes long interrups generated by the JSR 
> instruction, but Voxx program jumps into the interrupt process with a 
> JMP and not a JSR.
> Extract from Motorola doc :
> A long interrupt is formed if one of the interrupt instructions fetched 
> is a JSR instruction.
> The PC is immediately released, the SR and the PC are saved in the 
> stack, and the jump instruction controls where the next instruction is 
> fetched from.
> While either an unconditional jump or conditional jump can be used to 
> form a long interrupt, they do not store the PC on the stack; therefore, 
> there is no return path.
>
>
> I've modified the code to let JMP be considered as a JSR instruction in 
> the special interrupt process and this fixes the VOXXX.PRG program.
> I haven't noticed any regression.
>
> Both JMP and JSR store the PC on the stack in this special case.
> Maybe I should remove the code and save the PC to restore (as it seems 
> to be done into the DSP interrupt logic).
> Any advice here ?
>
> Maybe there's a better way to write the emulation code for this special 
> case.
> Your comments are welcome.

Hi

looking at 8.2.7 in motorola doc, I see :

"Interrupt instruction execution is considered "fast" if neither of the
instructions of the interrupt service routine cause a change of flow.
A JSR within a fast interrupt routine forms a long interrupt, which is
terminated with an RTI instruction to restore the PC and SR from the
stack and return to normal program execution."

My understanding : the doc tells "change of flow", so I think JMP could 
be considered as such. During prefetch the interrupt will then change 
from "fast" to "long" and PC/SR will be pushed automatically to the 
stack not because it's a JSR (else you would return with an rts, not an 
rti), but because it's a long interrupt.

So I think you should keep current code that pushes SR/PC on the stack, 
interrupt routine expects it as can be seen at "02fb : rti". If you 
don't push SR/PC on stack you will likely get a crash in the dsp code 
when it reaches rti and returns at a random place.

For completeness, maybe other instruction than JMP and JSR should also 
change to long interrupt mode (JScc for example).


Nicolas