atari-home.de - Foren
Hardware => Emulatoren => Thema gestartet von: Thorsten Otto am So 24.05.2020, 13:40:06
-
Zu Test-Zwecken hab ich mal ein paar kleine Programme zusammen gestellt.
Eines dieser Programme ist dazu gedacht, das Verhalten von vq_scrninfo heraus bekommen (da scheint es irgendwie noch Diskrepanzen sowohl in der Beschreibung, als auch in der Implementation zu geben).
Könnte das mal jemand auf "echten" Maschinen laufen lassen, mit verschiedenen NVDI-Versionen? Es erzeugt eine Datei "scrninfo.txt" im aktuellen Ordner.
-
Atari TT Matrix TC1208 NVDI Matgraph TC 800x600 16,7M Farben
OPENBM sind alle Objekte immer Rot. OPNBM wechselt von Rot nach Blau.
-
... Eines dieser Programme ist dazu gedacht, das Verhalten von vq_scrninfo heraus bekommen (da scheint es irgendwie noch Diskrepanzen sowohl in der Beschreibung, als auch in der Implementation zu geben).
Nachdem das eine "Behne&Behne"-Funktion ist (gibt's im originalen DRI VDI nicht, da ist das device-specific format "off limits", genauso wie in GKS), dürfte die einzig massgebliche Dokumentation wohl die hier sein: http://www.nvdi.de/gb/Download/nvdi4doc_gb.lzh
Welche Diskrepanzen gibt's denn konkret?
-
Welche Diskrepanzen gibt's denn konkret?
U.a. die hier:
intout[0..272] work_out[0..272] erweiterte Informationen
Meaning of work_out:
Nachfolgend werden dann 272 Ausgabewerte beschrieben (was auch Sinn macht, weil ab #16 nur noch 256 Einträge für die Pixelwerte kommen). Der erste Satz impliziert aber für mich, daß die Funktion 273 Ausgabewerte hat. Und Enhancer.prg schreibt auch tatsächlich in manchen Fällen 273 Werte.
Der Abschnitt aus der Html-Doku steht auch sinngemäss so in neue_fkt.txt, die bei Enhancer dabei liegt.
Abgesehen davon sollte die Funktion eigentlich in NVDI 2.5x implementiert sein, ist sie aber scheinbar nicht (oder fehlerhaft, ich bekomme jedenfalls immer nur die Werte von vq_extnd(1) stattdessen)
-
Nachfolgend werden dann 272 Ausgabewerte beschrieben (was auch Sinn macht, weil ab #16 nur noch 256 Einträge für die Pixelwerte kommen). Der erste Satz impliziert aber für mich, daß die Funktion 273 Ausgabewerte hat. Und Enhancer.prg schreibt auch tatsächlich in manchen Fällen 273 Werte.
Das riecht ja irgendwie nach klassischem "off-by-one" Fehler?
Dich interessiert jetzt, ob im letzten Farbregister Müll steht oder ob das ganze Array um eins "verrutscht" abgelegt wird?
Beides wär' wohl ein Fehler...
-
Das mit den 273 Werten scheint wohl nur ein Fehler in der Beschreibung, und in Enhancer zu sein.
Mich interessiert eigentlich eher ob NVDI 2.x vq_scrninfo überhaupt unterstützt, oder ob ich irgendwo 'nen Denkfehler habe. Wenn's nicht unterstützt wird, dürften off-screen-bitmaps dort vermutlich gar nicht funktionieren.
In dem Zusammenhang wären auch andere Programme interessant, die off-screen-bitmaps benutzen. Ich kenne nur keine...
-
Wenn der EdDI Cookie gesetzt ist, ist davon auszugehen, dass vq_scrninfo funktioniert.
Zitat:
"NVDI (and also the ENHANCER for the ATARI-VDI) will place an 'EdDI' cookie in the cookie jar containing a dispatcher address in the cookie's value. The dispatcher uses Turbo C/Pure C calling conventions (register d0 contains the opcode; registers d1-d2/a0-a1 and the stack may be used for additional parameters).
Till now only opcode 0 is implemented. This opcode returns the 'EdDI' version number.
Version 1.00 (return value is $100) supports v_opnbm, v_clsbm and vq_scrninfo."
Quelle:
http://toshyp.atari.org/en/003007.html#Cookie_2C_20EdDI
Offscreen Bitmaps wären schon interessant, ... aber vq_scrninfo gibt nicht auf allen Systemen korrekte Werte für das Screen-Format zurück. Die Funktion ist definitv öfters in Verwendung als die Bitmap Funktionen.
IMO verwendet z.B. Jean-François Lemaire offscreen Bitmaps für seine Tools: http://gemdict.org
-
Wenn der EdDI Cookie gesetzt ist, ist davon auszugehen, dass vq_scrninfo funktioniert.
ja, sollte man wohl annehmen, tut es aber scheinbar nicht. Zumindest nicht in NVDI 2.5x, wo die Funktion eingeführt wurde. Vlt. müsste man sich das mal genauer im disassembler anschauen, das Programm war da ja noch halbwegs überschaubar. Erst ab NVDI 3.x scheint es zu funktionieren.
Offscreen Bitmaps wären schon interessant
Ja, schon. Man müsste man sich was schlaues überlegen wie man das mit den monochromen Bitmaps handelt. NVDI hat die Treiber ja ab 3.x (wohl auch ua. deshalb) in Bildschirm-Treiber und off-screen-Treiber aufgeteilt. fVDI läd aber nur einen Treiber, den für den Bildschirm.
-
Kleines Update: der Aufruf von vq_scrninfo() scheint auch mit NVDI 2.x zu funktionieren, wenn man das physikalische Handle benutzt (das, was man mit graf_handle() bekommt). Es funktioniert aber unlogischerweise nicht bei einem virtuelle VDI handle (eins, das man mit v_opnvwk() bekommen hat).