Hintergrund: Wie ich ja schon im anderen Thread im Zusammenhang mit MiNT geschrieben hatte, landen auf der PAK/2 die PMMU-Instruktionen stattdessen bei der FPU. Das heißt, die PAK verhält sich, als ob in der Instruktion statt der CpID=0 (MMU) die CpID=1 (FPU) codiert wäre. Wenn ich Dein Testprogramm mal bzgl. der CpID patche(*), ergibt sich ein grundsätzlich gültiger Coprozessor-Befehl, gefolgt von etwas Unsinn, von dem aber nichts auch nur irgendeine Exception verursacht:
$0001d6fa : 7000 moveq #0,d0
$0001d6fc : (*)f238 4000 0000 fmove.l $0000.w,fp0
$0001d702 : 0000 203c ori.b #$3c,d0
$0001d706 : 0001 d670 ori.b #$70,d1
$0001d70a : 2f00 move.l d0,-(sp)
$0001d70c : 3f3c 0009 move.w #9,-(sp)
$0001d710 : 4e41 trap #1 ; Cconws
Zur Ausgabe der Meldung "no error" müsste aber folgender Code zur Ausführung kommen:
$0001d704 : 203c 0001 d670 move.l #$1d670,d0
$0001d70a : 2f00 move.l d0,-(sp)
$0001d70c : 3f3c 0009 move.w #9,-(sp)
$0001d710 : 4e41 trap #1 ; Cconws
Du siehst, dass der obige Code auf der PAK zu Cconws((char *)0x3c) führt. Und was steht an dieser Adresse?
0000003C: 0f e0 10 e2 10 e0 10 e2 11 e0 10 e2 12 e0 10 e2
0000004C: 13 e0 10 e2 14 e0 10 e2 15 e0 10 e2 16 e0 10 e2
Wenn man jetzt noch weiß, dass 0xe0 auf dem Atari der Zeichencode für α ist und 0xe2 der für Γ, dann ergibt die Meldung irgendwie Sinn.
Detail am Rande: Auch auf einem 68030 würde Dein Testprogramm vermutlich zum gleichen Fehler führen, weil Du die PMOVE-Instruktion falsch codiert hast.
$0001d6fc : f038 4000 0000 pmove $0000.w,tc
$0001d702 : 0000 203c ori.b #$3c,d0
$0001d706 : 0001 d670 ori.b #$70,d1
Korrekt wäre gewesen, siehe auch EmuTOS asmdefs.h:
$0001d6fc : f039 4000 0000 0000 pmove 0,tc
$0001d704 : 203c 0001 d670 move.l #$1d670,d0
Ich habe mir jetzt Deinen Patch für EmuTOS nicht angeguckt (und auch Dein Posting auf der Mailingliste noch nicht im Detail gelesen), aber wenn die obige Analyse irgendwelche Auswirkungen darauf hat, solltest Du Deine EmuTOS-Korrektur ggf. noch einmal anpassen.
