EmuTOS auf PAK68/2 ...

[Lukas Frank]

Habe mal von dem 256kB EmuTOS Snap 04042020 vier 27C512 Eproms gemacht und auf die PAK68/2 gesteckt. Die PAK68/2 bootet damit nicht. Vielleicht weiss @czietz Rat?

Es waren 120ns Eproms. Ein TOS 2.06 welches läuft sitzt auch auf 120ns Eproms. Für die PAK68/2 befindet sich da damit das 32bit TOS auf der PAK booten kann ein TOS 1.04 auf dem Rechner Mainboard.

---
# Kommandodatei fr ROMMIX:
# erstellen von 4 Eprom-Files fr 27C512
# 1 EmuTOS-IMG wird auf 4 Eproms aufgeteilt
# von Udo Overath @ KR
# (das geht auch direkt mit Pinatubo --- ms)

# Puffergr”že setzen
bufsize 256k
# Directory setzen
chdir c:\rommix\

load etos256.img 0 256k all -> 0 all
save ee.u11 64k <- 0 ee
save oe.u10 64k <- 0 oe
save eo.u9 64k <- 0 eo
save oo.u8 64k <- 0 oo

[czietz]

Das Thema hatten wir in der Vergangenheit schon mehrfach. Die TOS 1.04 ROMs auf dem Mainboard springen nach $FC0000. EmuTOS 256k liegt bei $E00000. Das PAK-TOS wird mit einem dreckigen Trick dagegen gepatcht. Sonst (also z.B. mit EmuTOS) braucht es ROMs auf dem Mainboard, die nach $E00000 zeigen, wie schon in der Anleitung zur PAK beschrieben.



Ich habe auch keine Kapazität, mich darum zu kümmern, dass das anders wird. Sorry.

[Lukas Frank]

Ich dachte das es geht weil das TOS 2.06  auf der PAK68/2 das ganz normale ist und nicht extra gepatcht. Es wurde halt nur in vier Files aufgeteilt ...

Es macht auch einen Unterschied ob PAK68/2 oder PAK68/3.

[czietz]

Dann muss mir jemand erklären, wie das mit TOS 2.06 auf der PAK2 überhaupt funktionieren kann, wenn die Mainboard-ROMs nach $FC0000 springen. Holger/@pakman vielleicht?

[SolderGirl]

@Lukas Frank kannst du es testweise mal mit dem 192k EmuTOS versuchen?
Nur um zu sehen ob es damit klappt.
Ich versuche nebenher mal das ganze manuell zu kompilieren ...

[SolderGirl]

@Lukas Frank ich habe mal ein spezielles EmuTOS compiliert:

Ich hab das target "192" modifiziert, um ein 256k ROM zu erzeugen, aber mit der FC00 Adresse.
Außerdem hab ich erweiterten CPU-Support aktiviert, ebenso SCSI, IDE und Nova Treiber.

Bitte probier das mal aus. Ich würd es ja selbst machen, hab aber keine leeren EPROMs und auch kein Löschgerät.

[Lukas Frank]

@SolderGirl .. ich verstehe den Sinn nicht. Wo ist denn der Unterschied bei dem EmuTOS außer der Startadresse?

Habe zur Gewissheit mal ein TOS 2.06 Image in Deutsch in vier Teile (EE, E0, 0E, 00)für die PAK68/2 aufgeteilt und im Eprombrenner mit den Eproms verglichen die auf der PAK stecken und da ist alles gleich. Es ist also ein Stink normales ungepatchte TOS 2.06 auf der PAK68/2. Die TOS 2.06 Startadresse ist ja die $ E.00000, also gehe ich mal davon aus das jedes TOS für die PAK dort starten muss. Man kann da auf der PAK auch nichts einstellen meine ich.

In dem Artikel aus der c´t wird das nicht genau beschrieben so wie bei der PAK68/3 aber man konnte damals ein extra angepasstes KAOS TOS für die PAK68/2 über emedia kaufen. Vielleicht ein KAOS mit der Startadresse $ E.00000?

[SolderGirl]

@Lukas Frank ja ich hab jetzt mal das modifizierte EmuTOS im Emulator getestet und da bringt es nur "Bus Error"

Ich verstehe es auch nicht. Da muss irgendein Trick dabei sein.
Es wäre soooo cool wenn das klappen würde.
Weil EmuTOS hat halt Treiber für SCSI und Nova/Vofa und sowas alles schon eingebaut.

[czietz]

Wie gesagt, @Lukas Frank, mit TOS 1.04 auf dem Mainboard springt die CPU nach $FC0000 (naja, genauer nach $FC0030). EmuTOS 256k liegt bei $E00000. Insofern kann ich mir gut vorstellen, dass das nicht funktioniert. Ich weiß nicht, warum TOS 2.06 dennoch funktioniert. Sinnvoll wäre, diese Diskussion auf der EmuTOS-Entwicklerliste zu führen, aber ich habe keine Zeit dafür.

EDIT: Danke, @SolderGirl für Deine Versuche, auch wenn sie nicht erfolgreich waren!

EDIT2: Auch der c't-Artikel zur PAK68/2 weiß nicht, wie das gehen soll, sondern schlägt ganz im Gegenteil vor, die Startadresse in den ROMs auf dem Mainboard zu ändern:

Um das neue Betriebssystem auf der PAK zu starten, gibt es zwei Möglichkeiten: entweder durch endgültiges Ändern des Reset-Vektors in den ROMS der Hauptplatine auf $E0 0000 (an Adresse $4) oder durch das abgedruckte Programm, das einem die Wahl zwischen altem und neuem TOS läßt. Es gehört an die erste Stelle im AUTO-Ordner.

Weitere Recherchen muss leider jemand anders übernehmen.

[Lukas Frank]

Na ja ob ich das verständlich machen kann in Englisch über die Mailingliste. Ich denke nicht!

Edit: Habe mal was an die Mailing List geschickt, mal schauen ...

[SolderGirl]

Ich hab da gerade mal im Archiv gesucht, und das Thema gab es 2016 schon mal in der Mailingliste.
Soweit ich verstanden habe, ist das Problem das EmuTOS Befehle benutzt, die von der PAK nicht richtig verarbeitet werden.
Es ist wohl so, das da PMMU Befehle an die FPU gegeben werden oder so.

Jedenfalls scheint es ein Problem mit EmuTOS zu sein das die Hardware anders anspricht als TOS selbst. Ein Versuch wäre noch, die CPU Unterstützung und PMMU Unterstützung komplett abzuschalten beim Kompilieren. Vielleicht hilft das?

[Lukas Frank]

Die MC68020 CPU hat keine PMMU. Die 030 hat eine. Wenn EmuTOS bei einer 020 CPU PMMU Befehle nutzt ist das ja dann falsch.

PAK ist nicht gleich PAK. Viele meinen bei PAK eine PAK68/3-030. Es gab aber eine Ur PAK mit 020CPU und einigen TTL Bausteinen, die PAK68/2 mit 020 CPU und eine PAK68/3-030 und PAK68/3-020 ...

[SolderGirl]

Ich hab gerade mal ein bisschen im Sourcecode gekramt, und das auf dem Bild gefunden.
Kann es sein, das da das #if eine Zeile früher sein müsste?
Könnte es so einfach sein?

[czietz]

Soweit ich verstanden habe, ist das Problem das EmuTOS Befehle benutzt, die von der PAK nicht richtig verarbeitet werden.
Es ist wohl so, das da PMMU Befehle an die FPU gegeben werden oder so.

Das ist nicht korrekt. EmuTOS 256k läuft fehlerfrei auf einem 68020. Bitte versteift Euch nicht darauf, dass EmuTOS hier die Ursache ist -- aller Wahrscheinlichkeit nach ist es die falsche Startadresse in den ROMs auf dem Mainboard.

Ich klinke mich aus diesem Thread jetzt aus.

[Lukas Frank]

Ja das EmuTOS Programm von Diskette gestartet läuft ja einwandfrei auf der PAK68/2 ...

[SolderGirl]

Soweit ich verstanden habe, ist das Problem das EmuTOS Befehle benutzt, die von der PAK nicht richtig verarbeitet werden.
Es ist wohl so, das da PMMU Befehle an die FPU gegeben werden oder so.

Das ist nicht korrekt. EmuTOS 256k läuft fehlerfrei auf einem 68020. Bitte versteift Euch nicht darauf, dass EmuTOS hier die Ursache ist -- aller Wahrscheinlichkeit nach ist es die falsche Startadresse in den ROMs auf dem Mainboard.

Ich klinke mich aus diesem Thread jetzt aus.

Nein, es ist nicht EmuTOS direkt, sondern das Zusammenspiel mit der PAK68/2.
Es ist wohl so, das die GALs auf der PAK keinen Unterschied machen zwischen PMMU oder FPU Befehlen. Da wird einfach alles was nicht für die CPU ist an die FPU durchgereicht.

Vermutlich weil nie jemand davon ausgegangen ist, das solche Befehle auftreten würden.
Zumindest hab ich das aus dem Thread herausgelesen:

https://sourceforge.net/p/emutos/mailman/message/35511963/

Die Lösung wäre aber eigentlich relativ einfach. EmuTOS sollte garkeine PMMU Befehle benutzen, dann kann das Problem auch nicht auftreten. Das wäre jedenfalls einfacher als die PAK zu modifizieren.

[Thorsten Otto]

Wenn ich mich richtig erinnere, bestand der Trick nicht darin, die Start-Adresse am Anfang des ROM zu ändern, sondern an Adresse $E40000.Man müsste also ein 512kROM nehmen. Zitat aus dem Patch -File für tospatch:

Code: [Auswählen]

;******************************************************************************
; Trick, damit die PAK auch mit TOS 1.xx auf dem Mainboard startet
; Kein Konflikt mehr, da der RSC-Bereich nach hinten verschoben wird
; Zim 20.12.2011
;
; - CPU l„dt nach Reset $00FC0030 als StartAdr (aus TOS 1.xx auf dem Mainboard)
; - Bei Zugriff auf $00FC0030 wird das PAK-TOS angesprochen, falls enabled
; - Adresse, die die PAK-ROMs sehen:
;   F    C    0    0    3    0      ; diese Adresse liegt am AdrBus an (hex)
;   1111 1100 0000 0000 0011 0000   ; (bin)
;   xxxx x100 0000 0000 0011 0000   ; diese Adr sieht das ROM (512 kBytes, bin)
;   x    4    0    0    3    0      ; (hex)



[czietz]

EmuTOS sollte garkeine PMMU Befehle benutzen, dann kann das Problem auch nicht auftreten.

Tut es auf einem 68020 auch nicht. Das würde sonst auf jedem 68020 gnadenlos abschmieren. Auch @Lukas Frank 's erfolgreicher Test mit der PRG-Version zeigt nochmal, dass das Problem wohl die Startadresse ist und nicht irgendwelche unverstandenen Befehle. Die wären in der PRG-Version ja ebenso drin.

Wenn ich mich richtig erinnere, bestand der Trick nicht darin, die Start-Adresse am Anfang des ROM zu ändern, sondern an Adresse $E40000.Man müsste also ein 512kROM nehmen. Zitat aus dem Patch -File für tospatch:

Soweit ich weiß, betrifft das die PAK3, die in der Tat ein gepatchtes 512k TOS braucht. Aber Frank sagt ja, ein unverändertes(!) TOS 2.06 liefe auf der PAK2. Wie das geht, soll mir mal jemand erklären. Aber erste nächste Woche, diese Woche beschäftige ich mich nicht damit.

[Lukas Frank]

Ich weiss es nicht genau aber ich denke ein ungepatchtes TOS 2.06 liefe auch auf einer PAK68/3-030. Allerdings ohne PMMU unterstütztung.

[Thorsten Otto]

Ja aber im Prinzip ist das das gleiche Problem. Entscheidender Unterschied ist wohl, daß bei einem gepatchten TOS 2.x die Addresse irgendwo in dem Bereich liegt wo normalerweise die Resource-Datei im ROM ist. Darum funktioniert das wohl auch nicht mit allen Language-Varianten.

Auf jeden Fall müsste man wohl ein bisschen mehr tuen, um EmuTOS auf diese weise zum laufen zu bekommen. Evtl.kriegt man das mit einem angepassten Linker-Script hin.

Daß ein ungepatchtes TOS 2.x auf diese Weise laufen soll kann eigentlich nicht sein, denn dann wäre ja das ganze Gehampel in Tospatch nicht notwendig. Vlt. wenns auf dem Mainboard sitzt, aber sicher nicht wenn dort ein 192k TOS  bootet.