atari-home.de - Foren
Software => Alternative Betriebssysteme => Thema gestartet von: RealLarry am Fr 02.09.2016, 13:07:05
-
Hallo allerseits!
Ich möchte an den Thread http://forum.atari-home.de/index.php?topic=12491.0 anknüpfen, mit dem Unterschied, dass in meinem TT eine MAT TC läuft.
GEM und die TC laufen tadellos, Mint mit den Standard-Auflösungen auch, aber eben nicht Mint mit den TC-Auflösungen; es läuft letzten Endes immer zu den (Darstellungs-)Problemen wie im zuvor genannten Thread. Versuchsweise hatte ich auch manche im Thread genannte Tipps ausprobiert, was ansatzweise eine Besserung, aber noch keinen Erfolg brachte.
Im Vorfeld hatte ich zum üben das ganze unter Hatari zum laufen gebracht, hiernach auf einem MiST mit hoher Mono-Auflösung. Läuft also überall im ganzen prima.
Verwendet werden die Original TC-Treiber, aktualisiert mit nvdi 5.03.
Wer mag mir hier freundlicherweise unter die Arme greifen?
-
NVDI ET4000 hat so seine Probleme mit MiNT/XaAES, es läuft nur bei 256 Farben. Die NVDI TC Version sollte da nicht anders sein, denke ich mir mal. Probiere doch das ganze mal ohne NVDI TC nur mit dem original Matrix Treiber zu deiner Karte.
Frage mal HelmutK einem der XaAES Entwicklern ...
-
Danke für die Hinweise - werde ich jetzt am Wochenende mal ausprobieren und ggf. Helmut kontaktieren.
256 Farben wären für mich völlig ausreichend und auch mein Ziel, denn damit kann ich bequem und schön bunt die 1024er-Auflösung fahren :)
-
Mit den Original TC-Treibern fährt mint und xaaes korrekt hoch (1024x768x256). Das ist schon einmal prima.
Ab hier hagelt es allerdings bei nahezu allem, was ich dann starte, Memory Violations; das gabs mit nvdi bei den Standard-Auflösungen zuvor nicht.
Da ich bei den Ataris seit gut 20 Jahren aus dem Thema bin: Brauche ich denn ein nvdi/fvdi? Welches macht dann mehr Sinn?
-
1) Stehen in der ASSIGN.SYS die richtigen Treiber? bzw. die richtige NVDI-
Version? Die müssen zueinander passen!
2) Anscheinend bestehen manche Bildschirm-Treiber darauf, daß ihre
Voreinstellung zur im *DESK*.?NF oder sonstwo vermerkten Auflösung
passen muß. (zB. unter #E... an sechster Stelle 3A (= VGA16))
-
Lasse mal mint030.prg ohne Memory Protection laufen zum Probieren. NVDI ET4000 läuft bei mir nur mit einem kleinen Patchprogramm mit 256 Farben von Helmut weil NVDI bzw. MiNT die Workstation oder so nicht öffnen kann.
Frage Helmut .... (Er hat auch Matrix Karten, zwar die kleinen CXX und keine TC)
Die MiNT Mailing Liste wäre auch gut dein Problem zu klären ...
-
1) Stehen in der ASSIGN.SYS die richtigen Treiber? bzw. die richtige NVDI-
Version? Die müssen zueinander passen!
2) Anscheinend bestehen manche Bildschirm-Treiber darauf, daß ihre
Voreinstellung zur im *DESK*.?NF oder sonstwo vermerkten Auflösung
passen muß. (zB. unter #E... an sechster Stelle 3A (= VGA16))
Das nehme ich jetzt einfach mal an, werde Dein Beispiel aber mal mit meiner assign.sys vergleichen. Denn wie ich Eingangs anmerkte, funktioniert die TC mit nvdi im GEM tadellos, wie auch die ST/TT-Standard-Auflösungen mit mint.
-
Lasse mal mint030.prg ohne Memory Protection laufen zum Probieren.
Yep, so fährt alles problemlos hoch (TC Original, mint, xaaes). Danke für den Tipp!
Die Dokus zur Memory Protection orakeln meiner Meinung nach da etwas, ob es sinnvoll ist, MP ein- oder auszuschalten. Ich lasse MP jetzt zunächst einmal ausgeschaltet und frage Helmut freundlich, ob er bei Gelegenheit mir über die Schulter schauen mag.
-
Die Geschichte mit NVDI und MiNT/XaAES ist schon traurig wie ich finde ...
Ich nutze bei meinen Karten die Nova Treiber, die haben da kein Problem. Leider hilft dir das bei der Matrix nicht ...
-
Ich hab das jetzt schon mehrfach erklärt: XaAES läuft ohne Probleme und ohne irgendwelche Zusatzprogramme mit NVDI-ET4000, wenn man das:
http://wiki.sparemint.org/index.php/Troubleshooting#XaAES_doesn.27t_work_with_NVDI_ET4000
beachtet. Wenn es dann immer noch nicht geht, bitte genauer!
Zur Matrix: Ich hab keine TC, aber jedenfalls läuft meine sowohl mit dem Matrix-VDI, als auch mit NVDI5 mit aktivierter Matrix-Option mit XaAES. Das Matrix-VDI ist eigentlich keine Lösung, da läuft zu viel schief.
Ich starte NVDI allerdings erst von XaAES aus, dann legt es sich über das Matrix-VDI. Dazu gibt es ein neues Kommando für xaaes.cnf (install, siehe example.cnf in meinem branch). Das ist allerdings alles schon länger her, weiß nicht ob es noch immer funktioniert, und wie genau.
-Helmut
-
Zur Matrix: Ich hab keine TC, aber jedenfalls läuft meine sowohl mit dem Matrix-VDI, als auch mit NVDI5 mit aktivierter Matrix-Option mit XaAES. Das Matrix-VDI ist eigentlich keine Lösung, da läuft zu viel schief.
Mit der Matrix-VDI habe ich heute auch viele Problemchen gehabt. Zwar läuft so jetzt alles soweit, aber einige kleinere Helferlein werden nicht oder nicht korrekt dargestellt - sowohl mit GEM, als auch mit MiNT.
Verwende ich NVDI5/TC und MiNT, startet XaAES in einer falschen (niedrigen?) Auflösung, alles ist rot dargestellt und sieht eher psychedelisch aus.
Ich starte NVDI allerdings erst von XaAES aus, dann legt es sich über das Matrix-VDI. Dazu gibt es ein neues Kommando für xaaes.cnf (install, siehe example.cnf in meinem branch). Das ist allerdings alles schon länger her, weiß nicht ob es noch immer funktioniert, und wie genau.
Das habe ich auch schon dem MiNT/XaAES/et4000 Thread entnommen (denke ich), werde mir das aber gerne mal genauer anschauen, testen und berichten.
Aus technischer Neugier: Verstehe ich das richtig, dass die Grafik/Auflösungs-Probleme letztlich durch das VDI verursacht werden? (Das eine initialisiert "scheiße", das andere "nicht richtig" (oder so ähnlich ;) )... Das alles ist bei mir halt schon sooo lange her, dass ich quasi wieder von vorne anfangen darf.
...und was hat es mit opnwk.prg auf sich? Ist es et4000-spezifisch? (Habe es nicht im Einsatz, interessiert mich aber am Rande).
Soweit aber vielen Dank für jegliche Hilfestellung! Viel fehlt ja nicht, dann läuft das ganze richtig rund...
-
Das weiß ich jetzt auch nicht mehr, was man da alles falsch machen kann, ich glaub aber sowas hatte ich auch schon. Klappt das denn mit Matrix-VDI+NVDI im GEM ohne MiNT, oder mit MiNT+GEM=ROM, also ohne XaAES?
Das opnwk.prg ist ein fieser Hack, den man nicht braucht! Es öffnet eine physikalische workstation, und beendet sich, diese wk wird dann von XaAES benutzt (Nummer geraten).
-Helmut
-
Das weiß ich jetzt auch nicht mehr, was man da alles falsch machen kann, ich glaub aber sowas hatte ich auch schon. Klappt das denn mit Matrix-VDI+NVDI im GEM ohne MiNT, oder mit MiNT+GEM=ROM, also ohne XaAES?
Also Matrix-VDI+NVDI im GEM (ohne MiNT) läuft tadellos; da hatte ich auch schon viel experimentiert, auch mit MagiC und Jinnee. Lief alles super, aber jetzt will ich mehr ;)
MiNT+GEM=ROM (ohne XaAES) habe ich noch nicht ausprobiert, weil mir nicht ganz klar war (ist), waswannwiesowenn in der mint.cnf bzgl. GEM= und INIT= geändert werden muss. Das werde ich morgen mal angehen.
Auch ist mir aufgefallen, dass wenn die mint.cnf, wie auch die xaaes.cnf aus der Example übernommen und angepasst wurden, scheinbar zu groß sind und nicht korrekt geparst werden und MiNT/XaAES nicht ordentlich hochkommen. Kürze ich sie auf das Essentielle, klappt's problemlos.
Das opnwk.prg ist ein fieser Hack, den man nicht braucht! Es öffnet eine physikalische workstation, und beendet sich, diese wk wird dann von XaAES benutzt (Nummer geraten).
So hatte ich das auch schon im anderen Thread aufgefasst. Aber dennoch Danke für die Bestätigung :)
Ich bin jetzt erst einmal ein gutes Stück schlauer, gehe in den Abend-Modus, wünsche Euch einen lauschigen Abend und werde morgen berichten.
-
Die Geschichte mit dem Grafikkartenbetrieb mit NVDI und MiNT/XaAES müsste mal ordentlich Dokumentiert werden. Ich für mein Teil richte das ein und ein paar Monate später habe ich alles wieder vergessen ...
Traurig finde ich halt das es nicht normal funktioniert also aus dem Autoordner heraus so wie in der NVDI Dokumentation beschrieben.
-
Genau das geht doch. Mit dem trunk-XaAES muss man eben den link setzen, mit meinem muss man gar nichts machen. Was soll denn da noch groß dokumentiert werden?
Ich weiß leider immer noch nicht, was Dein Problem ist.
-Helmut
-
...und am siebenten Tage schuf ER mit trunk-04092016.tar.bz2 und helmut-04092016.tar.bz2 ein neues MiNT/XaAES, startete neu und siehe! Es tat und war gut so.
Ähm, was soll ich sagen: Die beiden o.g. Snapshots ausgepackt, auf den TT kopiert, die laufenden mint.cnf und xaaes.cnf aus 1-18-0 dazu und die Pfade auf 1-19-CUR angepasst, sonst nichts weiter verändert, das war's schon. Der TT fährt sauber in 1024x768x256 (mit TC+NVDI) hoch und alles ist so, wie ich es mir gewünscht hatte.
Einzig über das TOSWIN2 aus dem Snapshot meckerte XaAES mit einem Memory Violation; ich habe es dann gegen das aus 1-18-0 ausgetauscht, damit startet XaAES fehlerfrei. Ich packe jetzt die Unix-Tools auf das EXT2 aus, richte das restliche System ein und werde berichten, ob und was mir ggf. sonst noch aufgefallen ist. Bislang scheint aber alles bestens zu funktionieren!
@Helmut: Auch wenn Du mir vielleicht nicht konkret, bzw. im Detail helfen konntest: Manchmal reicht es schon, dass man sich bloß einfach etwas darüber unterhält und schon kommen neue Ideen, die dann doch riesig weiterhelfen. An dieser Stelle also herzlichen Dank für jeden noch so kleinen Hinweis! (Dank aber auch an Lukas Frank - jeder Kommentar hilft in irgendeiner Weise)
Kann ich Dir, Helmut, in irgendeiner Weise beim 1-19 helfen, z.B. in Form von Bug-Reports oder ähnlichem?
-
...und am siebenten Tage schuf ER mit trunk-04092016.tar.bz2 und helmut-04092016.tar.bz2 ein neues MiNT/XaAES, startete neu und siehe! Es tat und war gut so.
Nur 7? ;)
Ähm, was soll ich sagen: Die beiden o.g. Snapshots ausgepackt, auf den TT kopiert, die laufenden mint.cnf und xaaes.cnf aus 1-18-0 dazu und die Pfade auf 1-19-CUR angepasst, sonst nichts weiter verändert, das war's schon. Der TT fährt sauber in 1024x768x256 (mit TC+NVDI) hoch und alles ist so, wie ich es mir gewünscht hatte.
Keine Ahnung was das war, aber es hat ja auch einige Veränderungen gegeben seit 1.18. Ich dachte die ganze Zeit, Du hast 1.19 genommen.
Einzig über das TOSWIN2 aus dem Snapshot meckerte XaAES mit einem Memory Violation; ich habe es dann gegen das aus 1-18-0 ausgetauscht, damit startet XaAES fehlerfrei. Ich packe jetzt die Unix-
Ich nehm ein ganz altes, aber meinerseits aufgepepptes toswin 1.6, daher kann ich dazu nichts sagen.
Kann ich Dir, Helmut, in irgendeiner Weise beim 1-19 helfen, z.B. in Form von Bug-Reports oder ähnlichem?
Wieso? Keine bugs - keine reports ;)
Im Ernst: was ist denn mit der "zu großen" cnf-Datei? Ich wollte das vorhin probieren, und mit cp -b example.cnf xaaes.cnf, aber aus dem b ist ein v geworden (passiert mir ständig ..), so dass mein xaaes.cnf erstmal weg war. Ist jetzt zwar wieder da, aber ich hab jetzt erstmal keine Lust mehr das nochmal zu probieren.
-Helmut
-
...und am siebenten Tage schuf ER mit trunk-04092016.tar.bz2 und helmut-04092016.tar.bz2 ein neues MiNT/XaAES, startete neu und siehe! Es tat und war gut so.
Nur 7? ;)
Sogar nur 3 (mit heute; hatte ja, wie in Post#1 erwähnt, schon fleißig mit MiNT und Hatari/MiST experimentiert). Bin also flotter als ER >:D
Keine Ahnung was das war, aber es hat ja auch einige Veränderungen gegeben seit 1.18. Ich dachte die ganze Zeit, Du hast 1.19 genommen.
Mein Fehler. Hatte in Post#1 nicht erwähnt, dass es 1-18 war. Vermutlich bin ich davon ausgegangen, dass das klar ist, da 1-18-stable und alles andere entweder -old oder -alpha/beta, was als Besonderheit erwähnenswert gewesen wäre.
Keine bugs - keine reports
Soso. Wir werden sehen... :)
Im Ernst: was ist denn mit der "zu großen" cnf-Datei? [...]
Bei meinen Versuchen mit MiNT-1-18 und MiST zeigte sich, als ich einfach die Examples von mint.cnf und xaaes.cnf nahm und nur anpasste, dass MiNT nicht XaAES per INIT startete. Also habe ich die mint.cnf abgespeckt und nur das nötigste drin gelassen, dann startete XaAES.
Aber XaAES startete Teradesk nicht automatisch. Also auch hier die xaaes.cnf auf's nötigste abgespeckt, dann gings. Daher vermute ich, dass die Dateigrößen mit ~13KB (mint.cnf, jetzt 1,5KB) und ~37KB (xaaes.cnf, jetzt 5,5KB) "zur groß" für den Parser sind. Werde das mit 1-19 aber gerne noch mal verifizieren.
-
Ich hab das jetzt mal probiert mit jeweils über 1MB großen mint.cnf und xaaes.cnf (fast alles Kommentar), und kann kein Fehlverhalten feststellen. Muss wohl was anderes sein.
-Helmut
-
Hast Du es mit der 1-19-cur oder darunter getestet? Bei mir trat dieses Verhalten bei 1-18-0 auf; mit 1-19-cur habe ich es bislang noch nicht getestet, weil ich hier noch mit ständigen memory violations und anderen zu kämpfen habe und nicht wirklich in den Griff bekomme :(
-
1.19-cur.
-
Ah, gut, danke für die Info.
Ich teste immer noch mit helmut-04092016. Läuft an sich prima, jedoch in Verbindung mit Teradesk oder Thing erhalte ich quasi immer Violations (welche im Detail müsste ich mal abpinnen), sobald das Desktop erscheint oder ich weitere Programme starten will. Mit dem nackten XaAES ist es nicht ganz so dramatisch.
Zum Vergleich hatte ich heute Morgen mal helmut-17092016 ausgecheckt, aber damit startet noch nicht einmal der MiNT-Kernel.
Ich habe mal die beiden .cnf angehangen... ;)
-
Normalerweise ist für xaloader GEM= zu wählen, INIT= müsste aber auch gehen.
Immer alles ersetzt? Allerdings hat sich in dem Zeitraum kaum was geändert, bei mir genau nichts. Entweder ist bei dem build was schief gelaufen, oder beim download.
Was brauchst Du denn jetzt? Ich könnte ja mal meine aktuelle Version bei mir hochladen(mintxxx.prg,xaaesxxx.km).
Übrigens: Die .pdf-Endung soll nicht heißen, dass man wirklich pdf-Dokumente abschickt, sondern die Originale in .pdf umbenennt, weil dieses Forum irgendwie kein .cnf usw. annimmt.
-Helmut
-
Normalerweise ist für xaloader GEM= zu wählen, INIT= müsste aber auch gehen.
...so hatte ich das Beispiel auch verstanden, aber mit GEM= kommt XaAES nicht hoch.
Immer alles ersetzt? Allerdings hat sich in dem Zeitraum kaum was geändert, bei mir genau nichts. Entweder ist bei dem build was schief gelaufen, oder beim download.
Klaaaar! ;) Das Archiv von heute Morgen scheint aber i.O. zu sein, denn es packt sauber aus.
Ich werde einfach mit dem helmut-04092016 weiter testen oder ggf. ein späteres dazupacken.
Was brauchst Du denn jetzt? Ich könnte ja mal meine aktuelle Version bei mir hochladen(mintxxx.prg,xaaesxxx.km).
Danke für das Angebot. Da komme ich bestimmt nochmal drauf zurück; ich werde das ganze zunächst nochmals überarbeiten (auch die CNF mit allen Kommentaren einbinden) und auftretende Fehler sauber dokumentieren. Kann von Dir ja nicht erwarten, dass Du meine Fehler im System errätst ;)
Übrigens: Die .pdf-Endung soll nicht heißen, dass man wirklich pdf-Dokumente abschickt, sondern die Originale in .pdf umbenennt, weil dieses Forum irgendwie kein .cnf usw. annimmt.
Hmpf... Gut zu wissen für das nächste Mal...
-
Neuer Tag, neues Glück.
Da ich mit Helmut's 1-19 auf dem TT nicht weiterkomme, habe ich heute mal meinen Falcon (Standard, 14 MB) dazugenommen, um auszuschließen, dass meine Probleme mit der 1-19 zwischen den Ohren liegen oder die MAT mich ärgert.
Also Platte geputzt, alles ganz frisch eingerichtet (kein NVDI, gar nix) und helmut-20092016 genommen. DÄNG, die selben Probleme wie mit dem TT: Gleich nachdem die FAT-Treiber geladen werden, ist Ende im Gelände; also noch bevor XaAES etc. geladen wird (bzw. bevor man etwas anderes sieht, wenn MiNT loslegt).
Alternativ helmut-18092016 genommen: Das selbe.
Dann helmut-04092016, welches auf dem TT zumindest soweit läuft, außer dass sofort und ständig Mem-Violations auftauchen, nachdem XaAES/Teradesk geladen ist: Läuft, aber mit den selben Problemen wie auf dem TT.
Hiernach die 1-18-0 dazugepackt: Läuft sofort, einwandfrei, stabil und ohne Mucken.
(Ja, ich habe auch immer brav Kernel, /mint/ und /tools/ aus dem jeweiligen Archiv genommen :))
Für mich sieht es so aus, als dass irgendwann nach helmut-04092016 etwas völlig daneben läuft.
Soll ich mal statt helmut-x den trunk-x des 1-19 Zweigs nehmen? Denn an dieser Stelle gehen mir die Ideen aus und die 1-18-0 zeigt mir ja, dass ich das "Konstrukt" (CNFs und was so alles zu MiNT dazugehört) nun soweit verstanden habe und auch, wie heute geschehen, mal-so-eben-nebenher aufziehen kann, dass es auch läuft.
Bin für jede Idee zu haben und dankbar, denn der Falcon ist, wenn man erst einmal den TT mit seiner MAT gewohnt ist, doch etwas behäbig (und meinem Falcon fehlt eine entspr. GraKa). Und das MiNT gefällt mir außerordentlich gut! Voll eingerichtet (mit ext2 und sparemint) ist es wie eine weitere Linux-Distri und man fühlt sich gleich wie zu Hause :)
-
Klar, ich hätte sowieso auch den aktuellen trunk probiert. Ich werde heute abend mal den "helmut"-build auf aranym testen, am Wochenende dann evtl. auf dem TT.
Lass mal alles außer MiNT aus dem Auto-Ordner weg, mit TT-Mid oder so. Geht's dann immer noch nicht? Setz mal in mint.ini WRITE_BOOT=1. Steht dann was brauchbares in C:/mint/boot.lo[gh]?
Die letzte Änderung im CVS war jedenfalls am 3. Juli 2016 ..
-
Danke für die Info...aber dazu eine Verständnisfrage: Wo ist denn dann der Unterschied zwischen "trunk" und "helmut"?
-
Ziemlich viel. Aus dem Kopf: trunk hat 1024 handles pro prozess, helmut 32, trunk hat aktuellere USB-Funktionen, helmut hat bessere /dev/fd-Darstellung, Keyboard geht bei GEM=ROM, äh, die 000-Version nutzt das TOSFS (für hatari), weiß nicht ...
-
Ziemlich viel [...]
Oh, ah, da kommt doch langsam Licht ins Dunkel :) Für einen MiNT-Neuling wichtige Informationen, die nirgends zu erlesen sind.
Dann nur noch eine ergänzende Frage: Du sprachst davon, dass "die neue Version" (1-19 / xaaes.cnf) beispielsweise nvdi.prg nachladen kann ("exec c:\auto\nvdi") - betrifft das auch "trunk" oder ist das eine Spezialität von "helmut"?
Einstweilen wieder besten Dank für die Unterstützung! Ich bastel dann mal wieder am TT mit der 1-19-trunk herum...
-
Das geht nur mit dem neuen XaAES (also helmut). Die obige Liste enthält ja auch nur einige der Änderungen im kernel.
-
*räusper* Verzeih, wenn ich aber nochmal nachhaken muss: Kann man denn dann bspw. den Kernel aus trunk, aber xaaes aus helmut nehmen? Oder wäre das keine so gute Idee...?
Für heute lass' ich Dich aber in Ruhe...bekomme ja sonst noch ein schlechtes Gewissen!
-
Vor allem log ich mich immer gleich aus, und muss mich jedesmal einloggen für die Antwort ;)
Es müsste aber gehen: Mit den neueren Versionen müsste man alles aus helmut/trunk mischen können.
-
Neuer Versuch mit dem TT: Alles beiseite gepackt (einfach und flott Dank UltraSatan und ParCP), Platte gelöscht, keinerlei Extras wie NVDI etc. und Kernel/tools/driver aus 1-19-trunk, sowie XaAES aus 1-19-helmut.
Ergebnis wie bisher, ILLEGAL INSTRUCTION und MEMORY VIOLATION allerorten - sowohl mit 04092016, als auch mit 20092016. Dieses mal aber mit Log-Files! ;)
Die Logs sind quasi mehr oder weniger identisch, ich habe aber der Vollständigkeit halber beide Versionen angehangen.
-
Deinen Logs nach hat weder MiNT noch XaAES irgendein Problem. Beide scheinen sauber zu starten.
Anschließend wird versucht, Taskbar und Teradesk zu laden und die schmieren beide ab. Ersteres mit ILLEGAL INSTRUCTION, letzteres mit MEMORY VIOLATION. Nachdem anschließend nix mehr übrig ist, beendet sich XaAES (auch wieder fehlerfrei).
Ich würde zunächst mal versuchen, Taskbar und Teradesk noch mal sauber mit frischen Downloads zu installieren. Da scheint irgendwas faul zu sein.
-
...gerade mit den Binarys des Falcon verglichen (wo ja alles bestens läuft): 100% identisch.
-
...gerade mit den Binarys des Falcon verglichen (wo ja alles bestens läuft): 100% identisch.
die unter u:\c\mint\ ?
-
Ja...
-
Normalerweise beendet sich XaAES nicht, auch wenn alles andere abstürzt, im 2. log hat XaAES auch ein SIGTERM oder so empfangen.
Was war das noch für eine lib von den Franzosen? Lass das auch mal weg.
Ich hab gestern die aranym-Version von Alan getestet (helmut-20092016.tar.bz2), und es läuft alles mit und ohne MMU. Allerdings hab ich festgestellt, dass die mit gcc 4.9 kompiliert ist, Deine mit gcc 4.8. Vielleicht macht das ja was aus.
Ich würde auch noch alle autorun-Sachen aus xaaes.cnf weglassen, und die Sachen dann manuell (C-A-K) starten.
Weitersuchen ;)
-
...werde ich gleich mal angehen. Ich dachte halt, wenn alles auf dem Falcon tut, sollte es auch auf dem TT tun. Der einige Unterschied ist ja "nur", dass auf dem Falcon 1-18, auf dem TT 1-19 läuft.
Die lib ist das LDG: a GEM Dynamical Library system for TOS computer (http://ldg.sourceforge.net/)
Aber was meinst Du mit C-A-K ?
-
Control-Alternate-K (alles gleichzeitig!)
Ach ja: Hast Du schon ohne memory-protection probiert?
-
So, alles außer Teradesk abgeschaltet; fährt bis dahin auch fehlerfrei hoch. Sobald ich dann jedoch etwas mit C-A-K ;) (oder per Tera) starte, geht's wieder los. Ich würde auch sagen, dass mit Memory-Protection quasi gar keine Chance besteht, weitere Programme zu starten...nicht einmal ParCP. Ohne Memory-Protection läuft zumindest ParCP.
-
Hm, langsam gehen mir die Ideen aus ..
Mach mal für alle Fälle einen Sektortest (e2fsck -c X:, das Laufwerk X: darf dabei nicht gemounted werden, also badblocks und /bin/sh müssen woanders sein), oder in HDDRUTIL.
-
Defekte Sektoren kann ich soweit ausschließen, da es (derzeit, während der ganzen Testphase) über ACSI/UltraSatan läuft und die SD-Karte OK ist (getestet per dd). Das ext2-Laufwerk ist jetzt auch noch gar nicht betriebsbereit, da ich heute ja alles ganz neu eingerichtet habe und 1-19 soweit instabil läuft, dass ich noch nicht einmal mke2fs ordentlich gestartet bekomme, ohne dass es abschmiert.
Während ich dies schreibe, lasse ich den TT gerade mit 1-18-0 (die MAT in ST-High + NVDI5) laufen. Scheint wieder alles stabil zu laufen, ext2 ist auch gerade fertig - nur muss ich eben zunächst leider auf die 1024er Auflösung der MAT verzichten.
Aber wenn ich das richtig verstanden habe, hat bislang noch niemand außer mir die 1-19 auf einem echten TT getestet?
-
Doch ich hatte das auf dem Atari TT mit Nova Karte in 16bit Farbdarstellung laufen ohne Probleme.
Waren aber Daily Builds von 2014/2015 ...
Ich hatte immer den trunk benutzt auf dem TT.
-
Ich nutze 1-19-cur jeden Tag auf meinem (hoffentlich) echten TT. Was Du da erlebst, ist schon ziemlich schräg. Wenn 1-18 auf exakt der selben Plattform läuft, 1-19 aber nicht, dann weiß ich momentan keine Erklärung.
Diese Art Abstürze kenn ich eigentlich nur aus der Zeit, wo meine Festplatte zu heiß wurde, und Aussetzer bekam.
-
Doch ich hatte das auf dem Atari TT mit Nova Karte in 16bit Farbdarstellung laufen ohne Probleme.
Waren aber Daily Builds von 2014/2015 ...
Ich hatte immer den trunk benutzt auf dem TT.
Build von 2014/2015? Dann doch aber nicht 1-19?
-
Ich nutze 1-19-cur jeden Tag auf meinem (hoffentlich) echten TT. Was Du da erlebst, ist schon ziemlich schräg. Wenn 1-18 auf exakt der selben Plattform läuft, 1-19 aber nicht, dann weiß ich momentan keine Erklärung.
Ach...da brat' mir doch einen 'nen Stoch. Magst Du mir nicht mal Deinen Kernel, /mint und /tools mit den beiden CNFs mailen? Kann doch dann nicht sein, dass das 1-19 dann bei mir so herumzickt.
-
http://home.arcor.de/zabruder/atari/xamint.zip
-
Danke, mein Held :)
-
Irre...: Mit dem kleinen Archiv gibt es Fortschritte.
Lasse ich die MAT auf ST-High, bzw. TT-Mittel, scheint jetzt alles stabil mit der 1-19 zu laufen.
Switche ich aber auf die 1024er-Auflösung der MAT, hängt recht schnell der ganze TT...nix geht mehr.
Macht das noch groß Sinn, hier weiter zu experimentieren? Ich sehe in Zusammenhang mit meiner MAT derzeit kein Licht am Ende des Tunnels. Hilft Dir, Helmut, das denn auch überhaupt weiter, wenn ich weiter daran bastele?
Eine Idee hätte ich noch: Könnte man denn nicht XaAES aus 1-19 mit dem Kernel aus 1-18 laufen lassen oder passt das gar nicht zusammen?
-
Nee, das geht nicht.
Also sehe ich das richtig:
- Alans MiNT 1-19 geht auf dem TT gar nicht, meins aber ja.
- Mein MiNT geht mit nur der Matrix nicht.
Falls das so ist ergeben sich 2 Probleme:
- Was ist bei Alans MiNT kaputt (ich mein der hat aber auch einen TT)?
- Was ist mit der Matrix?
Zumindest letzteres kann ich die Tage mal auf meinem anderen TT probieren, der hat aber nur eine normale Matrix (C110ZV). Da hab ich 1024x1280x8. Ist aber schon eine Weile her.
Dann installier ich das freemint.org-MiNT mal auf meinem 1. TT, aber erst am Wochenenede. Vorher mach ich noch backup.
Spiel ruhig weiter mit meinem kernel, vielleicht ergibt sich ja noch mehr. Du kannst ja auch mal nur mein XaAES, und nur mein mint.prg nehmen, vielleicht geht nur eins nicht.
Wie sieht das jetzt mit den trunk-builds von freemint.org aus: Laufen die auch nicht?
-Helmut
-
Build von 2014/2015? Dann doch aber nicht 1-19?
Doch doch, die MiNT Mühlen mahlen sehr langsam ;-)))
-
Nee, das geht nicht.
Mist...dachte ich mir schon. Aber die Idee war gut ;)
Also sehe ich das richtig:
- Alans MiNT 1-19 geht auf dem TT gar nicht, meins aber ja.
- Mein MiNT geht mit nur der Matrix nicht.
Ja, wenn ich jetzt noch überhaupt durchblicke, stimmt diese Aussage.
Falls das so ist ergeben sich 2 Probleme:
- Was ist bei Alans MiNT kaputt (ich mein der hat aber auch einen TT)?
- Was ist mit der Matrix?
Seltsam, nicht? Irgendwie sind die ganzen Zusammenhänge nicht fassbar.
Zumindest letzteres kann ich die Tage mal auf meinem anderen TT probieren, der hat aber nur eine normale Matrix (C110ZV). Da hab ich 1024x1280x8. Ist aber schon eine Weile her.
Dann installier ich das freemint.org-MiNT mal auf meinem 1. TT, aber erst am Wochenenede. Vorher mach ich noch backup.
Spiel ruhig weiter mit meinem kernel, vielleicht ergibt sich ja noch mehr.
-Helmut
Prima, tausend Dank. Hat ja auch keine Eile und wir/ich sind ja schon ein gutes Stück weiter gekommen, finde ich. Der Falcon läuft, der TT im Prinzip auch, nur in Zusammenhang mit der MAT TC bleiben Fragen offen.
Ich mache mir jetzt erst einmal mit einem Bier den Kopf frei nach so vielen Stunden und Tagen Atari/MiNT und trinke auf Euch! :)
Wie ich mich kenne, werde ich morgen/die Tage wieder die eine oder andere Idee haben und ausprobieren. Wenn es dabei etwas berichtenswertes gibt, werde ich es kundtun.
-
Auf die Gefahr hin, dass ich mich jetzt mächtig in die Nesseln setze und eine saudumme Frage stelle, aber hast Du mal die Grafikkarte ausgebaut und es ohne die Karte mit einem aktuellen Trunk von MiNT 1.19 versucht?
Doch doch, die MiNT Mühlen mahlen sehr langsam ;-)))
Oh ja. Das ist wohl so. Außer zwischen MiNT 1.17.0 und 1.18.0 lag nur ein knappes Jahr. Da hatte ich schon Angst, es stimmt was nicht. >:D Rechne nicht vor 2020 mit einem finalen MiNT 1.19.0. ;D
-
Mit meinem aktuellem MiNT läuft die Matrix auch nicht. XaAES stürzt in v_opnwk ab.
Mit dieser alten Version
http://home.arcor.de/zabruder/atari/xamint14.zip
geht's aber.
-Helmut
-
Ursache ist der fix für NVDI-ET4000 (wechsel nach C: vor dem v_opnwk). Jetzt weiß ich nur nicht, wie ich das ohne neue Konfigurations-Variable möglichst genau unterscheiden kann. Also wann ist NVDI mit einer ET4000 geladen? Die CrazyDots läuft ja angeblich auch mit NVDI5, was ich auf dem Matrix-TT auch habe.
Übrigens starte ich NVDI5 vor MiNT, und lade dann den Matrix-Treiber aus xaaes.cnf, nicht umgekehrt, wie ich das mal behauptet habe.
Hab mal einen screenshot gemacht (die kaputten Farben kommen von dem snapshot-Programm).
(http://forum.atari-home.de/index.php?action=dlattach;topic=13118.0;attach=12250;image)
-
Also wann ist NVDI mit einer ET4000 geladen?
Vielleicht über einen Cookie. Zumindest für die Matrix (http://toshyp.atari.org/de/003007.html#Cookie_2C_20MaTC) gibt es einen. Kann sein das der aber nur vom Matrix Treiber gesetzt wird und nicht von NVDI.
Ansonsten fällt mir noch vq_ext_devinfo (http://toshyp.atari.org/de/Inquire_functions.html#vq_ext_devinfo) ein. Steht unter umständen im Klartextnamen.
-
Wie ich das sehe, braucht man dafür ein wk-handle. Das hab ich da aber noch nicht.
Auf dem Matrix-TT gibt es einen cookie VSCR (sysinfo sagt dazu: virt. Bildschirm nicht aktiv). Ist der vom Matrix-Treiber? Im toshyp finde ich keine Auflistung der cookies, wo war die noch?
Ich hab jetzt erstmal für die CrazyDots die et4000_hack-Option verwendet, dann geht es auf beiden.
-
Im toshyp finde ich keine Auflistung der cookies, wo war die noch?
http://toshyp.atari.org/de/003007.html#Cookie-_20und_20XBRA-Liste
-
Ah ja, danke. Da steht:
VSCR Julian F. Reschke (Standardcookie) Structure of Virtual Screens
Dann ist das wohl was anderes.
Wie ist denn jetzt mit der TC-Matrix??
-
...bei mir dbzgl. noch nichts neues. Ich hatte in den letzten Tage nur noch vereinzelte (aber erfolglose) Versuche auf dem TT unternommen, bis ich dann am Wochenende feststellte, dass das UltraSatan aus bislang unbekannter Ursache Müll auf die SD schreibt. Je länger und öfter es die Daten anfasste, umso kaputter waren sie. Jetzt habe ich wieder die GigaFile in Betrieb und habe zunächst einmal wieder alles dort ausgepackt.
Ich sehe erstmal zu, dass der TT ohne MAT-TC- und ohne NVDI-Treiber mit der 1-18 stabil läuft, danach das selbe mit der 1-19 und dann packe ich die beiden Treiber dazu.
Übrigens starte ich NVDI5 vor MiNT, und lade dann den Matrix-Treiber aus xaaes.cnf, nicht umgekehrt, wie ich das mal behauptet habe.
NVDI5 vor MiNT ist klar, aber welcher ist denn der eigentliche MAT-Treiber? Die Reihenfolge bei mir ist INIT, REDIRECT, NVDI, SLCT_DEV ... MINT
-
NVDI ist der Grafikkarten Treiber. Das Matrix INIT ist das Hilfsprogramm der original Matrix Treiber Software die NVDI MAT/TC braucht.
-
...ich weiß nicht. So würde doch aber Helmut's Aussage keinen Sinn ergeben, denn er lädt ja erst NVDI und dann den Matrix-Treiber. Es sei denn, er lädt andere Treiber, da er ja auch eine andere MAT hat...
-
Zweimal Treiber für die gleiche Sache ... ?
Oder meint Helmut das normale NVDI und nicht das NVDI Matgraph CXX ?
Der Unterschied ist ja nur das Helmut das NVDI Matgraph CXX nutzen muss und du die TC Version vom NVDI.
-
So sieht mein Auto-Ordner aus (unsortiert):
-rwxr-xr-x 1 root wheel 2061 Mar 1 1996 redirect.prg
-rwxr-xr-x 1 root wheel 320651 Feb 9 2014 nvdi.prg
-rwxr-xr-x 1 root wheel 30556 Jun 9 1994 slct_dev.prg
-rw-r--r-- 1 root wheel 282169 Mar 16 2014 mint030.pr
-rw-r--r-- 1 root wheel 4818 Dec 31 1979 nvdivga.inf
-rw-r--r-- 1 root wheel 30556 Feb 9 2014 slct_dev.pr1
-rwxr-xr-x 1 root wheel 284779 Jul 3 17:30 mint119.prg
drwxr-xr-x 2 root wheel 2048 Mar 15 2014 a
In XaAES mach ich dann:
install -P NVDI,SDEV C:\matrix\cxx_driv.ttp C:\matrix\cxx\12x10x9.cxs
Das kann man aber wahrscheinlich auch vom Auto-Ordner (nach MiNT?). Nur ist die Text-Ausgabe danach unleserlich. Die -P-Option soll (wahrscheinlich, weiß nicht mehr genau) verhindern, dass cxx_driv gestartet wird, wenn nicht NVDI und SDEV geladen sind. Was jedenfalls nicht geht, ist XaAES beenden und neustarten. Evtl. später mal.
Interessant ist vielleicht noch was sich in trap2 abspielt:
Vor cxx_driv und v_opnwk:
88(aes/vdi:Trap 2)--Adress:01104cea----------------------------
SDEV->:01053068 flag:04384e75
NVDI->:010002ac flag:18784e75
RDCT->:00e1354c flag:000c4e75
Danach:
88(aes/vdi:Trap 2)--Adress:0114a54e----------------------------
MiNT->:010534fe flag:00000000
NVDI->:01104cea flag:000c4e75
SDEV->:01053068 flag:04384e75
NVDI->:010002ac flag:18784e75
RDCT->:00e1354c flag:000c4e75
Nach Beenden von XaAES (also v_clswk):
88(aes/vdi:Trap 2)--Adress:01104cea----------------------------
SDEV->:01053068 flag:04384e75
NVDI->:010002ac flag:18784e75
RDCT->:00e1354c flag:000c4e75
Also alles wie vorher.
Im Xbios-Trap ist auch was:
b8(xbios:Trap 14)--Adress:0114a234-----------------------------
MiNT->:01104d2e flag:600001c6
SDEV->:01051ab4 flag:000c4ed0
NVDI->:01000274 flag:000c4ed0
RDCT->:01008d38 flag:000c4ed0
M_IN->:00e00d9c flag:42404e75
Keine Ahnung was M_IN ist.
-Helmut
-
Keine Ahnung was M_IN ist.
Das stammt vom cxx_info.tos und installiert ein paar zusätzliche XBIOS Funktionen.
Mit der Funktion 0x7D02 kannst Du feststellen ob es vorhanden ist. Denn nach dem Aufruf, ohne Parameter, bekommst Du 'CxOK' (0x43784F6B) zurück.
Das Programm ist ziemlich Dumm, denn es testet nicht ob tatsächlich eine Grafikkarte vorhanden ist.
Man muss nun unterscheiden ob eine COCO oder TC Grafikkarte vorhanden ist. Bei letzteren heißt das Programm tcxxinfo.tos und die Funktion ist 0x7918 liefert als Rückgabe 'TcOK'.
-
Ich habe diesen Thread mit Interesse verfolgt, weil ich einerseits auch eine Matrix CoCo besitze (derzeit aber nicht betreibe), andererseits ungefähr ebenso große Probs bei der Installation von M_1.18.0, M_1.19.cur & XaAES auf meinem Falcon habe. Was mir auffiel:
Da gab es doch den Rumor, daß NVDI_5.0x nur unter MAGX stabil läuft. ASH hatte mir deshalb als Downgrade die Version 4.12 geschickt, die auf meinem TT mit CrazyDots-GK und MiNT_1.15.9 zufriedenstellend läuft (dort bisher noch keine Versuche mit neueren MiNTs, die mache ich erst, wenn ich´s auf dem F30 auf die Reihe gekriegt habe).
PS: Im Anhang eine _etwas_ vollständigere Cookie-Liste, die für LINNHE geeignet ist (und nach Ersetzung ": *" -> "" (* = Joker) auch für SHAURI)
-
Ist das was dabei was nicht im toshyp ist? Wo ist die her? M_IN kommt übrigens auch nicht vor.
Aber danke.
-
Ja, einiges.
Selbst zusammengesetzt aus mehreren Listen unterschiedlichster Herkunft.
-
[...]
Ich sehe erstmal zu, dass der TT ohne MAT-TC- und ohne NVDI-Treiber mit der 1-18 stabil läuft, danach das selbe mit der 1-19 und dann packe ich die beiden Treiber dazu.
Sodala, nach ein paar Wochen Grippe und chronischer Unlust habe ist das ganze Thema frisch aufgezogen.
Stand der Dinge ist
- 1.18.0 läuft auf dem TT (nackter NVDI, also ohne MAT-Treiber), wie auch auf dem Falcon einwandfrei
- 1.19-CUR, mein Sorgenkind, läuft scheinbar mittlerweile auch ohne zu Murren - mit MAT+NVDI in 1280er-Auflösung mit 256 Farben. Als ob es nie ein Problem gegeben hätte, und das mit den bisherigen Configs.
Ein Grund für die ganzen Probleme und seltsamen Phänomene könnte vielleicht die NVRAM-Batterie des TT gewesen sein. Solange die nämlich drin war und scheinbar auch funktionierte (Datum und Uhrzeit stets aktuell), gab es die komischsten Vorkommnisse, wie MAT will nicht initialisieren (Palette nicht gefunden); totale Hänger in MiNT; Programme starteten, aber fanden keinen Pfad zu "sich selbst" und und...
Also Batterie raus, mit BOOTCONF das NVRAM zurückgesetzt (was ein paar Anläufe und ein- ausschalten des TT brauchte) und seit dem ist Ruhe. Warum auch immer. Auch scheint seitdem das Problem aus http://forum.atari-home.de/index.php?topic=13143 (Boot-Problem TT+MatTC+Parallel-Port) fort zu sein.
Das NVRAM soll mir Wurscht sein; Datum und Uhrzeit besorgt mir mittlerweile ein CosmosEx (am ACSI) und MagiC und MiNT rennen flott und schön und ich hatte die letzten Tage viele schöne Stunden am TT.
Ich hoffe, das bleibt jetzt so ;) aber dennoch vielen vielen lieben Dank an alle, die in welcher Form auch immer dazu beigetragen haben!
-
Sehr schön. Welche 1.19-Version nimmst Du denn jetzt? Die normale vom trunk? Ich weiß nämlich immer noch nicht wie ich den CrazyDots/Matrix-Konflikt lösen soll.
-
Es ist vollständig die helmut-10102016. Mit trunk-* kam ich nie weit und hatte ganz schnell die eingangs erwähnten Probleme in Zusammenspiel mit der MAT TC/NVDI.
Und auch gestern, wie jetzt gerade fährt der TT ohne Batterie/NVRAM ohne Probleme hoch und alles ist toll :) Manchmal machen halt die kleinsten Dinge den größten Ärger :(
-
Mit der Version von freemint.org? Das würde ja bedeuten, dass das nur mit meiner Matrix nicht so geht. Wird ja immer doller ...
Der Sache mit dem NVRAM würde ich aber irgendwann mal nachgehen, oder nicht.
-
Mit der Version von freemint.org? Das würde ja bedeuten, dass das nur mit meiner Matrix nicht so geht.
Ja, mit "Deiner" von freemint.org. Welche Matrix hast Du noch einmal?
Der Sache mit dem NVRAM würde ich aber irgendwann mal nachgehen, oder nicht.
Dazu muss ich jetzt meine vorige Aussage etwas einschränken: Gestern wollte trotz fehlender Batterie die MAT nicht initialisieren. Erst nach ein paar Resets des NVRAM mittels BOOTCONF überlegte sie es sich anders und alles tat dann wunderbar seinen Dienst. Komisch. Aber notfalls kann ich damit durchaus leben.
-
C110ZV. Die Matrix ist ja eigentlich auch nicht das Problem, sondern NVDI-ET4000. Schätze, da werde ich eine extra-Option für xaaes.cnf (also et4000_hack -> chg_drive_c oder sowas) einführen. Und dann kann ich die ganze Doku nochmal ändern ...
Vielleicht ist es ja ein Kontakt-Problem im VME-Bus?
-
Der Atari TT kann schonmal spinnen wenn Mist im NVRam steht ...
-
-^^- Sehr richtig! Also, RealLarry, kauf Dir gefälligst eine neue Batterie (hält leider nmE. nur drei Jahre).
-------
Es muß NVDI.PRG vor MINT.PRG im AUTO\ stehen! Sonst, @HelmutK , ist es kein Wunder, wenn Du BuchstabenSalat kriegst!
Dazwischen kommt DEV_SLCT.PRG (oder bei anderen GK das entsprechende); damit werden die Treiber ausgewählt; die stehen weder in NVDI.PRG noch in DEV_SLCT.PRG selber, sondern da, wo ASSIGN.SYS angibt (für gewöhnlich in einem UnterOrdner von c:\GEMSYS\).
Das kann nicht gesund sein, dafür eine ´extra-Option für xaaes.cnf´ einzubauen! (Sonst macht die nächstbeste andere GK evtl. wieder Probleme).
Und nein, ein HW-Problem ist das nmE. nicht!
Nochmals der dezente Hinweis, daß es vielleicht lohnen könnte, NVDI_4.12 statt 5.xx zu nutzen (außer mit MAGX, damit funzt 5.xx).
-
Wer sagt denn was von Buchstabensalat? Keine Sorge, ich mach das schon richtig ;)
Und NVDI-ET4000 ist doch wohl NVDI 4.12. Ich hab das damals getraced: NVDI nimmt für alle Pfade
X:\..., außer für NVDIVGA.INF, da fehlt das X: (X: ist das boot-Laufwerk). Daher klappt das nur, wenn XaAES vor v_opnwk auf X: (also sysdrv) wechselt. Und genau das macht mit der Matrix aus unerfindlichen Gründen Probleme, aber offenbar nur bei mir.
-
-^^- hier scheinen sich zwei Threads zu berühren:
Als Geneva sich beschwerte, es finde sein JAR30 nicht, hatte ich den Verdacht, daß das am falschen ActDir liegen könnte. Also habe ich versucht, das aktuelle Directory mit MCMD auf E:\AUTO\ zu setzen - was aber anscheinend mißlang! Ich habe das dann zunächst nicht weiter verfolgt (es gab dringenderes zu tun...).
Vielleicht liegt die Ursache des Problems schlicht daran, daß neueres MiNT partout selbst das ActDir auf u:\ setzt!
-------
In meiner Sammlung habe ich drei Versionen von NVDI mit der Variante ´ET4000´ , nämlich 2.12, 2.51 und 2.11R8; afaik sind die zugeh. Treiber identisch, also bis heute unverändert; maW.: die Variante besteht nur in diesen.
Ich hatte zunächst geglaubt, daß NVDI_5.xx problemlos auch mit älteren Treibern umgehen kann (zB. mit denen aus 4.12) - bis ich einen winzigen kleinen Haken entdeckte, der aber nicht in der Schuld des NVDI liegt, sondern mit älteren Prgen. auftritt, die die VDI-Hdl. des AES mißbrauchen! Mir hat dieser Haken dann dazu gedient, Prg. mit solchem Mißbrauch zu entlarven (und auch, meine eigenen diesbezüglichen Fehler zu korrigieren...).
-------
Das hier:Nur ist die Text-Ausgabe danach unleserlich.
aus Deinem Beitrag #64 meinte ich mit ´Buchstabensalat´ ;)
-------
Nachtrag: Wenn bloß ein "X:" fehlt, dann ließe sich das Problem doch mit einem einfachen Pätsch im NVDI.PRG erledigen?! Bloß "NVDIVGA" etwas kürzen, dann paßt´s.
Noch´n Nachtrag zum Nachtrag: Damit ist _nicht_ gemeint, ein Patch-Prg. zu schreiben!
Höchstens nen kleinen Text mit Anweisung für Betroffene, was zu tun wäre - aber vorher müßte das erstmal ausprobiert werden: Wenn´s funzt, dann heureka, wenn nicht, so what?
Wenn noch andere NVDIVGA.INF benutzen, dann müssen die natürlich genauso gepatcht werden.
PS: Entia non sunt multiplicanda praeter nesessitatem!