Mint/XaAES mit 020 CPU ...

[czietz]

Sorry, aber ich habe heute nicht mehr die Muße, das alles nachzuvollziehen, wie das Coprozessor-Interface bei der PAK/2 gestrickt ist.

Ist aber letztlich egal: Wenn MiNT den 68020 auf realer Hardware nicht korrekt erkennt, muss das imho in MiNT gefixt werden. Wie EmuTOS die CPU-Erkennung macht, habe ich ja schon gepostet.

[1ST1]

Kann man nicht die CPU-Erkennung aus dem aktuellsten EmuTOS komplett in MiNT übernehmen? Dann klappts auch gleich mit Apollo.

[HelmutK]

Die Coprozessor Schnittstelle läuft doch direkt zwischen 020 und 68881 alles 32-bit breit alles ganz normal wie beim Atari TT auch. Der einzige Unterschied besteht darin über ein Steuer GAL FPU enable oder disable Jumpern zu können. Ist alles im c´t Artikel zur PAK68/2 beschrieben ...

Dann disabel doch mal die FPU. Wird die CPU dann richtig erkannt?

Aber vielleicht wäre es ohnehin besser, den 68020 über einen cache-Befehl zu identifizieren?

[Lukas Frank]

Treffer und versenkt ...

Mit der FPU disable wird die MC68020 CPU richtig erkannt und gesetzt aber mit FPU eine 030 CPU.

[czietz]

Also vermute ich mal, dass meine Theorie stimmt und das GAL (bei aktiver FPU) bei allen Coprozessor-Instruktionen -- auch denen, die an eine externe MMU gerichtet sind -- die FPU selektiert. Damit führt der Befehl, mit dem MiNT auf den 68030 testet, nicht mehr zum Fehler und Deine CPU wird fälschlicherweise als 68030 erkannt.

[HelmutK]

Ist das jetzt ein Fehler in MiNT oder in dem GAL?

[mfro]

Treffer und versenkt ...

Mit der FPU disable wird die MC68020 CPU richtig erkannt und gesetzt aber mit FPU eine 030 CPU.

Schon mal versucht, ob mit "FPU aus" EmuTOS bootet?

[czietz]

Naja, es ist dann ein Fehler im GAL, der sich aber im GAL nicht fixen lässt, weil die Signale zur Unterscheidung, ob FPU-Coprozessor oder MMU-Coprozessor angesprochen werden soll, dort nicht zur Verfügung stehen. Außerdem ist das ja nicht Franks exotische Eigenbau-Hardware sondern eine PAK, die schon etwas Verbreitung gefunden hatte. Daher wäre imho sinnvoller, die CPU-Erkennung in MiNT entsprechend anzupassen.

[pakman]

Also vermute ich mal, dass meine Theorie stimmt und das GAL (bei aktiver FPU) bei allen Coprozessor-Instruktionen -- auch denen, die an eine externe MMU gerichtet sind -- die FPU selektiert. Damit führt der Befehl, mit dem MiNT auf den 68030 testet, nicht mehr zum Fehler und Deine CPU wird fälschlicherweise als 68030 erkannt.

Volltreffer!
Die Anmerkungen von Steffen Engel, als er damals das TOS 3.06 gepatcht hat:

;* 03.12.93  Jetzt läuft es auch auf der 020 im RAM mit Warmstart.
;*           Ich sach nur: PMMU-Befehle sind auf 020 ILLEGAL!!
;*           Nix F-TRAP!!
;*
;* später:   Also, ein PMMU-Befehl ist latürnich ein F-Opcode. Damit sollte
;*           ein PMMU-Befehl in den F-Trap laufen. Wenn jedoch eine FPU
;*           vorhanden ist, so wird der F-Befehl an die FPU gereicht, die
;*           diesen jedoch abwehrt und einen ILLEGAL auslöst. Daher müssen
;*           die PMMU-Befehle mit ILLEGAL (020 mit FPU) und F-Trap
;*           (020 ohne FPU) gefangen werden.

War auf der PAK/2 schon so, ist dann aus Kompatibilitätsgründen für die PAK/3 übernommen worden.

[pakman]

Naja, es ist dann ein Fehler im GAL, der sich aber im GAL nicht fixen lässt, weil die Signale zur Unterscheidung, ob FPU-Coprozessor oder MMU-Coprozessor angesprochen werden soll, dort nicht zur Verfügung stehen.

Richtig! Es fehlen die Adressleitungen A15..A13, um FPU und MMU zu unterscheiden. Die Cp-Id für die MMU ist '000', die für die FPU habe ich gerade nicht parat. Eventuell würde schon eine der drei Leitungen alleine weiterhelfen.. Sind am GAL noch Pins frei?

Außerdem ist das ja nicht Franks exotische Eigenbau-Hardware sondern eine PAK, die schon etwas Verbreitung gefunden hatte. Daher wäre imho sinnvoller, die CPU-Erkennung in MiNT entsprechend anzupassen.

Wieder richtig! Man könnte sich ja an der CPU/FPU-Erkennung in der aktuellsten Version des PAK-TOS orientieren.. Anbei das Binärfile des PAK-TOS-Anfangs (den Quelltext müsste ich auch noch irgendwo haben.. bloß wo?)

[HelmutK]

Wäre ja nicht schlecht, wenn man eine funktionierende Lösung hätte zum Abkupfern. Daher auch meine Frage nach EmuTOS.

[tuxie]

Ich merke gerade ich brauch wieder eine Pak....

[Lukas Frank]

@pakman
@czietz

... wie sollte denn ein zusätzliches GAL in Verbindung mit U6 aussehen um die PMMU und die FPU Erkennung zu trennen ?

U6 ist vollbelegt, da ist kein Anschluss frei. Man könnte U6 mit einem zweiten GAL auf eine kleine Zwischenplatine setzen.



Wie müssen die JEDI GAL Gleichungen denn für ein neues U6 und ein Zusatz GAL aussehen ?

Und die Schaltung der beiden GALs, was fehlt lässt sich ja per Fädeldraht ranholen ...

Die Gleichungen von U6 sind dort ->    http://forum.atari-home.de/index.php?topic=13219.msg212155#msg212155

[1ST1]

Die Hardwarelösing ist sicher nett, aber nur für die wenigsten da draußen die noch eine originale PAK 68/2 haben.

Hat die PMMU nicht irgend ein Hardware-Register, was man an einer bestimmten Adresse auslesen kann? Mit vorhersehbarem Inhalt, auf den man prüfen kann?

[pakman]

Wäre ja nicht schlecht, wenn man eine funktionierende Lösung hätte zum Abkupfern. Daher auch meine Frage nach EmuTOS.

Anbei der Quelltext für den Anfang des PAK-TOS. Damit werden 020 und 030 mit und ohne FPU auf der PAK sicher erkannt. Vielleicht kannst Du da was übernehmen..
(Da der seinerzeit verwendete Turboassembler nur den 68000er Befehlssatz kennt, sind die ganzen 020er und 030er Befehle als DC.W codiert..)

[pakman]

... wie sollte denn ein zusätzliches GAL in Verbindung mit U6 aussehen um die PMMU und die FPU Erkennung zu trennen ?
Die Gleichungen von U6 sind dort ->    http://forum.atari-home.de/index.php?topic=13219.msg212155#msg212155

Eine zusätzliche Adressleitung reicht!
Man könnte einen der Jumper opfern..
Wie ist Dein Jumper Setting für J2, J3, J4?
Auf welche Umschaltmöglichkeit könntest Du verzichten?

[Lukas Frank]

- J2 offen: Die System-ROMs sind auf der Hauptplatine, auf die im verkürzten Buszyklus (fünf Takte) zugegriffen wird.
- J2 gesteckt: Es wird im GAL U6 bestimmten Speicherbereich kein cycle_00 und ROMSel erzeugt. Der 68020 erwartet einen
32 Bit breiten ROM/RAM-Bereich auf der PAK, auf den er ohne Waitstate zugreift.
- J3 offen: Adreßbits A29 und A30 werden ausgewertet (kompatibel zur alten PAK).
- J3 gesteckt: A29 und A30 werden ausmaskiert, damit wird ein Hängen des Rechners bei unsauberer Software (z. B. Mac-
ROMs), die die oberen acht Adreßbits als Flags mißbraucht, verhindert.
- J4 offen: FPU vorhanden
- J4 gesteckt: Beim Ansprechen der (nicht vorhandenen) FPU wird /BERR erzeugt (wichtig für Amiga).

J4 brauche ich denke ich mal. J2 und J3 sind bei mir gesetzt, also auf GND ...

Vielleicht ein 22V10 und die Funktion von J2 und J3 intern fest auf GND Level setzen ?

[HelmutK]

Anbei der Quelltext für den Anfang des PAK-TOS. Damit werden 020 und 030 mit und ohne FPU auf der PAK sicher erkannt. Vielleicht kannst Du da was übernehmen..
(Da der seinerzeit verwendete Turboassembler nur den 68000er Befehlssatz kennt, sind die ganzen 020er und 030er Befehle als DC.W codiert..)

Danke. Wie ich schon vorschlug: Cache-Features testen (wenn ich das richtig sehe):

Code: [Auswählen]


            dc.l $4E7A0002          ;     ; MOVEC CACR,D0   falls kein Illegal:
            bset      #9,D0               ; Datencache on
            dc.l $4E7B0002          ;     ; MOVEC D0,CACR       CACR schreiben
            dc.l $4E7A0002          ;     ; MOVEC CACR,D0       CACR lesen
            bclr      #9,D0               ; ist Datencache noch on?
            beq.s     E003D4              ; nein: ist 68020

Kann das mal einer in MiNT (arch/detect.S#279) einbauen?

[Lukas Frank]

Eine zusätzliche Adressleitung reicht!

Habe mal das neue GAL U6_2 probiert und mit TOS 2.06 läuft alles normal aber mit FPU bombt MiNT beim booten mit mehr als 10 Bomben ab. Ich kann die nicht Zählen, die sind so schnell wieder weg und der Rechner bootet ohne MiNT weiter.

Mit der FPU disable geht MiNT ...


Ich habe A13 von der 68000 Stiftleiste geholt und auf den Jumper Pin von J2 gelegt der zum GAL U6 Pin 11 führt. Den Pullup Widerstand von 4,7k habe ich einseitig ausgelötet damit er nicht zusätzlich die Adressleitung A13 belastet.

[pakman]

Habe mal das neue GAL U6_2 probiert und mit TOS 2.06 läuft alles normal aber mit FPU bombt MiNT beim booten mit mehr als 10 Bomben ab.

TOS 2.06 bootet mit FPU also problemlos, schon mal gut.
Hast Du dann auch mal ein Programm getestet, das die FPU tatsächlich benutzt?
Erst dann wissen wir, dass unter TOS 2.06 alles korrekt funktioniert..