Re: [hatari-devel] MEMWATCH freezes Hatari

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 11/10/2018 à 17:42, Uwe Seimet a écrit :
> > This might be due to TTram, at the moment its setting are not correctly
> > saved to memory snapshot (I already had a patch to commit for this, but
> > I was caught by these MMU problems :) )
> >
> > Can you try again with no TTRAM, only 4 or 8 MB os ST RAM : start hatari
> > with defaults, save snapshot again and try if you can restore snapshot
> > and open drive A without bombs this time ?
>
> ROMSPEED without TT-RAM? ;-) Remember, ROMSPEED copies the ROM into
> TT-RAM because on real hardware TOS executes faster when it's located in
> TT-RAM.

That was just to check that restoring a snapshot without ttram would 
work at least, to check if the problem is really with tttam 
saving/restoring or with sthg else.
Eventually, try to do a save/restore when running hatari without tt ram 
to confirm it works.

> I uploaded a full compressed log (330 MB), which I created by not using
> a snapshot but just logging everything until the double bus fault. You
> should be able to download it with this link:
>
> https://www.hddriver.net/downloads/hatari.log.gz

file downloaded. From what I see, pflusha is working, then romspeed 
create a cookie in RAM, call gemdos's super to go back to user mode. And 
it crashes here, from the trace it looks like A7 is 0 after going back 
to user mode, which is wrong ; it should have its value from earlier.

Can you try to run the test from the floppy, but add "-d ''" to the 
parameters to completely disable loading the fake cartridge code that 
emulate gemdos HD ? It doesn't mtter in my case, but maybe it changes 
sthg for you.

Nicolas