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

[Uwe Seimet <Uwe.Seimet@xxxxxxxxx>]

By the way, before the crash Hatari reports this:

WARN : Write to unimplemented RTC/NVRAM interrupt enable bits 0x40

> 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
> > 
> > 
> > 
> 
>