Re: [hatari-devel] Emulation of the TT second MFP

[Uwe Seimet <Uwe.Seimet@xxxxxxxxx>]

Hi,

I don't think that we may assume that FFFFFA13 is directly related to the
exception. The error message does not say so. A0 may just happen to
contain FFFFFA13. Most likely vector=0x1C means that the exception
resulted from a TRAPV, which is consistent with the "trap type 28"
message.
The SR content is 0x2000, though, i.e. V is *not* set. In theory the
error dump should contain the register contents at the time the
exception occured, so V should be set. I wonder whether TRAPV is emulated
correctly. I guess TRAPV is hardly ever used, so nobody might have
noticed issues with it yet.

Best regards

Uwe

> Le 06/05/2019 à 18:02, Uwe Seimet a écrit :
> > Hi,
> > 
> > Interesting news. I just checked the behavior of ASV, which appears to get a
> > bit further in the boot process now. There is an exception, though, please
> > see the attached screenshot.
> > 
> 
> Hi
> 
> hard to tell what went wrong with this screenshot (and I don't know ASV 
> that much) ; strange thing is that A0=FFFFFA13 in that dump, which would 
> mean it was an access to main MFP whose behaviour was not modified 
> (hopefully). But it's not sure the faulty access was made on this 
> address, one would need to see the corresponding asm code.
> 
> Nicolas
> 
> 
>