Test CPU/MMU30/30translate1 crashes on real machine
dirkwhoffmann opened this issue · 5 comments
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)
rteStrange. 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
rtsThe 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) 🤔.
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)
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:
Before installing the trap handlers in 30translate.i, try to add:
Works like a charm on the TF534 after adding your code 😎:
Closed as the MMU project is on hold.