| Re: [hatari-devel] Hatari hangs with NVDI when MMU is enabled |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] Hatari hangs with NVDI when MMU is enabled
- From: Uwe Seimet <Uwe.Seimet@xxxxxxxxx>
- Date: Sun, 30 Sep 2018 19:23:55 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1538328235; s=strato-dkim-0002; d=seimet.de; h=In-Reply-To:References:Message-ID:Subject:To:From:Date: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=LL2xT56ZiDVMzyySqUHS25/Wek5LyS2k7eFpOlwoi3I=; b=iTZYW2lo4uNdKfGQrcCZFi0rJNfwxS4qFAhWhGxkd6MyhDL8/GVuC25TyiYtTKvDrG dmWUnqTSSzOwalCosXAdAaFUKLXThbjaaT2ZlOJtrYDofmf73mxW2qvHAhLRJr6Me74P RNTNjI85XjA8jsOT/kvKkLckCVeC+VrMSyJam7fh0zfC6cnCUB7QxPYXk3B9LgZJInJy 2ev2A5sGlQlbCvZZKdD4CWj2GISOVym67g5UFocUif61OwTYEAzzqir50w7+o6BTV6gH 5mxNM1NV5i6AcusSkjxY7Jg89n1Sl4smA0y3RPOKyZKjF7YKZ67IOkdpjcB3M3OeDbiN 04pA==
Thank you, Christian, for this detailed analysis.
> Christian Zietz schrieb:
>
> > - NVDI also works with MMU when I tick either "Prefetch mode" or "Cycle
> > exact" in the CPU options.
> >
> > Maybe this already rings a bell with the Hatari CPU experts, otherwise
> > I'll have a deeper look later.
>
> Well, it seems like in this particular configuration (MMU = on, Prefetch
> mode = off, Cycle exact = off) something goes wrong within the CPU. More
> specifically, with the installation of NVDI's TRAP #2 handler.
>
> See below for an example. A memory dump at address 0x88 clearly shows
> that the address should be 0x0104658c which is the handler that NVDI had
> just installed before. However, after single-stepping, Hatari ends up at
> 0x0109a0f4 which incidentally is the address of the previous TRAP #2
> handler.
>
> So it seems as if Hatari uses and old (cached?) address for the TRAP #2
> handler, which in turn is unexpected to NVDI and causes it to fail in an
> endless loop.
>
> CPU=$e25508, VBL=758, FrameCycles=280444, HBL=312, LineCycles=892, DSP=N/A
> $00e25508 : 4e42 trap #2
> > m $88
> 00000088: 01 04 65 8c 00 e0 12 1c 00 e0 12 1c 00 e0 12 1c
> 00000098: 00 e0 12 1c 00 e0 12 1c 00 e0 12 1c 00 e0 12 1c
> 000000A8: 00 e0 12 1c 00 e0 12 1c 00 e0 12 1c 01 09 9e f2
> 000000B8: 01 04 4b 42 01 03 81 ba 00 e0 12 1c 00 e0 12 1c
> 000000C8: 00 e0 12 1c 00 e0 12 1c 00 e0 12 1c 00 e0 12 1c
> 000000D8: 00 e0 12 1c 00 e0 12 1c 00 e0 12 1c 00 e0 12 1c
> 000000E8: 00 e0 12 1c 00 e0 12 1c 00 e0 12 1c 00 e0 12 1c
> 000000F8: 00 e0 12 1c 00 e0 12 1c 00 00 00 00 00 00 00 00
> > s
>
> CPU=$109a0f4, VBL=758, FrameCycles=280448, HBL=313, LineCycles=0, DSP=N/A
> $0109a0f4 : 0c40 00c8 cmpi.w #$c8,d0
>
> Inserting a...
> > w 0x88 0x01 0x04 0x65 0x8c
> ... (which probably invalidates the cache) before single-stepping fixes
> the problem.
>
> With that I have to stop my investigation. Sorry! Someone else who knows
> the internals of Hatari's 68030 emulation better needs to take over here.
>
> Regards
> Christian
> --
> Christian Zietz - CHZ-Soft - czietz@xxxxxxx
> WWW: http://www.chzsoft.de/
> PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA
>
>