Re: [hatari-devel] EmuTOS boot freeze with Hatari git on 040/060 + MMU

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 13/03/2024 à 21:31, Christian Zietz a écrit :
> Christian Zietz schrieb:
>
> > - According to my "git bisect" the breaking commit within Hatari is:
> >
> > commit eb4467638e926af2c3d9b4e23da9917fbbf1d2d6
> > Author: Nicolas Pomarède <npomarede@xxxxxxxxxxxx>
> > Date:   Tue Sep 19 22:36:28 2023 +0200
>
> I suppose the problem lies somewhere here: 
> https://github.com/hatari/hatari/commit/eb4467638e926af2c3d9b4e23da9917fbbf1d2d6#diff-b285c31d41bc9b04586496a1ee1f4ae69b738da8f018aa512f844c7faf41a3d4R3291.
>
> The vector number (in this case for the Timer C IRQ) is put into "nr", 
> but later on, the original value saved in "vector_nr" is used to lookup 
> the exception vector, essentially incorrectly making this interrupt an 
> autovector interrupt.
>
> Note that the code uses "nr" and "vector_nr" in multiple places. I did 
> not check if there are other places where one of the variables is used 
> incorrectly.

Hi

thanks a lot for bisecting this.

I'm the one who sent Toni a patch for WinUAE in the case where MMU is 
used, because it was not handled correctly before.

in the case of the Amiga it uses vectored interrupt, except the vectored 
interrupt doesn't change, ie nr = vector_nr, so swapping nr with 
vector_nr was not noticeable in normal Amiga use, but in the case of 
Atari it was when MFP provides its own vector

But as you notice there're several places where nr and vector_nr are 
used and it's quite possible I forgot to replace one with the other for 
correct vectored result.

I will have a look at the whole MMU part to check this.

Nicolas