atari-home.de - Foren
Hardware => Hardware (High-End) => Thema gestartet von: Lukas Frank am Mo 06.04.2020, 14:09:32
-
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 fr ROMMIX:
# erstellen von 4 Eprom-Files fr 27C512
# 1 EmuTOS-IMG wird auf 4 Eproms aufgeteilt
# von Udo Overath @ KR
# (das geht auch direkt mit Pinatubo --- ms)
# Puffergre 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
-
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.
(https://forum.atari-home.de/index.php?action=dlattach;topic=15863.0;attach=25290;image)
Ich habe auch keine Kapazität, mich darum zu kümmern, dass das anders wird. Sorry.
-
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.
-
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?
-
@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 ...
-
@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.
-
@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?
-
@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.
-
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.
-
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 ...
-
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?
-
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 ...
-
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?
-
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.
-
Ja das EmuTOS Programm von Diskette gestartet läuft ja einwandfrei auf der PAK68/2 ...
-
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.
-
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:
;******************************************************************************
; 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 ldt 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)
-
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.
-
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.
-
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.
-
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.
-
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%.
-
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.
-
Die Bootsequenz und Sprünge müssen doch beim EmuTOS anders sein als beim TOS 2.06. Da ist vielleicht der Grund, oder?
-
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.
-
@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?)
-
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.
-
... 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.
-
Ja das war mir schon klar. Aber wenn ich eine Mail über ein Thema bekomme kann ich dort einfach auf Antworten klicken?
-
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.
-
@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?
-
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!
-
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.
-
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!
-
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?
-
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.
-
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.
-
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.
-
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.
-
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?
-
Also wäre die Lösung eigentlich auf dem Mainboard spezielle ROMs zu platzieren, die nichts anderes als einen absoluten Sprung an den Anfang des EmuTOS enthalten?
Quasi als "Bootloader"?
-
Ich kann das nicht ausprobieren aber selbst eine PAK68/3 läuft mit einem ungepatchten original TOS 2.06 meine ich ...
--- aus einem c´t Artikel ---
Atarisch
Die PAK/3-020 läuft unter TOS 2.06 problemlos, was im Prinzip auch für die 030er PAK gilt. Da TOS 2.06 jedoch nichts von der
Existenz einer MMU und eines CPU-internen Datencache weiß, kann es in bestimmten Situationen Probleme geben, so zum
Beispiel bei einigen Plattentreibern mit eingeschaltetem Datencache. Im TT fällt das nicht weiter auf, weil dort die MMU vom
TOS 3.06 entsprechend programmiert wird. Daß es aber auch anders geht, zeigt AHDI, der auch auf einer PAK/3-030 unter
TOS 2.06 ohne MMU-Unterstützung einwandfrei läuft.
Des weiteren gibt es noch einige Programme, etwa Treiber für virtuelles RAM, die die MMU verwenden, diese aber in genau
dem Zustand vorfinden möchten, wie sie vom TOS 3.06 im TT initialisiert wird. Bei TOS 2.06 kann diese MMU-Initialisierung
durch ein kleines Programm im Auto-Ordner nachgeholt werden, womit dann auch solche Programme laufen.
Leider handelt man sich damit ein weiteres (kleines) Problem ein: Ein über die Tastatur ausgelöster Kaltstart führt zum
Aufhängen des Rechners, denn TOS 2.06 löscht dabei den gesamten Speicher und mithin auch die MMU-Tabelle. Die CPU
trifft zwar in der Startup-Sequenz des TOS auf einen RESET-Befehl, womit die gesamte Hardware des Rechners (auch der L2-
Cache) zurückgesetzt wird. Der interne Status der CPU bleibt davon jedoch unberührt, die MMU und die beiden CPU-Cache
sind nach wie vor aktiv, was dann auch prompt in die Hose geht.
-
Bleibt ausserdem die Frage, wenn das so einwandfrei funktioniert, warum sie es bei der PAK/3 nicht genauso gemacht haben?
Ich vermute, das hat mit der ROM-Größe zu tun.
PAK mit 512k-ROMs:
$FC0030 (binär 1111 1100 0000 0000 0011 0000)
=> umgemappt auf $E40030 (binär 1110 0100 0000 0000 0011 0000), dort muss der "magische" Sprung stehen.
PAK mit 256k-ROMs:
$FC0030 => auch umgemappt auf $E40030, aber da es die Adressleitung A18 für $4xxxx bei diesen ROMs einfach nicht gibt => weiter umgemappt auf $E00030. Funktioniert dann natürlich nur wenn man echte 256k-EPROMs nimmt, nicht wenn man 512k-EPROMs nimmt und davon nur die untere Hälfte programmiert.
@Lukas Frank : Da Du ja auf der Liste mitliest, weißt Du, dass Roger einen Vorschlag für einen Test gemacht hat. Willst Du entsprechende ROMs testen?
-
Also wäre die Lösung eigentlich auf dem Mainboard spezielle ROMs zu platzieren, die nichts anderes als einen absoluten Sprung an den Anfang des EmuTOS enthalten?
Quasi als "Bootloader"?
Das entspricht dem Vorschlag, den auch die c't abgedruckt hatte ("durch endgültiges Ändern des Reset-Vektors in den ROMS der Hauptplatine auf $E0 0000 (an Adresse $4)"), bevor sie auf den Trick mit TOS 2.06 gekommen sind.
-
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.
Wird mit Jumper J2 geregelt:
- 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.
-
@czietz ... Eproms testen ist kein Problem. Habe je vier 27C512 oder 27C010 die ich löschen kann.
-
Wer die Mailingliste liest weiss das czietz eine angepasste EmuTOS Version gemacht hat womit die PAK68/2 bootet mit EmuTOS auf den PAK Eproms. Allerdings nur wenn die FPU disable ist, mit FPU bootet der Rechner nicht. Die EmuTOS Programm Version läuft ja mit FPU.
Weiss da jemand Rat ?
-
Das thema hatten wir doch schon einmal vor einem Jahr! Bei der FPU ansteuerung war ein fehler bzw. irgendeine ausdekotierung nicht korrekt. Holger hatte da doch irgendwas Modifiziert.. aber das war nur bei der Pak3-030 richtig ?
-
Ja, die Vermutung liegt nahe daß es an der FPU liegt. Preisfrage ist jetzt, warum die PRG Version von EmuTOS funktioniert, die ROM Version aber nicht, obwohl beide eigentlich das gleiche machen. Dann müsste man noch heraus finden, welche FPU Befehle Probleme machen, denn grundsätzlich wird das ja funktionieren, sonst wäre die FPU ja nutzlos.
-
Die normale Rom 256kb und 512kb Version 14042020 bootet nicht bei FPU disable. Nur die angepasste Version von czietz bootet bei FPU disable. Sind ja dann zwei verschiedene Sachen warum es nicht geht, oder?
-
Moin,
wenn ich mich recht entsinne, sollte die Startadresse der ROMs auf dem Mainboard FC... sein.
Gruß
skul
-
Nachtrag: Wir haben es mittlerweile gelöst. Ein aktueller EmuTOS Snapshot (256k ROM) läuft auf der PAK/2. Auch mit Startadresse $FCxxxx der Mainboard-ROMs und auch mit aktiver FPU.