Re: [hatari-devel] DSP long interrupts fix

[Laurent Sallafranque <laurent.sallafranque@xxxxxxx>]

Hi Nicolas,

Great, finally, all advises converge and make sense.
So my current patch is OK, and can be improved with conditional jumps.
I haven't encountered any case of JScc interrup yet, I'll have to make a 
test program for this.


Thanks for the reply.
Regards
Laurent

Le 24/06/2024 à 23:22, Nicolas Pomarède a écrit :
> 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