Re: [hatari-devel] 68030 MMU work

[Laurent Sallafranque <laurent.sallafranque@xxxxxxx>]

Hi Thomas,

No problem, I'll give it a look when the MMU work (I'll remap the cycles 
if needed).
I think the way I did it is probably not the best one (I think we should 
map the falcon 68030 way of working, ie add 2 memory access for a long, ....)
and not just precalculate everything. I've read somewhere that read 
timing is different from write timings, ...
It a part I didn't understand well when I added the new core (using 
winuae memory functions, timings, ...). Maybe this should be rewritten 
correctly.

Another question, as you're giving a look at the boot sequence of hatari :
I've noticed (with the new cpu core) that there are 2 exception 2 at 
boot sequence that we don't have with the old CPU core.
I've already investigated this, without success (I think it happens when 
we reach a illegal.l "opcode" but I'm not sure).

Maybe Nicolas fixed something in the exception functions of Hatari, but 
again, it's a part of the code I don't understand well.

Here is my boot sequence until I reach the desktop :

laurent@OrdiLolo:~/Atari/hatari/build/src$ ./hatari
Hatari v1.6.1, compiled on:  Jun 19 2012, 23:17:47
CPU cycleunit: 1 (0.500)
Building CPU table for configuration: 68030/2 ~cycle-exact 24-bit
1881 CPU functions
Building CPU, 45989 opcodes (3 -1 1)
CPU=68030, FPU=2, MMU(040)=0, JIT=0.
GEMDOS HDD emulation, C: <-> /media/0470BC8670BC7FCA/Jeux/Atari.
CPU cycleunit: 1 (0.500)
M68000 Bus Error reading at address $ff8e09.
Exception 2 (0) at e02ce2 -> e02ce6!
A-Trap a000 at e010a0 (0x1a92c60)
A-Trap a00e at e010c0 (0x1a92c80)
A-Trap a000 at fa022c (0x1c31dec)
M68000 Bus Error reading at address $f00039.
Exception 2 (0) at e01854 -> e01836!
M68000 Bus Error reading at address $f00039.
Exception 2 (0) at e01854 -> e01836!
Exception 2 (0) at 20346 -> 20356!
A-Trap a000 at 20e02 (0xcb29c2)

Regards
Laurent


Le 08/09/2012 09:49, Thomas Huth a écrit :
> Hi Laurent,
>
> I did not touch the falcon_cycle table. But I doubt that it will work
> out of the box with the MMU code since it uses a different m68k_run
> function.
>
>   Thomas
>
>
> Am Sat, 08 Sep 2012 00:08:05 +0200
> schrieb Laurent Sallafranque <laurent.sallafranque@xxxxxxx>:
>
> > Hi Thomas,
> >
> > Did you keep the falcon_cycles table I added for the 68030 "cycle
> > exact" CPU ?
> >
> > Regards
> >
> > Laurent
> >
> >
> > Le 07/09/2012 23:17, Thomas Huth a écrit :
> > > Am Sun, 2 Sep 2012 07:55:36 +0200
> > > schrieb Andreas Grabher <andreas.grabher@xxxxxxxxxxxx>:
> > >
> > > > Thanks for the suggestions! I'll look into set_x_funcs()!
> > > FYI: I've now tried to integrate your 68030 MMU work into Hatari:
> > >
> > > http://hg.tuxfamily.org/mercurialroot/hatari/hatari/rev/8521076211a3
> > >
> > > Instead of hacking cpummu.h with if-statements, I created a new
> > > "CPU level" in gencpu.c instead. I think this is a cleaner approach,
> > > and this way we get a real 68030 emulation instead of a 68040 with
> > > a 68030-MMU.
> > >
> > > Unfortunately, TOS does not boot with this new MMU yet. Seems like
> > > it is endlessly looping during the MMU set ==> this needs some more
> > > work...
> > >
> > >    Thomas