Test CPU/MMU30/30translate1 crashes on real machine

dirkwhoffmann commented 11 months ago

https://github.com/dirkwhoffmann/vAmigaTS/tree/master/CPU/MMU30/30translate1

Expected outcome:

On the real machine, it crashes. First guess: Something related to not flushing caches etc.

I've found this code snippet on EAB which is worth giving a try:

start
    move.w  #$4000,$dff09a
    movea.l $4.w,a6
    lea super(pc),a5
    jsr _LVOSupervisor(a6)
    move.w  #$c000,$dff09a
    rts

super
    moveq   #0,d0
    lea trap(pc),a5
    lea $10.w,a1
    lea $2c.w,a2
    movea.l (a1),a3
    movea.l (a2),a4
    move.l  a5,(a1)
    move.l  a5,(a2)
    dc.l    $4e7b0801   ;movec d0,vbr
    dc.l    $f4784e71   ;cpusha dc
    dc.l    $4e7b0002   ;movec d0,cacr
    dc.l    $4e7b0808   ;movec d0,pcr
    move.l  a3,(a1)
    move.l  a4,(a2)
    rte
trap    addq.l  #4,2(sp)
    rte

dirkwhoffmann commented 11 months ago

Strange. The test program executes this code:

setupTC:
    move.l  a4,a2
    add.l   #$2000,a2

    ; Install the Translate Control Register (TC)
    ;   8      : E = 1
    ;   0      : FCL = 0, SRE = 0
    ;   8      : PS = 256 bytes
    ;   84444  : IS = 8, TIA = 4, TIAB = 4, TIAC = 4, TIAD = 4 
    move.l  #$80884444,(a2)  

    pmove   (a2),TC

    ; At this point, the MMU is active and maps $Axxxxx to $Dxxxxx

; Added for debugging...
myloop:
    move #$F00,$AFF180
    move #$FF0,$AFF180
    jmp  myloop 

    rts

The code enables the MMU. It is set up to map $Axxxxx to $Dxxxxx which makes it possible to change the background color by writing into $AFF180 instead of $DFF180.

The myloop stuff has been added for debugging. I do see color stripes on the real machine (A500 with Terrible Fire) which means the MMU is working. However, if the myloop stuff is carried out right after the rts (in the calling function), the program crashes. This means, on the real machine, the rts does not return to the expected location. It sends the CPU to nirvana (but only on real hardware, not in UAE) 🤔.

mras0 commented 11 months ago

Where does the TF maps its fast mem in the address space? Is it in the Z3 range? It doesn't look like you're explicitly setting USP/SSP, so if SP is pointing to Z3 mapped fast mem (e.g. $6xxxxxxx) it will not translate correctly after MMU is enabled (since you ignore topmost 8 bits), and you'll be returning to some "random address" with rts.

Before installing the trap handlers in 30translate.i, try to add:

    lea     stacksetup(pc),a3
    move.l  a3,TRP0_INT_VECTOR
    trap    #0
stacksetup:
    lea     chip_stack_top,a3
    move.l  a3,sp
    sub.l   #$200*4,a3
    move.l  a3,usp

And this somewhere in chip bss:

    align 4
    ds.l    $400
chip_stack_top:

(Of course code also shouldn't be in Z3 fast, but since it's not crashing immediately that doesn't seem to be the case)

dirkwhoffmann commented 11 months ago

Where does the TF maps its fast mem in the address space?

OMG, that's it. I never thought about the upper memory area (my brain is hard-wired to the 24-bit address space of the old Amigas since I never had one the later machines 🙈). Indeed, the TF maps FastRam way beyond the 24-bit address space:

dirkwhoffmann commented 11 months ago

Before installing the trap handlers in 30translate.i, try to add:

Works like a charm on the TF534 after adding your code 😎:

dirkwhoffmann commented 8 months ago

Closed as the MMU project is on hold.

dirkwhoffmann / vAmiga

Test CPU/MMU30/30translate1 crashes on real machine #797