atari-home.de - Foren
Hardware => Hardware (High-End) => Thema gestartet von: Lukas Frank am So 20.11.2016, 12:35:10
-
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 ?
-
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).
-
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.
-
Auf der Pak sollte doch ein 32bit Tos drauf, oder?
-
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 ?
-
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.
-
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.
-
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).
-
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.
-
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?
-
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 ...
-
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.
-
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?
-
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.
-
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.
-
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.
-
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?
-
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.
-
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
-
@pakman ... könnte vielleicht etwas dazu sagen.
-
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.
Das ist zwar richtig, aber darüber sind wir doch längst hinweg. Christian hat oben festgestellt, daß das durch die unvollständig ausdekodierte PAK-Adresslogik der ROMs "ganz zufällig" auch für 256k TOS paßt.
Es bleibt bloß noch die Frage, warum's nicht läuft.
Mein Verdacht ist der, daß (wie im anderen Thread, wo's um die CPU-Erkennung geht) der PMMU-Befehl, den EmuTOS absetzt, um einen 030er zu erkennen ebenso wie bei MiNT bei der PAK ohne eine Reaktion ins Leere geht.
EmuTOS setzt (das ist noch innerhalb der ersten hundert Instruktionen des ROMs, da hat der Bildschirm noch keine Chance, irgendwas anderes als schwarz darzustellen) erst das CACR-Register (wenn das funktioniert, ist >= 020 erkannt) und versucht anschließend, das Translation Control-Register zu beschreiben (das gibt es nur bei einem 030er+ oder einem 020er mit 68851 MMU).
Wenn das ohne Protest "hingenommen" wird, beschließt EmuTOS, daß es einen 030er vor sich hat.
-
Wenn das zufällig mit den 256kB TOS auf der PAK gehen würde, würde mein ST mit der PAK 68/2 kein TOS 1.04 auf der Hauptplatine brauchen. Geht aber nicht ohne. Daher bin ich von deiner Argumentation noch nicht überzeugt. Das einfachste ist vielleicht, testweise mal 1.04 auf die Platine zu stecken und 2.06 auf die Pak und dann schauen dass das Ding startet. Dann mal das 1.04er weg, dann dürfte das Ding nicht mehr starten (so ist es bei mir mit der Original-PAK). Dann 1.04 wieder drauf und Emu-TOS auf die Pak, und wenn das auch nicht klappt 192er EmuTOS auf die Hauptplatine und hoffen dass der Einsprungvektor gleich ist wie beim 256er.
-
Vielleicht liest Du einfach mal den ersten Beitrag in diesem Fred ...
-
Habe Holger mal über Whatsapp angeschrieben das er mal reinschaut, vielleicht hat er ja eine Idee
-
Vielleicht liest Du einfach mal den ersten Beitrag in diesem Fred ...
Hab ich, beweist aber nichts:
"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 ?"
Deckt sich schlicht nicht mit meiner Erfashrung mit meiner PAK 68/2.
-
Deckt sich schlicht nicht mit meiner Erfashrung mit meiner PAK 68/2.
Du willst uns damit sagen, daß EmuTOS 256kB auf deiner PAK läuft?
-
EmuTOS setzt (das ist noch innerhalb der ersten hundert Instruktionen des ROMs, da hat der Bildschirm noch keine Chance, irgendwas anderes als schwarz darzustellen) erst das CACR-Register (wenn das funktioniert, ist >= 020 erkannt) und versucht anschließend, das Translation Control-Register zu beschreiben (das gibt es nur bei einem 030er+ oder einem 020er mit 68851 MMU).
Wenn das ohne Protest "hingenommen" wird, beschließt EmuTOS, daß es einen 030er vor sich hat.
Das ist die initiale Erkennung in startup.S [1], aber später in processor.S [2] wird's nochmal "richtig" gemacht und auch auf das Vorhandensein des Datencache beim 68030 getestet.
[1] https://sourceforge.net/p/emutos/code/ci/master/tree/bios/startup.S
[2] https://sourceforge.net/p/emutos/code/ci/master/tree/bios/processor.S
-
Eventuell doch mal versuchen das EmuTOS mit aufs Board zu stecken ? Wäre zwar doppelt gemoppelt aber ein versuch wert.
-
Deckt sich schlicht nicht mit meiner Erfashrung mit meiner PAK 68/2.
Du willst uns damit sagen, daß EmuTOS 256kB auf deiner PAK läuft?
Nein, aber TOS 2.06 läuft, das aber nicht ohne dass auf der Hauptplatine ein TOS 1.04 steckt. Mittlerweile verstehe ich aber den Mechanismus, der dahintersteckt, nicht mehr, denn ich habe mir mal mit einem Hexeditor die Einsprungadressen in TOS 1.04, 2.06 und EmuTOS 192/256 kB angeschaut, und jeweils bei den 256 kB TOS steht die selbe Sprungadresse ab Byte 4 drin (00E00030), und in den 192ern steht jeweils auch eine gleiche drin ( 00FC0030). Vielleicht muss ich in den 256ern nochmal nachsehen, ob vielleicht auf 00FC0030 noch ein Sprung auf 00E00030 zu finden wäre. Dann würde es passen.
-
Nein, aber TOS 2.06 läuft, das aber nicht ohne dass auf der Hauptplatine ein TOS 1.04 steckt.
Es hat ja auch niemand etwas anderes behauptet. Was also "[d]eckt sich schlicht nicht mit [D]einer Erfashrung mit [D]einer PAK 68/2. "?
Mittlerweile verstehe ich aber den Mechanismus, der dahintersteckt, nicht mehr,
Habe ich weiter oben erläutert.
-
Habe ich weiter oben erläutert.
Ich hab' ja den Eindruck, daß 1ST1 nur seine eigenen Beiträge liest ... >:D
-
Dann musst du es wohl mal ausführlicher erklären. Ich kann mir die Erklärung momentan nicht herleiten. 00FC0030 und 00E00030 bekomme ich momentan mit keiner doppelten Einblendung der ROMs zusammen.
-
@Lukas Frank : kannst Du das angehängte Programm mal auf deiner PAK laufen lassen und uns sagen, was es erzählt (in .prg umbenennen)?
-
Der Code macht übrigens das hier:
#include <mint/osbind.h>
#include <setjmp.h>
jmp_buf env;
void access_fault_exception(void) __attribute__((interrupt));
void access_fault_exception(void)
{
Cconws("access fault\r\n");
longjmp(env, 0);
}
void illegal_exception(void) __attribute__((interrupt));
void illegal_exception(void)
{
Cconws("illegal instruction\r\n");
longjmp(env, 0);
}
void linef_exception(void) __attribute__((interrupt));
void linef_exception(void)
{
Cconws("linef exception\r\n");
longjmp(env, 0);
}
void coprocessor_protocol_exception(void) __attribute__((interrupt));
void coprocessor_protocol_exception(void)
{
Cconws("coprocessor protocol violation\r\n");
longjmp(env, 0);
}
void check_pmmu(void)
{
void *old_access, *old_illegal, *old_linef, *old_coproc;
old_access = Setexc(2, access_fault_exception);
old_illegal = Setexc(4, illegal_exception);
old_linef = Setexc(11, linef_exception);
old_coproc = Setexc(13, coprocessor_protocol_exception);
if (!setjmp(env))
{
__asm__ volatile(
" moveq #0,d0 \n\t"
" .long 0xf0390800 \n\t" // pmove 0,tt0
" .long 0x00000000 \n\t"
:
:
: "d0"
);
Cconws("no error\r\n");
}
Setexc(2, old_access);
Setexc(4, old_illegal);
Setexc(11, old_linef);
Setexc(13, old_coproc);
}
int main(int argc, char *argv[])
{
while (Cconis()) Cconin();
Supexec(check_pmmu);
Cconws("\r\nPress key.\r\n");
while (!Cconis());
}
-
... kannst Du das angehängte Programm mal auf deiner PAK laufen lassen und uns sagen, was es erzählt (in .prg umbenennen)?
Mit Single TOS 2.06 ohne FPU = linef exception
Single TOS mit FPU = no error
Mit MiNT genau das gleiche ...
-
Und was kommt bei
ssystem -v CTRLCACHE:0:-1
?
-
Unter TOS kann ich das nicht lesen, ist zu schnell wieder weg ...
Bei MiNT kommt egal ob mit oder ohne FPU "mode:23:0, result:0(0x0)"
-
... kannst Du das angehängte Programm mal auf deiner PAK laufen lassen und uns sagen, was es erzählt (in .prg umbenennen)?
Mit Single TOS 2.06 ohne FPU = linef exception
Single TOS mit FPU = no error
Mit MiNT genau das gleiche ...
Hmm. Also macht die PAK genau, was sie soll.
Die MMU-Befehle sind's dann wohl doch nicht, die EmuTOS am Starten hindern...
Mittlerweile bin ich auch dahintergekommen, daß "pmove <ea>,ttx" beim Gespann 68020/68851 gar keine valide Instruktion ist (tt<x>-Register gibt's da gar nicht).
War mir neu, ich dachte bisher, die 68851 MMU wäre dieselbe, die im 030 steckt).
-
@Lukas Frank: kannst Du das hier auch noch laufen lassen?
pmove <ea>,tc
(wird von EmuTOS ein wenig später benutzt) ist bei der 68851 MMU ein gültiger Befehl. Passiert da dasselbe?
-
Ist das ein neues Programm ?
Oder soll ich es in ttp umbenennen und die Parameter übergeben ?
-
Ist das ein neues Programm ?
Oder soll ich es in ttp umbenennen und die Parameter übergeben ?
Das ist ein neues Programm (unterscheidet sich bloß in einem Wort vom alten) - genau wie vorhin: umbenennen und einfach starten.
-
ohne FPU unter TOS kommt "linef exception" und mit FPU kommt siehe Bild ...
-
ohne FPU unter TOS kommt "linef exception" und mit FPU kommt siehe Bild ...
Aha.
:o
Das ist zwar nicht, was ich erwartet hätte (das Gekrakel sollte eigentlich nicht kommen :) ), aber ein Indiz dafür, daß die PAK (sobald die FPU aktiv ist) mit dem MMU-Befehl irgendwas macht, was sie nicht sollte.
-
Dann musst du es wohl mal ausführlicher erklären. Ich kann mir die Erklärung momentan nicht herleiten. 00FC0030 und 00E00030 bekomme ich momentan mit keiner doppelten Einblendung der ROMs zusammen.
[Erklärmodus=an]
Das GAL auf der PAK selektiert die EPROMs sowohl für Adressen 0xE00000 - 0xE7FFFF als auch für Adressen 0xFC0000 - 0xFEFFFF. An den EPROMs selbst sind nur die CPU-Adressleitungen bis A18 angeschlossen. Somit landet ein Zugriff auf 0xFC0030 erst einmal an derselben Stelle wie ein Zugriff auf 0xE40030, da (0xFC0030 & (2^19 - 1)) == (0xE40030 & (2^19 - 1)) == 0x40030. Wenn Du nun aber 4 EPROMs mit zusammen nur 256 kByte Speicher hast, wird das oberste Adressbit nicht beachtet und damit landet der Zugriff statt bei Adresse 0x40030 im EPROM bei Adresse 0x00030, also derselben Adresse, an der auch ein Zugriff auf 0xE00030 landen würde.
[Erklärmodus=aus]
Mehr kann ich dazu wirklich nicht mehr erklären...
-
Ich denke ich weiß, warum EmuTOS nicht startet.
Es hängt in einer Endlosschleife fest.
@Lukas Frank : kannst/willst Du das da mal probieren?
[edit: ich hab' den Anhang nochmal entfernt, kann so noch nicht funktionieren. Noch ein bißchen Geduld bitte]
-
@czietz danke das leuchtet ein.
-
Sodele, damit müsste der erste CPU-Test eigentlich zu überwinden sein. Ob das später (wo der CPU-Cookie gesetzt werden soll) auch klappt, hab' ich mir nicht angeschaut.
Kannst Du das mal in deine ROMs packen?
-
Ich probiere das mal aber es ist immer eine große Aktion mit den Eproms ...
Habe auch von pakman ein neues GAL U6 bekommen mit PMMU Handling ...
-
Besser wäre wenns mit dem Original-GAL gehen würde.
-
Ich probiere das mal aber es ist immer eine große Aktion mit den Eproms ...
Das hier ist einfacher zu testen. Einfach in .prg umbenennen und vom (TOS 2.06) Desktop starten.
-
So wie es aussieht muss ich das doch mit den Eproms ausprobieren. Das Programm läuft, auch die normale 0.97 Version. Allerdings wenn ich Programme starte hängt sich der Rechner mit Bus Error auf ...
Der Rechner hat ja schon gebootet beim Start vom emutos.prg !?!
-
So wie es aussieht muss ich das doch mit den Eproms ausprobieren. Das Programm läuft, auch die normale 0.97 Version. Allerdings wenn ich Programme starte hängt sich der Rechner mit Bus Error auf ...
Der Rechner hat ja schon gebootet beim Start vom emutos.prg !?!
Wenn ich das richtig verstanden habe, heißt das, emutos.prg läuft grundsätzlich? Aber Du kannst keine Programme starten?
Dann ist da wahrscheinlich nochmal was anderes faul und es wird mit den ROMs wohl auch nicht besser. Es sei denn, das Programmstarten geht wegen Speichermangel schief (wieviel hast Du denn in der Kiste?).
Du müsstest ja eigentlich beim Programmstart einen "Panic"-Dump von EmuTOS bekommen - kannst Du den mal posten? Könnte Hinweise auf die Fehlerursache liefern.
-
Du müsstest ja eigentlich beim Programmstart einen "Panic"-Dump von EmuTOS bekommen - kannst Du den mal posten? Könnte Hinweise auf die Fehlerursache liefern.
Wie mache ich sowas ?
Mal ein Bild ... (http://forum.atari-home.de/index.php?action=dlattach;topic=13231.0;attach=12537;image)
Hardware: Mega ST4 mit MonSTer (TOS 1.04 selektiert), PAK68/2
Es macht keinen Unterschied ob ich die Programme von der CF Karte oder von Floppy starte ...
-
Ändert sich das Verhalten, wenn Du die FPU ausschaltest?
-
Nein mit FPU disable kommt die gleiche Panic Line F Emulator ...
-
Habe jetzt mal deine EmuTOS Version in Eproms gebrannt und damit bootet deer Rechner zum Desktop mit der PAK68/2, allerdings wie bei der Diskettenversion kann ich keine Programme starten ...
-
Habe jetzt mal deine EmuTOS Version in Eproms gebrannt und damit bootet deer Rechner zum Desktop mit der PAK68/2, allerdings wie bei der Diskettenversion kann ich keine Programme starten ...
Prima, dann haben wir die erste Hürde genommen.
Kannst Du von dem Panic-Dump, der bei der ROM-Version kommt, bitte auch noch mal ein Foto machen?
-
Tut mir Leid aber der Rechner will nicht mehr booten mit dem EmuTOS Eproms ...
TOS 2.06 drauf gepackt und läuft. Ich nehme mal ein anderes Mainboard ohne MonSTer.
-
Ich habe irgendwie den Verdacht, daß sich die PAK an dem MMU-Befehl zur Prozessor-Erkennung gründlich verschluckt.
Es gibt keinen vernünftigen Grund für das Testprogramm oben, das Kauderwelsch auszugeben. Da müsste "illegal instruction" stehen.
Was die Zeichenanzahl angeht, paßt das anscheinend auch. Also ist die Zeichenmatrix irgendwie verhunzt.
Mein Testprogramm macht das nicht...
-
Habe das an einem anderen Rechner mit einer leeren Diskette ausser dem exc.prg drauf probiert und es ist genau das gleiche ...
-
Es wird immer Seltsamer ...
@mfro
Habe nochmal die EmuTOS Eproms aufgesteckt und der Rechner will nicht booten, ist tot. Wenn ich aber den FPU disable Jumper setze bootet EmuTOS einwandfrei und ich kann auch Programme starten bzw. mein MiNT bootet einwandfrei ...
Jetzt bei zwei PAK68/2 getestet und bei beiden dass gleiche. Das die PAK mit der FPU drauf und EmuTOS mal gebootet hat war wohl ein großer Zufall.
-
Es wird immer Seltsamer ...
@mfro
Habe nochmal die EmuTOS Eproms aufgesteckt und der Rechner will nicht booten, ist tot. Wenn ich aber den FPU disable Jumper setze bootet EmuTOS einwandfrei und ich kann auch Programme starten bzw. mein MiNT bootet einwandfrei ...
Hast Du jetzt das neue "Zusatz-GAL" dran oder nicht?
-
Nein habe das original U6, nicht das von Holger ...
-
Dann verstehe ich nicht, warum sich das plötzlich anders verhält als gestern. Ist das eine andere PAK oder nur ein anderes Board?
-
War gerade mit dem Hund und jetzt bootet EmuTOS wieder gar nicht egal was mit der FPU ist ...
So langsam wird mir das alles zu viel !
Mainboard ist das mit der MonSTer drauf und eine original PAK68/2.
Edit: ... jetzt geht es plötzlich wieder !?!
-
Edit: ... jetzt geht es plötzlich wieder !?!
Wenn Du noch ein bißchen (ein paar Tage oder so) Geduld hast, mach' ich dir eine Version, die mit großer Wahrscheinlichkeit zuverlässig funktioniert - vorausgesetzt, Du testest sie dann auch (eine Hand wäscht die andere).
Ich würde ganz einfach das ganze PMMU-Geraffel ignorieren, sobald EmuTOS einen 68020 gefunden hat. Dann muß wohl noch ein 2. Fehler gefixt werden, der wahrscheinlich dazu führt, daß das Programme Starten mal geht und mal nicht (bei einem 020 wird aktuell der I-Cache nach dem Laden nicht invalidiert, was wahrscheinlich zu dem Line-F Fehler von gestern geführt hat).
Und dann müssen wir halt mal sehen, ob noch was übrig ist, was nicht geht.
-
Ja machen wir ...
-
Ich habe nur einen Satz 27C512 Eproms, neue schon aus China neue bestellt aber die Frage wäre ob ich auch das 512kB EmuTOS mit der PAK nutzen kann. 27C010 Eproms habe ich noch jede Menge. Was ist denn dann mit den NVRAM Settings ?
Das ist aber nur eine Frage, ich würde weiterhin die 256kB Version nutzen wollen ...
-
Ich habe nur einen Satz 27C512 Eproms, neue schon aus China neue bestellt aber die Frage wäre ob ich auch das 512kB EmuTOS mit der PAK nutzen kann. 27C010 Eproms habe ich noch jede Menge. Was ist denn dann mit den NVRAM Settings ?
Das ist aber nur eine Frage, ich würde weiterhin die 256kB Version nutzen wollen ...
Wenn die Hardware das nicht unterbindet, müsste es eigentlich laufen (Du wärst aber der Erste, der das probiert, soweit ich weiß).
Mein Suska-Board (das ja fast ein STE ist) ist jedenfalls mit EmuTOS 512 ganz glücklich...
Wenn's kein NVRAM gibt, ist die Oberfläche halt englisch.
-
Ich werde das mal probieren, das Problem ist das die PAK68/2 mit TOS 3.06 (27C010) mit der MonSTer nicht booten will. Das geht nur wenn TOS 1.04 in Form von Proms/Eproms direkt auf dem Board steckt ...
-
Es gibt keinen vernünftigen Grund für das Testprogramm oben, das Kauderwelsch auszugeben. Da müsste "illegal instruction" stehen.
Es sei schon einmal verraten, dass ich das "Kauderwelsch" auch mit Hatari reproduzieren kann, siehe Anhang. Es gibt auch keine "Illegal Instruction"-Exception, weder in Hatari noch bei Frank. Details erzähle ich Dir später.
-
... jetzt machst Du mich aber neugierig, hab' ich irgendwo Mist gebaut? ;)
-
Hintergrund: Wie ich ja schon im anderen Thread im Zusammenhang mit MiNT geschrieben hatte, landen auf der PAK/2 die PMMU-Instruktionen stattdessen bei der FPU. Das heißt, die PAK verhält sich, als ob in der Instruktion statt der CpID=0 (MMU) die CpID=1 (FPU) codiert wäre. Wenn ich Dein Testprogramm mal bzgl. der CpID patche(*), ergibt sich ein grundsätzlich gültiger Coprozessor-Befehl, gefolgt von etwas Unsinn, von dem aber nichts auch nur irgendeine Exception verursacht:
$0001d6fa : 7000 moveq #0,d0
$0001d6fc : (*)f238 4000 0000 fmove.l $0000.w,fp0
$0001d702 : 0000 203c ori.b #$3c,d0
$0001d706 : 0001 d670 ori.b #$70,d1
$0001d70a : 2f00 move.l d0,-(sp)
$0001d70c : 3f3c 0009 move.w #9,-(sp)
$0001d710 : 4e41 trap #1 ; Cconws
Zur Ausgabe der Meldung "no error" müsste aber folgender Code zur Ausführung kommen:
$0001d704 : 203c 0001 d670 move.l #$1d670,d0
$0001d70a : 2f00 move.l d0,-(sp)
$0001d70c : 3f3c 0009 move.w #9,-(sp)
$0001d710 : 4e41 trap #1 ; Cconws
Du siehst, dass der obige Code auf der PAK zu Cconws((char *)0x3c) führt. Und was steht an dieser Adresse?
0000003C: 0f e0 10 e2 10 e0 10 e2 11 e0 10 e2 12 e0 10 e2
0000004C: 13 e0 10 e2 14 e0 10 e2 15 e0 10 e2 16 e0 10 e2
Wenn man jetzt noch weiß, dass 0xe0 auf dem Atari der Zeichencode für α ist und 0xe2 der für Γ, dann ergibt die Meldung irgendwie Sinn.
Detail am Rande: Auch auf einem 68030 würde Dein Testprogramm vermutlich zum gleichen Fehler führen, weil Du die PMOVE-Instruktion falsch codiert hast.
$0001d6fc : f038 4000 0000 pmove $0000.w,tc
$0001d702 : 0000 203c ori.b #$3c,d0
$0001d706 : 0001 d670 ori.b #$70,d1
Korrekt wäre gewesen, siehe auch EmuTOS asmdefs.h:
$0001d6fc : f039 4000 0000 0000 pmove 0,tc
$0001d704 : 203c 0001 d670 move.l #$1d670,d0
Ich habe mir jetzt Deinen Patch für EmuTOS nicht angeguckt (und auch Dein Posting auf der Mailingliste noch nicht im Detail gelesen), aber wenn die obige Analyse irgendwelche Auswirkungen darauf hat, solltest Du Deine EmuTOS-Korrektur ggf. noch einmal anpassen.
-
Ahja, danke für die Analyse.
Einigermaßen verzwackt das Ganze, aber sauber aufgedröselt, Hut ab und dankeschön für's Auflösen!
Es gibt also gültige PMMU-Befehle, die auf der PAK plötzlich zu gültigen FPU-Befehlen werden.
Das ist interessant, hat aber auf den EmuTOS-Patch (so er denn mal fertig ist) keinen Einfluß.
Der wird - sobald ein 020er erkannt wird - keine PMMU-Befehle mehr absetzen. Erstens werden sie nicht gebraucht, zweitens würden sie auf der PAK bloß Blödsinn anstellen und drittens würde die 68030-MMU-Befehlssequenz auch bei einem "richtigen" 68020/68851-Gespann so nicht laufen.
-
Es gibt also gültige PMMU-Befehle, die auf der PAK plötzlich zu gültigen FPU-Befehlen werden.
Das sah man ja auch schon an Deinem ersten Testprogramm, das bei Frank mit "no error" durchlief. Da war der fehlerhaft dekodierte Befehl wohl so, dass danach kein "Unsinn" folgte.
EDIT: Und es ist auch zu vermuten, dass im Fall von EmuTOS nicht der PMMU-Befehl an sich sondern die drauffolgenden auf der PAK/2 dann fälschlicherweise auch als Befehl dekodierten Worte zu der von Dir gefunden "illegal instruction exception" führen.
-
Ich habe nur einen Satz 27C512 Eproms, neue schon aus China neue bestellt aber die Frage wäre ob ich auch das 512kB EmuTOS mit der PAK nutzen kann. 27C010 Eproms habe ich noch jede Menge.
Das ist aber nur eine Frage, ich würde weiterhin die 256kB Version nutzen wollen ...
Die 256kB Version läuft auch mit den 27C010.
Du musst nur in jedes 27C010 den Inhalt des 27C512 zweimal hintereinander reinschreiben.