MiNT/XaAES und MAT TC

[RealLarry]

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?

[Lukas Frank]

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 ...

[RealLarry]

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

[RealLarry]

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?

[ari.tao]

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))

[Lukas Frank]

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 ...

[RealLarry]

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.

[RealLarry]

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.

[Lukas Frank]

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 ...

[HelmutK]

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

[RealLarry]

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...

[HelmutK]

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

[RealLarry]

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.

[Lukas Frank]

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.

[HelmutK]

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

[RealLarry]

...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?

[HelmutK]

...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

[RealLarry]

...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 

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.

[HelmutK]

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

[RealLarry]

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