Re: [hatari-devel] MMU tests

[ Thread Index | Date Index | More Archives ]


Great Job Thomas, Entracte demo is really a nice demo.
It's sad there's this little speed test, because all the rest works well.

Best regards


Le 16/11/2012 00:47, Thomas Huth a écrit :
  Hi Laurent,

Am Wed, 14 Nov 2012 23:50:19 +0100
schrieb Laurent Sallafranque <laurent.sallafranque@xxxxxxx>:

While testing the new MMU, I've noticed the following messages in the
console :

Longjumping /home/laurent/Atari/hatari/src/m68000.c in 433
Gotcha! 2 /home/laurent/Atari/hatari/src/cpu/newcpu.c in 3354
Exception_mmu 00e02cde 00e02cde 00000000

I've got plenties of these 3 lines
Don't worry about these, it's just debug code indicating that an bus
error has occured - this is quite normal when a program uses paging.

Here is a copy of my console after I started hatari (I've gone into
directories, launched a demo that still doesn't work (entracte by
exa) and returned to the desktop (exa demo doesn't display anything
in the console while lauched).
That demo uses some strange time measurement code like this:

0001FC08 7000                     MOVE.L #$00000000,D0
0001FC1E 4278 0468                CLR.W $00000468
0001FC22 4a78 0468                TST.W $00000468
0001FC26 67fa                     BEQ.B #$fffffffa == $0001FC22 (T)
0001FC28 4278 0468                CLR.W $00000468
0001FC2C 7000                     MOVE.L #$00000000,D0
0001FC2E 4a78 0468                TST.W $00000468
0001FC32 6600 0006                BNE.W #$0006 == $0001FC3A (F)
0001FC36 5240                     ADD.W #$00000001,D0      ; Increase D0 during one VBL
0001FC38 60f4                     BT .B #$fffffff4 == $0001FC2E (T)
0001FADA b07c 4100                CMP.W #$4100,D0
0001FADE 6f00 00e8                BLE.W #$00e8 == $0001FBC8 (T)  ; Jump to exit when D0 too small
0001FAE2 b07c 4200                CMP.W #$4200,D0
0001FAE6 6e00 00e0                BGT.W #$00e0 == $0001FBC8      ; Jump to exit when D0 too big

In Hatari, the value in D0 is too small, so the demo aborts here.
I don't know what this is good for, maybe some kind of primitive
protection against tempering with a debugger, or a check to make sure
that the CPU runs with the right speed?
I guess we need proper Videl VBL timings first to be able to run this
demo out-of-the-box.
The good news is that this seems to be the only problem. If you
by-pass this check manually, the demo runs without further problems.


Mail converted by MHonArc 2.6.19+