EmuTOS auf PAK68/2 ...

[SolderGirl]

Also ich hab jetzt gerade eine PDF zur PAK gelesen, und da steht auch das das TOS für die PAK gepatcht sein muß.
Jetzt weiß ich auch nichtmehr.

[Lukas Frank]

Ja zu der Zeit gab es noch kein TOS 2.06. Es gab nur ein 2.05, ein 1.04 und KAOS TOS ...

Ein ungepatchtes TOS 2.06 aufgeteilt in vier 27C512 Eproms auf der PAK68/2 läuft zu 100%.

[SolderGirl]

Also ich weiß ja nicht ob das vorhin untergegangen ist, aber ich hab da einen Teil des PMMU codes gefunden, der nicht richtig auskommentiert ist.
Hab das mal geändert und neu kompiliert.
Kannst es ja mal damit versuchen, vielleicht geht das.
Ansonsten wüsste ich jetzt auch nichtmehr weiter.
Und ich muß jetzt auch ins Bett.

[Lukas Frank]

Die Bootsequenz und Sprünge müssen doch beim EmuTOS anders sein als beim TOS 2.06. Da ist vielleicht der Grund, oder?

[SolderGirl]

Die Bootsequenz und Sprünge müssen doch beim EmuTOS anders sein als beim TOS 2.06. Da ist vielleicht der Grund, oder?

Ja, vermutlich.
Aber ich weiß zu wenig über die Startsequenz und wie die PAK diese modifiziert.
Das würde wohl eine ausführliche Analyse erfordern.
Man müsste genau wissen wie die PAK das Speicherlayout modifiziert, und dann die Sprünge einzeln verfolgen. Dann könnte man rausfinden, wo genau es fehl schlägt.

[czietz]

@Lukas Frank : Du hattest ja auf der EmuTOS-Liste gepostet. Warst Du der Liste auch beigetreten, sodass Du Mails bekommst, die darüber geschrieben werden?

Aktuelle Frage: Hat die PAK68/2 nur 256k-ROMs? (Also anders als die PAK/3 mit 512k?)

[Lukas Frank]

Auf die PAK68/2 gehören vier Stück 27C512 Eproms also 64kB Eproms. Es gab mal eine Händische Patchliste um ein TT TOS für die PAK68/2 zu machen. Ich vermute ein TOS 3.01. Die PAK68/2 hat vier 32pol Sockel für SRAMs oder Eproms. Ich weiss zwar noch nicht wie aber 27C010 Eproms sollten auch gehen ...

Ich bekomme die EmuTOS Mailing List Mails. Wie geht das schreiben/antworten denn genau? Ich habe zwei Mailadressen, das Mailprogramm nimmt immer wenn ich nichts weiter angebe meine AOL Adresse und das ist falsch.

[mfro]

... Wie geht das schreiben/antworten denn genau? Ich habe zwei Mailadressen, das Mailprogramm nimmt immer wenn ich nichts weiter angebe meine AOL Adresse und das ist falsch.

Schreibe an mailto:emutos-devel@lists.sourceforge.net mit der Absenderadresse, mit der Du dich dort ursprünglich mal angemeldet hast.

[Lukas Frank]

Ja das war mir schon klar. Aber wenn ich eine Mail über ein Thema bekomme kann ich dort einfach auf Antworten klicken?

[tuxie]

Ja kannst du, du musst nur schauen das der Empfänger die Maillingliste ist und nicht der Absender der Mail! Das ist wichtig ansonsten bekommt diese nicht die liste. Ich nutze Apple Mail und gehe immer auf alle antworten und lösche dann den nicht listen empfänger raus.

[Lukas Frank]

@czietz ... soll ich die 512kB Version mal probieren? Macht aber nur Sinn wenn die 512kB Version auf einer PAK68/3 läuft, oder? Ich dachte eigentlich das die 512kB Falcon only wäre?

[tuxie]

Wieso soll die 512kby Verson Falcon only sein? Die läuft doch auch im TT! Nö da ist doch eine Erkennung eingebaut auf welchem System sie läuft und parametriert sich selbst. Und auf der Pak sollte auf jedenfall die 512kbyte version drauf!

[Lukas Frank]

Ja gut aber die Frage bleibt ob die Version auf einer PAK68/3 läuft? Wenn nicht macht es keine Sinn es auf der PAK68/2 zu probieren.

[czietz]

Das lässt sich abkürzen: Ja, die 512k-Version läuft auf allen unterstützten Systemen (ST, STE, TT, Falcon, ...), sofern man den Systemen ggf. beibringt, 512k ROM zu dekodieren. Nein, die 512k-Version läuft ungepatcht nicht auf einer PAK/3, weil der magische Sprung an Adresse 0xE40030 fehlt, den TOSPatch ins PAK/3-TOS hineinpatcht.

Aber bitte lasst uns nicht abschweifen: Es geht in diesem Thread um die PAK/2, nicht? Also bitte in diesem Thread bei der PAK/2 blieben und nicht vermischen, das führt nur zu noch mehr Verwirrung!

[czietz]

Aber ich verstehe, dass auf einer PAK/2 ein ungepatches TOS 2.06 läuft, also ohne irgendwelche magischen Sprünge.

Die Frage, die ich beantwortet brauche, bevor ich mich weiter mit diesem Thema beschäftige: Wie funktioniert das mit TOS 2.06, wenn die CPU doch nach dem Reset nach $FC0030 springt?

[KarlMüller]

Aber ich verstehe, dass auf einer PAK/2 ein ungepatches TOS 2.06 läuft, also ohne irgendwelche magischen Sprünge.

Aus dem Artikel "Stufe sechs  TOS x.06 für die PAK 68/2" c't 9/1992 S. 212

Die PAK arbeitet hervorragend mit dem Universal-TOS 2.06 zusammen. ...

Mit einer derart ausgestatteten PAK startet der Rechner übrigens ohne zusätzliches Hilfsprogramm, wenn man folgende GAL-Bestückung wählt: U6 = P20_22, U12 = P20_21, J2 gesteckt. Der Trick daran: P20_22 blendet die PAK-ROMs sowohl bei $E00000 als auch bei $FC0000 ein. Wenn der 68020 seinen Resetvektor von den Hauptplatinen-ROMs (die müssen noch nicht einmal 68020-fest sein) bekommen hat, arbeitet er sich zunächst im $FC-Bereich vor, bis er über einen absoluten Sprung im $E0-Bereich landet. 

[czietz]

Danke, @KarlMüller!

Verhindern die GALs auf der PAK auch, dass die ROMs auf der Hauptplatine bei der Adresse 0xFC0000 usw. angesprochen werden? Sonst würden sich in diesem Adressbereich ja zwei ROMs melden.

[Lukas Frank]

Gerade mal aus Langeweile ein PAK68/3 gepatchtes TOS 3.06 mit dem TP306V20 Paket erzeugt probiert und auf die PAK68/2 gesteckt und funktioniert das ganze. Vermute jetzt mal das der TOS bootvorgang bei der PAK68/2 genau so abläuft wie bei der PAK68/3. Ich musste an den Jumpern nichts verändern im gegensatz zu der 27C512 Bestückung mit TOS 2.06.

[czietz]

Vermute jetzt mal das der TOS bootvorgang bei der PAK68/2 genau so abläuft wie bei der PAK68/3.

Ich wiederhole mich: Der Bootvorgang bei der PAK68/3 braucht den hineingepatchen Sprung bei Adresse $E40030. Folglich kann es bei TOS 2.06 (ungepatcht) nicht genau so ablaufen! Hier kann nur @KarlMüllers Post eine Erklärung bieten.

[Thorsten Otto]

Wie schon auf der EmuTOS-ML: bleibt immer noch die Frage, wie genau das Mapping aussieht. Das kann eigentlich nur funktionieren, wenn von vornherein TOS 2.06 ausgeführt wird, wenn auch an der falschen Addresse. Ausserdem sehe ich da am Anfang der boot-sequenz für lange Zeit keinen absoluten Sprung.

Bleibt ausserdem die Frage, wenn das so einwandfrei funktioniert, warum sie es bei der PAK/3 nicht genauso gemacht haben?