Re: [hatari-devel] MMU tests

[laurent.sallafranque@xxxxxxx]

Hi Thomas,

Thanks for the explanation.


> 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.

Great, I'll patch it for myself to have a look at it.


> I guess we need proper Videl VBL timings first to be able to run this
demo out-of-the-box.

Yes, but as usual, to have good Videl (and crossbar) timings, we need perfect CPU timings, and the main work is still there for now.
I think the patch I wrote last year was not the best approach (it's not integrated into the MMUCPU, it change change, ...).

Maybe now, we could remote all this code of mine and add a correct cpu timings code ?
(it's a huge work to do, but it would pay at the end (I guess))


A last question : shouldn't cpummu.c be renamed into cpummu040.c ?
(It would be cleaner and closer to reality from my point of view).

Regards
Laurent




----- Mail original -----
De: "Thomas Huth" <th.huth@xxxxxx>
À: hatari-devel@xxxxxxxxxxxxxxxxxxx
Envoyé: Vendredi 16 Novembre 2012 00:47:16
Objet: Re: [hatari-devel] MMU tests


 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.

 Thomas