Re: [hatari-devel] MMU emulation broken ?

[ Thread Index | Date Index | More Archives ]

The only strangeness I've seen so far relates to the state of CRP/SRP registers for saving/restoring MMU state.

The MMU can throw exceptions if illegal values are written to these registers - the bitfield gets sanity-checked by the CPU before the register is changed.

I noticed the initial value of SRP is garbage on the Falcon and therefore cannot be saved/restored without causing an exception. This should affect all Falcons (and Hatari).

However I found one additional (seemingly Hatari-specific) problem, which results in an incorrect value of 0 being read from CRP, which also causes an exception when restored on exit (but this doesn't happen on real hardware). This operation uses the 64bit pmove.d instruction. 

I wondered if it needs to be quadword-aligned, but haven't investigated it properly yet so I'm not sure of the real cause for difference here.

I haven't noticed any other differences so far.


On 3 September 2013 09:45, Laurent Sallafranque <laurent.sallafranque@xxxxxxx> wrote:

I wanted to try evolution demo by EXA (patched today by ggn).
It seems to need the MMU emulation to run.
But when I select MMU in hatari GUI, I get the following:

Building CPU, 45989 opcodes (3 0 1)
CPU=68030, FPU=68882, MMU=1, JIT=0.
MMU disabled
MMU enabled
Exception_mmu 00e02cde 00e02cde 00000000

And hatari stops running on the initial black screen, before starting the white (GEM) screen and the falcon memory check.

Any idea ?



Mail converted by MHonArc 2.6.19+