dirkwhoffmann / vAmiga

vAmiga is a user-friendly Amiga 500, 1000, 2000 emulator for macOS

Home Page:https://dirkwhoffmann.github.io/vAmiga

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Test CPU/MMU30/30translate1 crashes on real machine

dirkwhoffmann opened this issue · comments

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

Expected outcome:

image

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

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

commented

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:

IMG_5079
IMG_5080

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

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

IMG_5083

Closed as the MMU project is on hold.