Re: [hatari-devel] Wrong stackframe for non-autovector IRQ and CPU >= 68020

[Toni Wilen <twilen@xxxxxxxxxx>]

> So far, WinUAE cpu core only handles vector_nr (the corresponding value
> for non autovectored int) by calling the function iack_cycle().
> But this function is only called in 68000 CE mode and in Exception_normal()
> 
> But in Exception_normal, we have this final else :
> } else {
>         Exception_build_stack_frame_common(oldpc, currpc, regs.mmu_ssw,
> nr);
>         used_exception_build_stack_frame = true;
> }
> 
> the problem is that vector_nr is not passed to this function and instead
> this stores on the stack :
>     x_put_word (m68k_areg (regs, 7), (format << 12) | (nr * 4));
> 
> (in our case, format=0)
> 
> Toni, do you agree that vector_nr should be passed to
> Exception_build_stack_frame_common and Exception_build_stack_frame ?
> 
> Also, in Hatari I added a call to iack_cycle into Exception_mmu030 and
> Exception_mmu to include correct vector number in the stack in case of
> interrupt :
> 
> #ifdef WINUAE_FOR_HATARI
>         if (interrupt)
>                 nr = iack_cycle(nr);
> #endif
> 
> Maybe something similar should be added into WinUAE too (by replacing
> 'nr' directly or using 'vector_nr' too) ?

I'll think about it after bug fix release of winuae is out (next few
weeks). Also need to check Motorola documentation carefully because I am
not familiar enough with autovectored interrupts, they are not used in
Amigas.

It probably is best if you attach patch example that is tested and
confirmed working. I can't test it :)