MiNT/XaAES und MAT TC

[RealLarry]

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

[Lukas Frank]

NVDI ist der Grafikkarten Treiber. Das Matrix INIT ist das Hilfsprogramm der original Matrix Treiber Software die NVDI MAT/TC braucht.

[RealLarry]

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

[Lukas Frank]

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.

[HelmutK]

So sieht mein Auto-Ordner aus (unsortiert):

Code: [Auswählen]

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

Code: [Auswählen]

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:

Code: [Auswählen]

  88(aes/vdi:Trap 2)--Adress:01104cea----------------------------
  SDEV->:01053068 flag:04384e75
    NVDI->:010002ac flag:18784e75
      RDCT->:00e1354c flag:000c4e75

Danach:

Code: [Auswählen]

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

Code: [Auswählen]

  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:

Code: [Auswählen]

  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

[KarlMüller]

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

[ari.tao]

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)

[HelmutK]

Ist das was dabei was nicht im toshyp ist? Wo ist die her? M_IN kommt übrigens auch nicht vor.

Aber danke.

[ari.tao]

Ja, einiges.
Selbst zusammengesetzt aus mehreren Listen unterschiedlichster Herkunft.

[RealLarry]

[...]
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!

[HelmutK]

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.

[RealLarry]

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

[HelmutK]

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.

[RealLarry]

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.

[HelmutK]

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?

[Lukas Frank]

Der Atari TT kann schonmal spinnen wenn Mist im NVRam steht ...

[ari.tao]

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

[HelmutK]

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.

[ari.tao]

-^^- 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!