Re: [hatari-devel] Hatari and OUTSIDE (virtual memory manager)

[ Thread Index | Date Index | More Archives ]

Le 02/10/2018 à 17:25, Uwe Seimet a écrit :
I'm afraid this change does not make a difference on my machine. The
behavior is exactly as before. Even complete removing the code block and
always returning "true" did not have any effect.

If I try with ROMSPEED, it does change something.

        lea $00e00000,a0
..nom1:  ptestr #2,([8,a0]),#7,a0        ;refer to user program address space
        move.l d0,(a0)  ;enter in descriptor table

Before that "ptestr #2,([8,a0]),#7,a0" gave an exception 11 when executing this instruction. If I remove "eamode==6" then the instruction completes but the program crashes after that with a bus error on "move.l d0,(a0)" because a0=0 (and RAM location 0.l and 4.l can't be written in Atari)

According to TEMPLMON the instruction is F036 9E01 0161 0010

PTESTR DFC,([$0010,A6]),#7

mmu_op30_invea() incorrectly rejects effective address mode 6. I added
the test because previously it didn't reject all invalid addressing
modes like real CPU does and for some reason I also added one valid
addressing mode..


if (eamode == 0 || eamode == 1 || eamode == 3 || eamode == 4 || eamode
== 6 || (eamode == 7 && rreg > 1))


if (eamode == 0 || eamode == 1 || eamode == 3 || eamode == 4 || (eamode
== 7 && rreg > 1))

It should fix the unexpected f-line.

Mail converted by MHonArc 2.6.19+