ATI Graka Speicher lesen mit VESA

[Xpyder]

Erstmal: Bin neu. Falls OffTopic, bitte Nachricht.

Hab neulich festgestellt, dass auf ATI-Grakas (und
scheinbar NUR dort) das Umschalten des
Grafikspeicher-Segments NUR fuer Schreiben und NICHT fuer
Lesen gemacht wird. (Will sagen: Schreiben kann ich in den
ganzen Speicher, lesen nur die ersten 64k). Hat einer ne
Ahnung, ob man das Problem irgendwie umgehen kann
(vielleicht Aufruf einer Routine oder setzen von Flags in
irgendeinem VESA-Int)?

Achso: Bitte nichts, was mit Direct-X, Windows oder
Windows-Treibern zu tun hat. Suche nach einer 16-Bit-DOS-
Loesung.

[toxl]

Komisch. Du könntest es mit dem linearen framebuffer probieren, dann hast du den ganzen VGA-RAM an einem Stück. Gibt's ab VESA 1.2 oder so, kann also praktisch jede Karte. Funktioniert allerdings normalerweise nur im 32-Bit Modus, oder im "Unreal Mode" (16-Bit Modus mit 4G Segmentlimit, falls du den Trick kennst).

[Xpyder]

Hm. Linearen FrameBuffer wollte ich ja vermeiden, da, wie
richtig angemerkt, nur im 32-Bit-Mode funzt. 4G-Mode
(bzw. FlatMode, UnrealMode und wie er noch genannt
wird...) wollt ich ebenfalls nicht benutzen - weil er zB
nicht mit EMM386 zusammenarbeitet. Mir gehts wirklich um
den konventionellen "Banked" Mode. Ich weiss ja, dass ich
nerve. (Und btw: Es gibt Grafikkarten, die keinen LFB
koennen - ja ich weiss: Wegschmeissen, neue einbauen.
Macht sich manchmal schlecht zB bei Laptops...)
Hatte halt gehofft, irgendwer hat mal dieses Problem auf
ATI gehabt und weiss, woran es liegt - oder ob der VESA
Standard dafuer irgendetwas spezielles vorsieht.

[toxl]

Ich bin mir jetzt nicht sicher, VESA ist lang her. Gibt es nicht eine Funktion jeweils für die Lese- und Schreib-Bank?

Ein Workaround wäre ein Puffer im RAM, aber das braucht natürlich mehr Speicher. Bist du aber sicher auch schon drauf gekommen... Normalerweise liest wohl niemand aus dem VGA-RAM, weil es so langsam ist.

[Xpyder]

> Ich bin mir jetzt nicht sicher, VESA ist lang her.
> Gibt es nicht eine Funktion jeweils für die Lese- und
> Schreib-Bank?

Das war in VGA so, daß man das getrennt ändern konnte.
(Die VGA-Methode funktioniert ja auch. Sie hat lediglich
den Nachteil, daß sie natürlich nur für die ersten
256kB der Graka funzt --- abgesehen davon, daß, selbst
WENN ich das nutzen würde [und damit nur den 640x400-Mode
haben könnte] keinesfalls gesagt ist, daß die Graka
die 256kB VGA-RAM auf die ersten 256kB des Graka-Speichers
"mappt"... - obwohl es meine ET4000 zB tut.)
In VESA hat es ja *auf anderen Grafikkarten* funktioniert.
Und auf *meiner* Graka funzt es ja.
Nur halt einige ATI-Karten (weiß nicht, ob es *alle*
ATIs betrifft) hat er halt das "Lese-Segment" auf den ersten
64k gelassen. Ich habe bisher auch nirgends explizit in
einer VESA-Dokumentation (und ich habe die Doku zu
VESA 3.0 als "Originaldokument" der VESA) gelesen, daß
das Umschalten nur für Schreibzugriffe gilt.

> Ein Workaround wäre ein Puffer im RAM, aber das braucht
> natürlich mehr Speicher. Bist du aber sicher auch schon
> drauf gekommen...

Ja, bin ich. Aber bei 1024x768x8bit bräuchte ich 768kB -
die mir im 16Bit-DOS nicht so ohne weiteres zur Verfügung
stehen...

> Normalerweise liest wohl niemand aus dem VGA-RAM, weil
> es so langsam ist.

So ist es. (Das wird wohl auch der Grund sein, wieso es
keinem weiter aufgefallen ist bei ATI - weil es eben kaum
einer macht. Ich nehme an, die supporten VESA nur "der
Form halber"...)
Vermeide selbstredend auch Lesezugriffe auf Graka-Speicher,
wenn ich kann.

Aber wenn ich halt ein "Fenster öffne", muß ich das, was
"drunter" lag, irgendwohin retten. Und wenn ich z.B. einen
Mauszeiger bewegen will, soll der dabei ja auch nicht die
Grafik zerstören. Diese geringen Datenmengen könnte der noch
lesen (Mauszeiger ist nicht groß, Fenster wird ja nicht
ständig geöffnet), ohne die ganze Performance zu killen.
(Wär ja halt kaum gerechtfertigt, extra alles in XMS zu
puffern, inklusive der ganzen Programmierung der Zugriffe
etc, nur damit ich den Grafik-Hintergrund für so'n mickrigen
Mauspfeil retten kann...)

Ich sag mal so: Eine *Abfrage* fuer dieses Problem habe
ich schon gecodet. Ich kann also sagen: "Ihre Grafikkarte
supportet leider nicht die benötigten Funktionen korrekt."
Aber dies ist natürlich unbefriedigend. Es ist wie
schonmal gesagt KEIN GENERELLES VESA PROBLEM!
Normalerweise funzt das in VESA. Nur diese ATI-Karten
(schon das dritte ATI-Modell, die das nicht konnte) können
das nicht! Andere Grakas machen das ganz normal.

Ich habe nur mal gelesen (Ralph Brown's Interrupt List),
daß VESA auch direkte Pointer auf einige Subroutinen (also
keine INT 10h-Aufrufe) zur Verfügung stellt und vielleicht
müßte man ja bei manchen Grakas z.B. vor dem Zugriff diese
"EnableDirectAccess"-Routine aufrufen oder dergleichen...
(Wollt das nicht erwähnen, weil das die Überlegungen der
Leute auch in die total falsche Richtung führen könnte,
weil es nämlich auch sein kann, daß die was ganz anderes
macht.)

Hatte halt gedacht, jemand hätte beim Coding von VESA auf
ATI mal dergleichen Erfahrungen gemacht und könnte mir
sagen, ob es
a) einen Trick gibt, um das Problem zu workarounden oder
b) definitiv nicht möglich ist und ich daher aufhören kann,
nach einer Lösung zu suchen, weil es keine gibt.

Achja, und zum Abschluß noch eine Sache, über die ich mir
*immer noch nicht* im Klaren bin: Bin ich mit dieser
Frage/Problem überhaupt im richtigen Topic?

[Messiah_of_Death]

also ich weis auch net so recht, wenn ich meinen alten Quellcode angucke, ging das lesen oder schreiben nur in 64K - Blöcken im VESA Modus

.. naja is alles schon sehr lange her, ich hab 2 Source noch gefunden .. vielleicht hilft es dir ja

die sollten (wenn ich die richtigen gefunden habe) einen Farbverlauf in VESA 1024x768x256 darstellen

(oh, ja Backups machen wäre bei mir hin und wieder angebracht :rolleyes: )

[toxl]

Ich bin hier zwar kein Mod, aber ich würde mal sagen es ist on topic. Wenn nicht verschieben sie dich schon. :)

Und ich kann dir wieder nix direkt beantworten, weil ich das Problem noch nicht hatte. Trotzdem noch ein anderer Vorschlag: Du könntest die Bildstücke nicht zwischenspeichern, sondern jedesmal wenn sich der Mauscursor oder ein Fenster bewegt, neu zeichnen. Halte ich für besser, erfahrungsgemäß. Auch z. B. falls sich mal ein Fenster "unter" dem Cursor bewegen soll, oder ein Fenster unter einem zweiten, das geht mit der Zwischenspeichermethode nicht so einfach.

Kann natürlich sein dass das in deinem Fall nicht so geht. Aber weiß ich nicht.

[Xpyder]

Ich beantworte gleich mal beide Messages -
die von Messiah_of_Death und die von toxl

Also...

>Erstellt von: Messiah_of_Death
>Datum: Gestern 11:34
>also ich weis auch net so recht, wenn ich meinen alten Quellcode angucke,
>ging das lesen oder schreiben nur in 64K - Blöcken im VESA Modus
>... naja is alles schon sehr lange her, ich hab 2 Source noch gefunden ...
>vielleicht hilft es dir ja
>die sollten (wenn ich die richtigen gefunden habe) einen Farbverlauf in
>VESA 1024x768x256 darstellen (oh, ja Backups machen wäre bei mir hin und
>wieder angebracht :rolleyes: )

Hm. Naja.
a) NUR mit 64k Blöcken ist nicht *ganz* richtig, weil VESA auch noch den
sogenannten "Linearen Framebuffer" anbietet - der ist aber nur bei 32bit-Adressierung sinnvoll einsetzbar -
aber das gehört wohl jetzt nicht hierher...
b) GENAU DAS - nämlich diese Ansteuerung in 64k Blöcken WILL ICH MACHEN.
c) Ich KANN diese Ansteuerung von 64k Blöcken in VESA! Es liegt nicht daran, daß ich nicht weiß,
wie VESA funktioniert oder so. Einziges Problem ist, daß einige (oder alle??) Grafikkarten
*speziell von ATI* das Segment beim Ändern nur für SCHREIBZUGRIFFE ändern, für Lesezugriffe aber
auf dem ersten Segment stehenbleiben! Und wie gesagt: Die anderen Grafikkarten ändern das Segment
für Schreiben UND Lesen. Es tritt halt NUR bei (einigen?) ATI-Karten auf...
d) hab mir jetzt noch nicht die Sourcen angeguckt. Wie gesagt: Ich kann auch n Farbverlauf erstellen - sogar
auf ATI-Karten! Auf ATI-Karten könnte ich ihn halt nur NICHT wieder AUSLESEN - sondern (bei 1024x768x8bit)
halt nur die ersten 64 Zeilen... (1024 x 64 = 65536 (64kB))
e) Ich hab mir grad auch mal die Sourcen angeguckt. Du machst da EXAKT dasselbe wie ich. Nämlich INT 10h
aufrufen, mit Funktion $4F05 und der Bank-Nr in BX. (und zwar, wie ich schon sagte, für schreiben UND lesen
halt gleich).
Jetzt nur mal eins probieren: Compilieren, und die EXE dann auf ner neueren ATI-Karte laufen lassen!
Die GELESENEN Pixel werden halt allesamt aus den ersten 64kB genommen, weil er die LESE-Bank scheints
nicht mit umschaltet. Jedesfalls bei manchen ATI-Karten.
Auf MEINER Grafikkarte funzt das halt.


>Erstellt von: toxl
>Datum: Gestern 15:37
>
>Ich bin hier zwar kein Mod, aber ich würde mal sagen es ist on topic.
>Wenn nicht verschieben sie dich schon. :)
>Und ich kann dir wieder nix direkt beantworten, weil ich das Problem
>noch nicht hatte. Trotzdem noch ein anderer Vorschlag: Du könntest die
>Bildstücke nicht zwischenspeichern, sondern jedesmal wenn sich der
>Mauscursor oder ein Fenster bewegt, neu zeichnen. Halte ich für besser,
>erfahrungsgemäß. Auch z. B. falls sich mal ein Fenster "unter" dem
>Cursor bewegen soll, oder ein Fenster unter einem zweiten, das geht mit
>der Zwischenspeichermethode nicht so einfach.
>Kann natürlich sein dass das in deinem Fall nicht so geht. Aber weiß ich
>nicht.

Hm. Darum gehts erstmal garnicht. In dem Fall zeichne ich eh neu. Aber:
Wenn ich immer das, was unter Mauszeiger ist, neu zeichnen würde, müßte
ich für jedes gezeichnete Objekt (jeden Rahmen, jeden Button, jede Linie,
jeden Text) halt alle Parameter (Farbe, Position, Skalierung/Größe. Bei
Texten halt den Text, bei Bildern oder Pictogrammen halt die Nummer der
Bitmap) irgendwo zwischenspeichern - was mich unter Umständen soviel
Speicher kosten kann, daß ich auch gleich einen Puffer anlegen könnte.
Also, diese Idee hatte ich auch schon. (Abgesehen davon ziehts natürlich
etwas "Performance", ständig "Objekte" unter dem Mauszeiger neu zu zeichnen
bei Bewegung... (Also könnte "flüssige Mausbewegung" auf nem 486er in Frage
stellen.)
Desweiteren: Mein Malprogramm soll ja auch sowas ähnliches bekommen. Und
weil ich da eben auch sowas wie 1024er Modus supporte und man aber halt auch
mal einen Zeichencursor oder ein Menü hat... Hab halt nix, wohin ich 768kB
"mal eben" retten könnte - behalte das immer gleich in der Graka.

Außerdem (ich weiß, das ist natürlich DER BLANKE IRRSINN) benutze ich
unbenutzten VESA-Speicher auch mal optional gern mal als Zwischenspeicher...

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
DIE FOLGENDE BEMERKUNG EINFACH IGNORIEREN, WENN MAN SICH
NICHT ANGESPROCHEN FÜHLT:

Achja. Noch ne Randbemerkung: Ich weiß, das ist für viele fürchterlich lame
Sch***, die ich da mache. DOS, 486er, VESA und so weiter. Wen's nicht
interessiert, einfach dieses Topic ignorieren - es gibt so viele andere
Topics hier... - Wer auch immer sowas absolut nicht zeitgemäß,
Zeitverschwendung oder sonst irgendwie bescheuert findet, oder mir DirectX
etc empfehlen will - bitte Kommentare sparen, habe das alles schon gehört...
(Btw: Kenne auch n Haufen Leute, die meinen Mist zu schätzen wissen, was
es dann im Gegenzug ja quasi wieder rechtfertigen würde - wenn man auf
Rechtfertigung via Anerkennung durch andere angewiesen wäre.)
Und noch was: Wer sich durch diese Randbemerkung *nicht betroffen* fühlt,
kann das am besten zeigen, indem er diese Randbemerkung *nicht kommentiert*.

[Messiah_of_Death]

ok,

bei meinen nVidia Karten lief das eigentlich

bei meinem Laptop mit nem ATI Chip krepiert mir das System beim Ausführen

langsam kapier ich was du meinst

... ich erinner mich an ATI und seine Shaderdefinitionen ... da gab's auch mal heiße Diskussionen

...damit klink ich mich weg, mit VESA coden hab ich eigentlich abgeschlossen udn hab grad paar Klausuren vor mir, wollte hier nur kurz was beitragen :)

[Xpyder]

@ Messiah_of_Death :

>bei meinen nVidia Karten lief das eigentlich
>bei meinem Laptop mit nem ATI Chip krepiert mir das System
>beim Ausführen
>langsam kapier ich was du meinst

Hm. "Krepieren" war eigentlich nicht so ganz die Reaktion,
die ich vom System erwartet hätte. Eher die, daß er bei
den Teilen, wo er liest und wieder schreibt, dann das
oberste Fünftel des Screens unten immer wiederholt...

>... ich erinner mich an ATI und seine Shaderdefinitionen
>... da gab's auch mal heiße Diskussionen

Hä? Davon hab ich nie was gehört. Wäre natürlich schön,
wenn mir einer was dazu sagen könnte, beispielsweise ob es
vielleicht irgeneinen Trick gibt, mit der man die ATI dann
*doch noch* zum Funzen kriegen könnte - einen der mit
diesen "Shaderdefinitionen" zu tun hat möglicherweise...

[Pukys]

a) NUR mit 64k Blöcken ist nicht *ganz* richtig, weil VESA auch noch den
sogenannten "Linearen Framebuffer" anbietet - der ist aber nur bei 32bit-Adressierung sinnvoll einsetzbar -
aber das gehört wohl jetzt nicht hierher...

Nein, die Adressierung erfolgt in "granular units", die kann man abfragen. Sie ist _meist_ 64kb, aber nicht immer. Ich hatte damals z.B. eine Paradise VGA, die hatte eine granular unit von 4kb.


b) GENAU DAS - nämlich diese Ansteuerung in 64k Blöcken WILL ICH MACHEN.
c) Ich KANN diese Ansteuerung von 64k Blöcken in VESA! Es liegt nicht daran, daß ich nicht weiß,
wie VESA funktioniert oder so. Einziges Problem ist, daß einige (oder alle??) Grafikkarten
*speziell von ATI* das Segment beim Ändern nur für SCHREIBZUGRIFFE ändern, für Lesezugriffe aber
auf dem ersten Segment stehenbleiben! Und wie gesagt: Die anderen Grafikkarten ändern das Segment
für Schreiben UND Lesen. Es tritt halt NUR bei (einigen?) ATI-Karten auf...


Die ultimative Informationsquelle für solche Dinge ist immer noch die Ralph Brown Interrupt List. Ohne sie wäre ich damals aufgeschmissen gewesen.
Du findest sie u.a. hier: http://www.ctyme.com/rbrown.htm

Die sagt zu dem Thema:

Note: When using an accelerated video mode under VBE/AF v1.0P, the application must call EnableDirectAccess before switching banks if bit 9 of the video mode attributes flag is set (see #00080) (http://www.ctyme.com/intr/rb-0274.htm#Table80)

Ich vermute, daß genau das bei dir passiert.

Hast du schon mal UNIVESA.EXE bzw. UNIVBE.EXE probiert?

[Xpyder]

Nein, die Adressierung erfolgt in "granular units", die kann man abfragen. Sie ist _meist_ 64kb, aber nicht immer. Ich hatte damals z.B. eine Paradise VGA, die hatte eine granular unit von 4kb.
Ja, ich weiß das natürlich. (Daran liegts auch nicht.)

Die ultimative Informationsquelle für solche Dinge ist immer noch die Ralph Brown Interrupt List.
Ja, die hab ich schon lange, steht aber nur das drin, was ich auch mache.

Die sagt zu dem Thema:
Note: When using an accelerated video mode under VBE/AF v1.0P, the application must call EnableDirectAccess before switching banks if bit 9 of the video mode attributes flag is set.
Ich vermute, daß genau das bei dir passiert.
Ja ich weiß. Leider liefert "EnableDirectAccess" (also die
Adresse, die eigentlich auf die Routine - wenn vorhanden - zeigen soll, 0000h:0000h - also "nicht vorhanden".
Will sagen: Zumindest im Realmode hat er diese Routine nicht.

Und nochmal: Das "lustige" ist, daß das Bank-switching ja klappt! Und es sind auch wirklich 64kB
Banks. Problem ist nicht, daß er nicht Bank-switchen kann! Problem ist, daß er das nur für den Schreib-Modus
tut. - Gelesen wird jedoch weiterhin aus den ersten 64kB
(also Bank 0 = 00000h-0FFFFh) auch wenn die "Schreib-Bank" zB. auf 5 (also bei 50000h-5FFFFh im Vesa-Speicher)
steht.
Und: Andere Grafikkarten switchen immer für Lesen und Schreiben.
Mir kommt's so vor, als hätte ATI da Mist gebaut - und weil heutzutage kaum noch VESA benutzt, geschweige
denn diesen Realmode-Krempel codet... - ist das wohl keinem weiter aufgefallen.
(Und selbst, wer sowas macht, vermeidet meist, Graka-Speicher zu lesen.)

In "derselben" Graka-Version für Laptops (also Radeon 9600 - nur halt für Lap) funktioniert es nämlich - hat einer
neulich für mich rausgefunden (sprich: mein Testprogramm laufen lassen).

Hast du schon mal UNIVESA.EXE bzw. UNIVBE.EXE probiert?
Ja, habe ich, hilft aber nichts.