EmuTOS auf PAK68/2 ...

[Lukas Frank]

EmuTOS 0.97 in der 256kB Version läuft nicht auf meiner PAK68/2.

TOS 1.04 ist auf dem Mainboard und TOS 2.06 auf der PAK, das läuft wie es soll.

Habe EmuTOS aufgeteilt in vier 64kB Teile und in Eproms gebrannt genau so wie beim TOS 2.06.


Woran kann es liegen das es nicht geht ?

[mfro]

 

Woran kann es liegen das es nicht geht ?

Ich denke, da müsste man erst mal rausfinden, warum es eigentlich in der Kombination TOS 1.04 und 2.06 geht.

Nach meinem Verständnis läuft der Systemanlauf so ab, daß die MMU beim Start die ersten beiden Langworte des Onboard-TOS (also 1.04) einblendet (an das TOS der PAK kommt sie ja nicht dran) und die von der CPU als initial Stack und initial PC abgeholt werden. Als initialer PC steht dann da FC0030 (wenn ich das richtig in Erinnerung habe). Der initial Stack ist nicht wichtig (den setzt TOS anschließend selbst).

Jetzt kommt's drauf an, wann die PAK das PAK-TOS aktiviert (ich würde mal annehmen, sofort).
Das TOS 2.06 auf der PAK startet bei E00000 (FC0030 liegt da also mittendrin).

Wenn die Vermutungen so richtig sind, funktioniert's mit TOS 2.06 mehr oder weniger zufällig, weil beim ST-TOS Start bei FC0030 zufällig was steht, was das TOS 2.06 sauber loslaufen läßt (und bei EmuTOS eben nicht).

[1ST1]

Genau das ist das was ich im anderen Thread meinte. Der Reset-Vektor von TOS 1.04 passt zwar zu TOS 2.06, aber nicht zu EmuTOS. Daher die Idee, auch auf die Hauptplatine mal ein EmuTOS drauf zu setzen. Aber es muss verglichen werden, ob der Reset-Vektor von 192 kB EmuTOS identisch mit dem von 256 kB EmuTOS ist. Oder man brennt sich zwei Eproms für die Hauptplatine, wo außer dem richtigen Resetvektor für EmuTOS sonst nichts drin sein muss.

[neogain]

Auf der Pak sollte doch ein 32bit Tos drauf, oder?

[Lukas Frank]

Auf der PAK ist das TOS 32-bit breit ...

Aber das ist erstmal egal.

Ich könnte das mal mit der MonSTer ausprobieren. Aber ein 192kB EmuTOS ist doch ein 1.04 und ein 256kB EmuTOS ein 2.06, oder ?

[1ST1]

192/256k ROM entscheidet darüber, welche Hardware unterstützt wird. Könnte sein dass im 256er Support für den TT-Shifter drin ist.

[tuxie]

Das ist nicht richtig, die Größe hat damit gar nix zu tun, ausser das in der kleinen version nicht alles unterstützt wird weil der Platz nicht ausreicht.

Was du mal machen könntest Frank wäre auch auf dem board ein EmuTOS zu setzen, denke das die Vektoren die verwendet werden nicht Kompatibel sind.

[mfro]

192/256k ROM entscheidet darüber, welche Hardware unterstützt wird. Könnte sein dass im 256er Support für den TT-Shifter drin ist.

Jedes EmuTOS (auch 192k) läuft auch auf dem TT. Mit dem 192k ROM wird dann halt ein ST mit 030 erkannt.

Aber ein 192kB EmuTOS ist doch ein 1.04 und ein 256kB EmuTOS ein 2.06, oder ?

Da sind die Grenzen fließend. Das 192kB EmuTOS ist einfach ein "abgestripptes" 256er, was wiederum ein eingeschränktes 512er ist. Man kann durchaus 256k ROMs in einem Falcon und das 512er in einem STe betreiben (wenn man genug Platz hat).

[KarlMüller]

Was du mal machen könntest Frank wäre auch auf dem board ein EmuTOS zu setzen, denke das die Vektoren die verwendet werden nicht Kompatibel sind.

Sinnvoller erscheint mir das zu tun was im Handbuch zur PAK 68/3 steht:

Bei allen ausser der deutschen PAK-TOS Version sind leider Start-ROMs auf dem Mainboard nötig, die in den zweiten 4 Bytes die Adress des PAK-TOS ($FEE0.0000) als Start-PC enthalten müssen (hier steht normalerweise die Adresse $00FC.0000).

Warum das mit dem deutschen PAK-TOS funktioniert kann man leicht aus den Quellen des Patch zum PAK-TOS erkennen.

[czietz]

Bei allen ausser der deutschen PAK-TOS Version sind leider Start-ROMs auf dem Mainboard nötig, die in den zweiten 4 Bytes die Adress des PAK-TOS ($FEE0.0000) als Start-PC enthalten müssen (hier steht normalerweise die Adresse $00FC.0000).

Warum das mit dem deutschen PAK-TOS funktioniert kann man leicht aus den Quellen des Patch zum PAK-TOS erkennen.

Da EmuTOS ja open-source ist, ließe sich der "Hack" aus dem deutschen PAK-TOS mit etwas Linker-Magie wohl auch dort einbauen. Oder Frank ersetzt die "Start-ROMs" wie oben beschrieben.

EDIT: Das o.g. PAK-TOS ist ja ein TOS 3.06. Muss denn TOS 2.06 überhaupt gepatcht werden, um auf Franks PAK/2 mit 68020 zu laufen?

[Lukas Frank]

Auf der PAK68/2 läuft auch ein gepatchtes TOS 3.06 (PAK Patches), das TOS 2.06 braucht nicht gepatcht zu werden. Das funktioniert so, es muss nur in vier 64kB Eproms aufgeteilt werden für die PAK68/2 ...

[1ST1]

Auf meiner PAK 68/2 (das Original, den neuen Nachbau habe ich noch nicht in Betrieb genommen) läuft ein ungepatchtes 2.06, auf der Hauptplatine sitzt ein 1.04. Das wurde seinerzeit in der c't so empfohlen, wegen der Sache mit dem Resetvektor.

[czietz]

Wenn die Vermutungen so richtig sind, funktioniert's mit TOS 2.06 mehr oder weniger zufällig, weil beim ST-TOS Start bei FC0030 zufällig was steht, was das TOS 2.06 sauber loslaufen läßt (und bei EmuTOS eben nicht).

Wenn ich das richtig interpretiere, ist die PAK so gebaut, dass der vermeintlich Zugriff auf 0xFC0030 stattdessen auf 0xE40030 führt. Daher wird in PAK-TOS 3.06 an dieser Adresse etwas gepatcht. Bei TOS 2.06 hingegen, das nur 256 kByte groß ist, ist 0xE40030 ein "Spiegel" von 0xE00030 und es klappt auf Anhieb und ohne Patch.

Das setzt natürlich voraus, dass man EPROMs verwendet, die auch wirklich (physikalisch) nur 64 kByte je Stück groß sind, damit dieser Umbruch von 0xE40030 auf 0xE00030 überhaupt stattfindet. Wenn meine Theorie aber stimmt, gibt es keinen offensichtlichen Grund, warum EmuTOS nicht zumindest starten sollte. Vielleicht hängt es sich auf, noch bevor der Bildschirm initialisiert wird?

[1ST1]

Die PAK 68/2 mappt nicht die ersten 8 (?) Bytes des Eproms auf der Pak auf die Adresse ab 0. Der Reset-Vektor für die PAK muss auf jeden Fall aus den TOS-Roms auf der Hauptplatine kommen.

[mfro]

Ah, der Wraparound. Also läuft das PAK-TOS als 256k Version wahrscheinlich da los, wo's beabsichtigt war.

Das ist jetzt nur geraten, aber ich könnte mir durchaus vorstellen, daß EmuTOS in der PAK aus den gleichen Gründen nicht läuft, die im anderen Thread zum Fehlschlag der Prozessorerkennung führen.

EmuTOS setzt (schon relativ früh, da gibt's noch keine Bildschirmausgabe) PMMU-Befehle ab (die im TOS2.06 nicht vorkommen). Wenn die Befehle in der PAK (wie diskutiert) nicht zu einem Fehler führen (obwohl gar keine PMMU vorhanden ist), kann ich mir schon vorstellen, daß EmuTOS sich daran aufhängt.

[1ST1]

Ich würde erstmal sichergehen, dass das mit dem Reset-Vektor passt. Ohne passende Einsprungadresse startet TOS garnicht. Darüber hinaus müsste man im englischen Forum mit Vincent Riviere fachsimpeln, was da los ist. Ich kann das mal initieren, denn EmuTOS wäre auch für meine zweite PAK 68/2 mal ein interessantes Thema.

[mfro]

Ich würde erstmal sichergehen, dass das mit dem Reset-Vektor passt. Ohne passende Einsprungadresse startet TOS garnicht.

Warum sollte der nicht passen?

Und wenn er nicht passen würde, warum würde EmuTOS überhaupt irgendwo laufen?

[1ST1]

Andere Boards haben das Problem nicht, denn dort wird das EmuTOS passend ausdekodiert. Das Problem ist PAK-spezifisch, sobald man das auf der PAK installierte TOS benutzt. Onbord-TOS bekommt durch MMU/GLUE den Resetvektor aus dem ROM an die ersten 8 Bytes ab Adresse 0 des 68000 Adressraums eingeblendet. Diese Adresslogik ist aber auf der PAK nicht integriert.

[Lukas Frank]

Darüber hinaus müsste man im englischen Forum mit Vincent Riviere fachsimpeln, was da los ist. Ich kann das mal initieren ...

Bitte sehr ->   http://www.atari-forum.com/viewtopic.php?f=27&t=30757

[Lukas Frank]

@pakman ... könnte vielleicht etwas dazu sagen.