Re: [hatari-devel] MEMWATCH freezes Hatari

[ Thread Index | Date Index | More Archives ]

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

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:

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.


Mail converted by MHonArc 2.6.19+