Hardware > Hardware (High-End)
EmuTOS auf PAK68/2 ...
czietz:
--- Zitat von: mfro am Do 24.11.2016, 08:58:43 ---Es gibt keinen vernünftigen Grund für das Testprogramm oben, das Kauderwelsch auszugeben. Da müsste "illegal instruction" stehen.
--- Ende Zitat ---
Es sei schon einmal verraten, dass ich das "Kauderwelsch" auch mit Hatari reproduzieren kann, siehe Anhang. Es gibt auch keine "Illegal Instruction"-Exception, weder in Hatari noch bei Frank. Details erzähle ich Dir später.
mfro:
... jetzt machst Du mich aber neugierig, hab' ich irgendwo Mist gebaut? ;)
czietz:
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.
mfro:
Ahja, danke für die Analyse.
Einigermaßen verzwackt das Ganze, aber sauber aufgedröselt, Hut ab und dankeschön für's Auflösen!
Es gibt also gültige PMMU-Befehle, die auf der PAK plötzlich zu gültigen FPU-Befehlen werden.
Das ist interessant, hat aber auf den EmuTOS-Patch (so er denn mal fertig ist) keinen Einfluß.
Der wird - sobald ein 020er erkannt wird - keine PMMU-Befehle mehr absetzen. Erstens werden sie nicht gebraucht, zweitens würden sie auf der PAK bloß Blödsinn anstellen und drittens würde die 68030-MMU-Befehlssequenz auch bei einem "richtigen" 68020/68851-Gespann so nicht laufen.
czietz:
--- Zitat von: mfro am Do 24.11.2016, 21:48:47 ---Es gibt also gültige PMMU-Befehle, die auf der PAK plötzlich zu gültigen FPU-Befehlen werden.
--- Ende Zitat ---
Das sah man ja auch schon an Deinem ersten Testprogramm, das bei Frank mit "no error" durchlief. Da war der fehlerhaft dekodierte Befehl wohl so, dass danach kein "Unsinn" folgte.
EDIT: Und es ist auch zu vermuten, dass im Fall von EmuTOS nicht der PMMU-Befehl an sich sondern die drauffolgenden auf der PAK/2 dann fälschlicherweise auch als Befehl dekodierten Worte zu der von Dir gefunden "illegal instruction exception" führen.
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln