Aktuelles MiNT/XaAES und NVDI ET4000 ...

[mfro]

ext2 ist aber auf jeden Fall empfindlicher. Mit C: hab ich ja auch ein etwas mulmiges Gefühl, aber dass das viel cached, glaub ich nicht. Und von C: ist alles 1:1 gesichert, im Ggs. zum ext2. Mal gucken

C: ist nur dann gecached, wenn Du das in der MINT.CNF (FS_WB_ENABLE) auch so einrichtest (und das würd' ich - zumindest für's Bootlaufwerk - eher nicht empfehlen).

[Lukas Frank]

Auch das opnwk10.prg funktioniert nicht bei 32k Farben, seltsamerweise läuft es aber mit 256 Farben !?!

Irgendwo hast du da einen Fehler drin ...


Du hast doch eine CrazyDots und auch NVDI ET4000 ...

[HelmutK]

Bei mir auch nicht. Konnte mich gestern nicht zurückhalten und hab's mal kurz probiert (->fsck). Ich bin mir auch nicht so sicher, ob die Nummer überhaupt eine Bedeutung hat, oder die kommt har nicht nach work_in[0], wer blickt da schon durch ...

[Lukas Frank]

... wer blickt da schon durch ...

Ich auf jeden Fall nicht :-)))

[KarlMüller]

Bei mir auch nicht. Konnte mich gestern nicht zurückhalten und hab's mal kurz probiert (->fsck). Ich bin mir auch nicht so sicher, ob die Nummer überhaupt eine Bedeutung hat, oder die kommt har nicht nach work_in[0], wer blickt da schon durch ...

Wenn ich das richtig verstanden haben gibt es wohl Probleme beim öffnen der VDi Workstation. Ich habe mir k_init.c nicht bis ins letzte angeschaut, mir fällt da nur folgendes auf:

Überall wo die Workstation geöffnet werden soll wird, in der Regel in work_in[0] eins gesetzt, beim Milan ist es wohl fünf. Also laut Aussage von Mike Fulton ist grundsätzlich Getrez()+2 zu nehmen.

[HelmutK]

Das mit dem Getrez steht ja auch im toshyp, aber ich glaub das gilt bei Grafikkarten nicht mehr. In XaAES ist work_in[0] das was man als VIDEO= angibt, sonst 1, mehr oder weniger. Hab ich nat. auch probiert: Ohne opnwk, und als video diese Nummer: Geht nicht.

[HelmutK]

Hab jetzt *Stunden*  verbraten, um einen VDI-handler in MiNT einzubauen ....

Klappt jetzt aber. Bei XaAES kommt auf aranym/fVDI in work_in:

v_opnwk: 1:1:1:1:1:1:1:1:1:1:2:0:0:0:0:0

Und bei N.AES:

v_opnwk: 5:1:1:1:1:1:1:1:1:1:2:336:7560:336:7560:336

Signifikant sind wahrscheinlich nur die ersten 11 Werte, also bis zur 2. Man sieht, N.AES (das ja laut Frank mit MiNT und ET4000 keine Probleme hat), nimmt 5 als work_in[0], XaAES 1.

Ob das was zu sagen hat?

So, bin erstmal geschafft!

-Helmut

[Lukas Frank]

Vielleicht ist das jetzt der totale Blödsinn aber ist es nicht so das MiNT/XaAES 1.16 noch einwandfrei auf Grafikkarten mit NVDI als Treiber lief und dann danach irgendwann nicht mehr ?

@ Helmut: ... hast du denn jetzt einem deiner TT mit CrazyDots aufgebaut zum Probieren ?

Bei der Matrix NVDI CXX/TC Version sollte doch das gleiche Problem bestehen, oder nicht ?

[Arthur]

Hab jetzt *Stunden*  verbraten, um einen VDI-handler in MiNT einzubauen ....

Klappt jetzt aber. Bei XaAES kommt auf aranym/fVDI in work_in:

v_opnwk: 1:1:1:1:1:1:1:1:1:1:2:0:0:0:0:0

Und bei N.AES:

v_opnwk: 5:1:1:1:1:1:1:1:1:1:2:336:7560:336:7560:336

Signifikant sind wahrscheinlich nur die ersten 11 Werte, also bis zur 2. Man sieht, N.AES (das ja laut Frank mit MiNT und ET4000 keine Probleme hat), nimmt 5 als work_in[0], XaAES 1.

Ob das was zu sagen hat?

So, bin erstmal geschafft!

-Helmut

@Helmut du bist der Beste. Danke für deine Arbeit 

[HelmutK]

Wofür? Noch ist nicht viel gewonnen. Aber das hatte ich schon lange vor, damit kann man auch sowas wie remote-screen (über Internet:)), Druckertreiber, und Debugger/Profiler realisieren, irgendwann irgendwer. Ich versteh nur nicht, wie ich so lange so auf dem Schlauch stehen konnte, egal.

@Frank: MiNT 1.16 dürfte sich ja sicher noch auftreiben lassen, probier's einfach.

Natürlich hab ich den TT mit ET4000 hier, hab mich noch nicht getraut, das da zu testen.

Theoretisch könnte VIDEO=5 jetzt in xaaes.cnf die Lösung sein, ohne opnwk, aber ich glaub nicht, dass es so einfach ist.

Edit: Auf dem TT läuft N.AES mit der ET4000 ohne Probleme. Diesmal benutzt es 8 in work_in[0]. XaAES läuft damit aber immer noch nicht. Also weitersuchen ...

-Helmut

[Lukas Frank]

MiNT 1.16 dürfte sich ja sicher noch auftreiben lassen, probier's einfach.

... gerade probiert und geht natürlich nicht !

[HelmutK]

Jetzt hab ich alles imitiert was N.AES bzw. der TOS-Desktop bei GEM=ROM bei v_opnwk macht, und geht immer noch nicht.

XaAES knallt immer beim Zugriff auf die Adresse 0xD02000 im v_opnwk-Aufruf, also eigentlich stürzt NVDI ab. An der Adresse ist aber nichts, nicht vorhanden. Sagt das jemandem was?

-Helmut

[Arthur]

Sorry Helmut, kenn mich mit Programmieren überhaupt nicht aus. Doch ich denke, auch wenn es noch nicht klappt, das der Ansatz der Richtige ist es wie im NAES zu implementieren.

Edit: Lass und das auch testen... mit verschiedenen Grafikkarten um zu sehen ob es irgendwo doch läuft. Evtl. ist es nur eine Kleinigkeit. Welches MiNT Version benutzt Du zum Testen und wo liegt deine XaAES-Variante mit dem Du jetzt testest?

[HelmutK]

Das Problem tritt nur bei NVDI/ET4000 auf. Das würde nichts bringen, mit anderen Karten, und MiNT sowie XaAES sind Baustellen zur Zeit.

Aber da stimme ich zu: Ist sicher nur eine Kleinigkeit. Irgendwas muss ich übersehen. Wenn ich mein opnwk.prg von der shell aus aufrufe, tritt genau der gleiche Fehler auf (0xd02000), obwohl das mit purec-c kompiliert ist, kann also auch nicht an irgendwelchen bindings oder gcc-Eigenheiten liegen.

Das vdi-binding für v_opnwk in XaAES hab ich auch schon 2x geändert, immer das selbe.

Muss ich wohl erst mal drüber schlafen

-Helmut

[Lukas Frank]

Also bei einer Matrix Grafikkarte und NVDI CXX oder TC als Treibersoftware je nach Karte tritt das Problem nicht auf ?

[HelmutK]

Nein. TC weiß ich allerdings nicht.

Was ist eigentlich mit EmuTOS: Gibt's da eine Chance mit dem Mega-STE?

[Lukas Frank]

Das bedeutet ja dann das alle NVDI Grafikkarten Versionen betroffen sind.

Kann es sein das XaAES ausschliesslich bei "video =" die Standard ST/TT Auflösungen unterstützt und nichts wissen will wenn die Auflösungen anders sind ?

Code: [Auswählen]

If you don't have a Falcon <mode> can be:
# -----------------------------------------
#   - 2 =  320*200,  16 colour (ST-Low)
#   - 3 =  640*200,   4 colour (ST-Medium)
#   - 4 =  640*400,   2 colour (ST-High)
#   - 6 =  640*480,  16 colour (TT Medium)
#   - 8 = 1280*960,   2 colour (TT High)
#   - 9 =  320*480, 256 colour (TT Low)
#   
#   All other values are ignored!

All other values are ignored!

[HelmutK]

So ein Quatsch! XaAES übergibt die Treibernummer an v_opnwk, der Rest ist VDI (und das stürzt dann ab), da gibt es nichts zu "unterstützen". Erst dachte ich ja, MiNT ändert irgendwas, weil es ja ohne MiNT klappt. Aber wenn N.AES ohne Probleme mit MiNT läuft, und auch der TOS-Desktop, der sicher nichts von MiNT oder ET4000 weiß, muss es noch was anderes geben.
Das was Du da zitierst, bezieht sich auf die eingebaute Standard-Grafik.

Wenn mir gar nichts mehr einfällt frag ich vielleicht die Behnes oder diesen Mannigel. Aber so weit ist es noch nicht.

Probier doch mal EmuTOS!

-Helmut

[Lukas Frank]

Ohne Ahnung ist man vor Quatsch nicht gefeit ;-)))

[HelmutK]

So, geht jetzt.

Lösung vorerst (vorausgesetzt NVDIVGA.INF ist in C:\AUTO):

ln -s /c/auto /auto

oder in mint.,cnf:

sln c:\auto u:\auto.

NVDI kann sonst NVDIVGA.INF nicht finden.

slct_dev muss offenbar gestartet worden sein.

In xaaes.cnf VIDEO=6  (für 8 bit), und et4000_hack=0 (oder weglassen), opnwk nat. nicht starten.

Ich bin mir nicht sicher, ob von meinen Änderungen, die noch nicht im cvs sind, welche eine Rolle spielen, aber vielleicht läuft es ja schon mit den freemint.org-builds.

-Helmut