VESA Graphikroutinen in Assembler
-
- MemMaker-Benutzer
- Beiträge: 78
- Registriert: Do 5. Mär 2015, 17:17
- Wohnort: Magdeburg
Re: VESA Graphikroutinen in Assembler
Wenn ich darf, beteilige ich mich mal am Offtopic-Geschreibe, da es aufgrund der vorigen Post doch ganz gut passt.
@Schlowski und @DOSferatu, ihr seit nicht nur zu zweit, bei mir ist es auch in etwa so gelaufen.
Erstaunlich, wie ähnlich wir uns sind.
Ich habe meine ersten Berührungen mit der Computerwelt auf einem KC85/3 in der Berufsschule gehabt, hatte aber nie die Kohle, mir einen eigenen Computer zu zulegen. Das änderte sich erst mit der Wende, wo ich meine 100 DM Begrüsungsgeld in einen C64 mit Datasette investierte. Diese Investition habe ich nie bereut. Naja, das nächste war ein Amiga 500 der mir als Einstieg in die Amiga-Welt diente. Als ein Freund von mir sich damals einen 286er zulegte, war sein alter 8068 über, den ich dann geerbt hatte. Der war zwar zu diesem Zeitpunkt auch schon veraltet, aber einem geschenkten Gaul schaut mann nicht ins Maul. ^^
Dann habe ich jede x86-Generation mitgemacht, 286, 386 und so weiter. Ich hatte damals aber noch keine Hardware gesamelt. Die alten Rechner wurden immer entsorgt. Ihr könnt euch sicherlich vorstellen, wie sehr ich mich heute darüber ärgere. Da waren so schöne Sachen wie ein Amiga 2000 mit Festplatte, oder ein VC20 dabei, oder ein Aktion-Replay für den PC. Ist zwar eine reichlich sinnlose Karte, aber sie war ebend etwas besonderes. Aber ich schweife ab.
Als ich mit dem C64 anfing, interessierte mich damals natürlich nur das zocken (Katakis, Krieg um die Krone 2, u.s.w.) aber das wurde ihrgendwann langweilig. Da stand ich vor der Entscheidung, das Hobby aufzugeben, oder mehr mit dem Rechner zu machen, als nur zu zocken. Ich entschied mich für Programmierung, und musste nach kurzer Zeit feststellen, das es mir leichter viel, als ich vorher dachte. Naja, und bei der Programmierung bin ich dann auf jeder Rechner-Generation geblieben. Dabei geht es mir so ähnlich wie DOSferatu, Grafik-Routinen machten mir immer am meisten Spaß,
aber was Sound anbelangt fehlt mir dazu ihrgendwie das Händchen. Ich bin auch, unabhängig vom Computer, musikalisch absolut untalentiert. Ich schaffe es nichtmal, beim tanzen im Takt zu bleiben. ^^
Glücklicherweise habe ich, obwohl meine Rechner damals immer verschrottet wurden, alle Quelltexte gesichert, und über die Jahre gerettet. Als Entwicklungsumgebung hatte ich meistens mit Borland Pascal gearbeitet, und mit einer eigenen IDE (geschrieben mit Hilfe von Turbo-Vision) auch mit Turbo Assembler V5.0 geproggt. Assembler macht schon richtig Spaß. Auf neuerer Hardware bin ich dann, zumindest was meine Privaten Projekte anbelangt, bei "BlitzMax" gelandet. Assembler unter Windows war mir dann doch etwas zu aufwendig. Ich verdiene mir heute meine Brötchen als Software-Entwickler, aber als Angestellter, nicht Selbstständiger. Und da habe ich seit einiger Zeit kaum noch Zeit und Lust, nach der Arbeit privat zu proggen. Auch da geht es mir so wie DOSferatu.
Zur Zeit versuche ich mich in die Elektronik etwas einzuarbeiten. Kleinere Lötarbeiten, wie zum Beispiel der PS2 zu Seriell-Adapter von Matze79, machen mir richtig Spaß. Naja, und meine vor ca. 4 Jahren ausgebrochene Leidenschaft, Computer und Konsolen zu sammeln, braucht ja auch etwas Zeit.^^
@Schlowski und @DOSferatu, ihr seit nicht nur zu zweit, bei mir ist es auch in etwa so gelaufen.
Erstaunlich, wie ähnlich wir uns sind.
Ich habe meine ersten Berührungen mit der Computerwelt auf einem KC85/3 in der Berufsschule gehabt, hatte aber nie die Kohle, mir einen eigenen Computer zu zulegen. Das änderte sich erst mit der Wende, wo ich meine 100 DM Begrüsungsgeld in einen C64 mit Datasette investierte. Diese Investition habe ich nie bereut. Naja, das nächste war ein Amiga 500 der mir als Einstieg in die Amiga-Welt diente. Als ein Freund von mir sich damals einen 286er zulegte, war sein alter 8068 über, den ich dann geerbt hatte. Der war zwar zu diesem Zeitpunkt auch schon veraltet, aber einem geschenkten Gaul schaut mann nicht ins Maul. ^^
Dann habe ich jede x86-Generation mitgemacht, 286, 386 und so weiter. Ich hatte damals aber noch keine Hardware gesamelt. Die alten Rechner wurden immer entsorgt. Ihr könnt euch sicherlich vorstellen, wie sehr ich mich heute darüber ärgere. Da waren so schöne Sachen wie ein Amiga 2000 mit Festplatte, oder ein VC20 dabei, oder ein Aktion-Replay für den PC. Ist zwar eine reichlich sinnlose Karte, aber sie war ebend etwas besonderes. Aber ich schweife ab.
Als ich mit dem C64 anfing, interessierte mich damals natürlich nur das zocken (Katakis, Krieg um die Krone 2, u.s.w.) aber das wurde ihrgendwann langweilig. Da stand ich vor der Entscheidung, das Hobby aufzugeben, oder mehr mit dem Rechner zu machen, als nur zu zocken. Ich entschied mich für Programmierung, und musste nach kurzer Zeit feststellen, das es mir leichter viel, als ich vorher dachte. Naja, und bei der Programmierung bin ich dann auf jeder Rechner-Generation geblieben. Dabei geht es mir so ähnlich wie DOSferatu, Grafik-Routinen machten mir immer am meisten Spaß,
aber was Sound anbelangt fehlt mir dazu ihrgendwie das Händchen. Ich bin auch, unabhängig vom Computer, musikalisch absolut untalentiert. Ich schaffe es nichtmal, beim tanzen im Takt zu bleiben. ^^
Glücklicherweise habe ich, obwohl meine Rechner damals immer verschrottet wurden, alle Quelltexte gesichert, und über die Jahre gerettet. Als Entwicklungsumgebung hatte ich meistens mit Borland Pascal gearbeitet, und mit einer eigenen IDE (geschrieben mit Hilfe von Turbo-Vision) auch mit Turbo Assembler V5.0 geproggt. Assembler macht schon richtig Spaß. Auf neuerer Hardware bin ich dann, zumindest was meine Privaten Projekte anbelangt, bei "BlitzMax" gelandet. Assembler unter Windows war mir dann doch etwas zu aufwendig. Ich verdiene mir heute meine Brötchen als Software-Entwickler, aber als Angestellter, nicht Selbstständiger. Und da habe ich seit einiger Zeit kaum noch Zeit und Lust, nach der Arbeit privat zu proggen. Auch da geht es mir so wie DOSferatu.
Zur Zeit versuche ich mich in die Elektronik etwas einzuarbeiten. Kleinere Lötarbeiten, wie zum Beispiel der PS2 zu Seriell-Adapter von Matze79, machen mir richtig Spaß. Naja, und meine vor ca. 4 Jahren ausgebrochene Leidenschaft, Computer und Konsolen zu sammeln, braucht ja auch etwas Zeit.^^
Re: VESA Graphikroutinen in Assembler
Na da sammeln sich ja gerade ein paar Gleichgesinnte. Schon interessant, dass wir alle auf Pascal und Assembler stehen.
@Felmar Loyd: BlitzMax hab ich auch, genau wie BlitzPlus, PureBasic, DarkBasic... Mein allerliebstes Basic war immer das GFA-Basic auf dem Atari ST, einfach ungeschlagen.
@Felmar Loyd: BlitzMax hab ich auch, genau wie BlitzPlus, PureBasic, DarkBasic... Mein allerliebstes Basic war immer das GFA-Basic auf dem Atari ST, einfach ungeschlagen.
Re: VESA Graphikroutinen in Assembler
Locomotive Basic war mein Favorit am CPC, da hab ich einige Sachen programmiert.. jetzt mach ich mehr mit MCUs rum.
Ich versuche hartnäckig mir AVR Asembler beizubringen, leider fehlt mir Schwer die Zeit und so greife ich auch hier immer wieder zu Basic (BASCOM), Wobei C auf dem AVR auch sehr gut ist, ist oft genauso schnell wie ASM Code.
Der AVRGCC ist hier wirklich sehr ausgereift :)
Ich versuche hartnäckig mir AVR Asembler beizubringen, leider fehlt mir Schwer die Zeit und so greife ich auch hier immer wieder zu Basic (BASCOM), Wobei C auf dem AVR auch sehr gut ist, ist oft genauso schnell wie ASM Code.
Der AVRGCC ist hier wirklich sehr ausgereift :)
https://www.shadowcircuit.de - Die kleine Community rund um Retro Computing
https://www.retroianer.de
https://www.retroianer.de
Re: VESA Graphikroutinen in Assembler
Oh man, schon wieder ein paar Wochen vergangen, seit ich was an meinen Routinen gemacht habe - momentan fehlt mir einfach die Zeit und Ruhe für langwierige Assembler-Abende
Aber damit das jetzt nicht ganz sang- und klanglos hier versackert, dachte ich mir, ich stelle meine bisherigen Ergebnisse mal zur Verfügung, falls jemand reinschauen möchte, es wurde ja Interesse an meinem Programmstil bekundet
.
Unter http://www.stojalowski.de/files/VESA_src.zip findet sich das Paket mit den Sourcen (*.asm), etwas Dokumentation (*.txt) und einer Main.exe plus zugehöriger Resourcen (*.fnt, *.pal), die einfach ein paar Testroutinen aufruft und anschließend die gemessene Zeit ausgibt.
In der beiliegenden Settings.Ini kann man ein paar Einstellungen vornehmen:
X und Y geben die gewünschte Auflösung an, wenn die nicht gesetzt werden kann (kein VESA 3.0 gefunden oder Auflösung nicht unterstützt) gibt es ein Auto-Fallback auf 320x200x256.
Und der letzte Wert gibt an, ob direkt im Bildschirm gezeichnet wird (dbuffer=0) oder in einem Hintergrundbuffer gemalt und anschließend umgeschaltet wird (dbuffer=1)
Assembliert habe ich das Ganze übrigens mit dem FlatAssembler, der frei verfügbar ist.
Edit: Ich hab nochmal ein bisschen aufgeräumt und eine kleine Menüführung durch die Tests eingebaut, damit man die einzeln oder in Gruppen laufen lassen kann. Außerdem hab ich den RDTSC-Kram rausgeschmissen und einen vernünftigen Millisekunden-Timer eingebaut
Das ZIP ist aktualisiert.
![Frowning :frown:](./images/smilies/icon_frown.gif)
Aber damit das jetzt nicht ganz sang- und klanglos hier versackert, dachte ich mir, ich stelle meine bisherigen Ergebnisse mal zur Verfügung, falls jemand reinschauen möchte, es wurde ja Interesse an meinem Programmstil bekundet
![Smile :-)](./images/smilies/icon_e_smile.gif)
Unter http://www.stojalowski.de/files/VESA_src.zip findet sich das Paket mit den Sourcen (*.asm), etwas Dokumentation (*.txt) und einer Main.exe plus zugehöriger Resourcen (*.fnt, *.pal), die einfach ein paar Testroutinen aufruft und anschließend die gemessene Zeit ausgibt.
In der beiliegenden Settings.Ini kann man ein paar Einstellungen vornehmen:
Code: Alles auswählen
x=640
y=400
dbuffer=1
Und der letzte Wert gibt an, ob direkt im Bildschirm gezeichnet wird (dbuffer=0) oder in einem Hintergrundbuffer gemalt und anschließend umgeschaltet wird (dbuffer=1)
Assembliert habe ich das Ganze übrigens mit dem FlatAssembler, der frei verfügbar ist.
Edit: Ich hab nochmal ein bisschen aufgeräumt und eine kleine Menüführung durch die Tests eingebaut, damit man die einzeln oder in Gruppen laufen lassen kann. Außerdem hab ich den RDTSC-Kram rausgeschmissen und einen vernünftigen Millisekunden-Timer eingebaut
![Smile :-)](./images/smilies/icon_e_smile.gif)
- Dateianhänge
-
- Screenshots aus DOSBox
- Screens.png (20.3 KiB) 11799 mal betrachtet
Re: VESA Graphikroutinen in Assembler
Bei meinen Tests ist mir dann noch Folgendes aufgefallen:
GetImage ist auf realer Hardware um den Faktor 4 (Olivetti P90) bzw. 40 (2.1GHz Rechner) langsamer als PutImage, wohingegen es sich sowohl in der DOSBox als auch im PCEm lediglich um den Faktor 1,5 handelt.
DOSBox ist klar, das ist eh keine zyklengenaue Emulation, aber auch PCEm scheint da zu patzen. Ich hab das mit verschiedenen Graphikkarten und verschiedenen Bus-Einstellungen für die GraKa probiert (16Bit ISA, langsamer bis schneller VLB), aber immer bleibt das Verhältnis ungefähr bei 1:1,5. Das erscheint mir insgesamt einfach zu schnell für Schreibzugriffe auf das Graphik-RAM. Wieder einmal zeigt sich, dass man keiner Emulation trauen kann...
Am überraschendsten fand ich allerdings, dass mein High-End-Rechner mit 2.1 GHz Core2Duo und PCI-Express Graphikkarte beim Lesen aus dem Graphik-RAM dermaßen langsam ist, dass ihn selbst der P90 abhängt. Man sieht auch am Zeitunterschied zwischen PutImage (32x32 Pixel Image, komplett gefüllt) und PutImageTrans (32x32 Pixel Image, nur äußerer Rand gesetzt, innen transparent), wie sehr der Core2Duo durch die Zugriffe auf das GraKa-RAM ausgebremst wird.
Als nächstes wäre mal interessant, die ganzen Operationen statt im Graphikkarten-RAM im normalen Speicher auszuführen, das sollte dem Core2Duo deutlich besser liegen. Und anschließend dann das fertige Bild in die Graphikkarte kopieren.
Da sieht man mal wieder, dass man unter DOS eigentlich für jeden PC bzw. jede Hardware-Kombination eigene, handoptimierte Routinen braucht, um das Beste aus der Kiste rauszuholen. Aber interessant finde ich das immer wieder![Smile :-)](./images/smilies/icon_e_smile.gif)
GetImage ist auf realer Hardware um den Faktor 4 (Olivetti P90) bzw. 40 (2.1GHz Rechner) langsamer als PutImage, wohingegen es sich sowohl in der DOSBox als auch im PCEm lediglich um den Faktor 1,5 handelt.
DOSBox ist klar, das ist eh keine zyklengenaue Emulation, aber auch PCEm scheint da zu patzen. Ich hab das mit verschiedenen Graphikkarten und verschiedenen Bus-Einstellungen für die GraKa probiert (16Bit ISA, langsamer bis schneller VLB), aber immer bleibt das Verhältnis ungefähr bei 1:1,5. Das erscheint mir insgesamt einfach zu schnell für Schreibzugriffe auf das Graphik-RAM. Wieder einmal zeigt sich, dass man keiner Emulation trauen kann...
Am überraschendsten fand ich allerdings, dass mein High-End-Rechner mit 2.1 GHz Core2Duo und PCI-Express Graphikkarte beim Lesen aus dem Graphik-RAM dermaßen langsam ist, dass ihn selbst der P90 abhängt. Man sieht auch am Zeitunterschied zwischen PutImage (32x32 Pixel Image, komplett gefüllt) und PutImageTrans (32x32 Pixel Image, nur äußerer Rand gesetzt, innen transparent), wie sehr der Core2Duo durch die Zugriffe auf das GraKa-RAM ausgebremst wird.
Als nächstes wäre mal interessant, die ganzen Operationen statt im Graphikkarten-RAM im normalen Speicher auszuführen, das sollte dem Core2Duo deutlich besser liegen. Und anschließend dann das fertige Bild in die Graphikkarte kopieren.
Da sieht man mal wieder, dass man unter DOS eigentlich für jeden PC bzw. jede Hardware-Kombination eigene, handoptimierte Routinen braucht, um das Beste aus der Kiste rauszuholen. Aber interessant finde ich das immer wieder
![Smile :-)](./images/smilies/icon_e_smile.gif)
- Dateianhänge
-
- Zeitvergleich
- Vergleich_GetImage.png (9.7 KiB) 11799 mal betrachtet
Re: VESA Graphikroutinen in Assembler
Mein Laptop mit Intel Celeron 433 und Trident Cyber9525 (http://www.dosforum.de/viewtopic.php?f=29&t=9581):
Mode 320x200 ($13)
1000x GetImage_____ 1324 ms
1000x PutImage______ 234 ms
1000x PutTransparent__ 94 ms
[VESA wurde nicht gefunden; finde ich auf dem PC aber auch nicht, obwohl mir mal ein Tool gesagt hat, es wäre vesa vorhanden]
Aber der CoreDuo ist echt schwach, Dachte eigentlich, dass moderne Hardware (auch GraKa) deutlich flotter sein müssten.
Mode 320x200 ($13)
1000x GetImage_____ 1324 ms
1000x PutImage______ 234 ms
1000x PutTransparent__ 94 ms
[VESA wurde nicht gefunden; finde ich auf dem PC aber auch nicht, obwohl mir mal ein Tool gesagt hat, es wäre vesa vorhanden]
Aber der CoreDuo ist echt schwach, Dachte eigentlich, dass moderne Hardware (auch GraKa) deutlich flotter sein müssten.
Re: VESA Graphikroutinen in Assembler
Naja, mein Progrämmilein benötigt VESA 2.0 wegen des LFB, die Meldung ist etwas ungenau...
Danke für den Test, das ist ja mal interessant, die Werte eines anderen Rechners zu sehen. Da ist der Zugriff auf das GraKa-RAM offensichtlich auch der begrenzende Faktor, wie man schön an den beiden PutImage-Werten sehen kann, außer in einem fehlenden Schreibzugriff bei transparenten Pixeln unterscheiden sich die beiden Routinen nicht.
Und ja, mein Core2Duo hat mich auch bitter enttäuscht
Das PutImage ist ja noch ok, aber das GetImage ist quasi indiskutabel. Haben moderne Rechner irgendeine Art Write-Cache für Graphikkarten? Anders kann ich mir den Unterscheid zwischen GetImage und PutImage nicht erklären.
Edit: Ich hab nochmal auf zwei weiteren, aktuellen Rechnern getestet
1. Core i7-2700K 3.5GHz mit ATI irgendwas damals ganz teurem
Auflösung 320x200x8
GetImage ............ 718 ms
PutImage ............ 23 ms
PutImageTrans ..... 5 ms
2. Core i5-3340 3.1GHz mit integrierter Graphik
Auflösung 320x200x8
GetImage ............ 208 ms
PutImage ............ 87 ms
PutImageTrans ..... 11 ms
Auflösung 640x480x8
GetImage ............ 85 ms
PutImage ............ 52 ms
PutImageTrans ..... 7 ms
Das mit der größeren Auflösung muss ich bei dem ersten Rechner nochmal nachholen, ich finde es jedenfalls interessant, dass die Zeiten bei der OnChip-Graphik von der Auflösung bzw. der Lage des Graphikspeichers abhängig sind (320x200x8 = $A000:000, 640x480x8 LFB irgendwo im hinteren/höheren Speicherbereich). Aber insgesamt kommt die integrierte Graphik viel besser mit dem direkten Speicherauslesen klar, auch wenn sie bei den restlichen Tests beim Schreiben in den Graphikspeicher dann doch deutlich abfällt gegen die dedizierten Graphikkarten.
Danke für den Test, das ist ja mal interessant, die Werte eines anderen Rechners zu sehen. Da ist der Zugriff auf das GraKa-RAM offensichtlich auch der begrenzende Faktor, wie man schön an den beiden PutImage-Werten sehen kann, außer in einem fehlenden Schreibzugriff bei transparenten Pixeln unterscheiden sich die beiden Routinen nicht.
Und ja, mein Core2Duo hat mich auch bitter enttäuscht
![Shocked :shock:](./images/smilies/icon_eek.gif)
Edit: Ich hab nochmal auf zwei weiteren, aktuellen Rechnern getestet
1. Core i7-2700K 3.5GHz mit ATI irgendwas damals ganz teurem
![Wink ;-)](./images/smilies/icon_e_wink.gif)
Auflösung 320x200x8
GetImage ............ 718 ms
PutImage ............ 23 ms
PutImageTrans ..... 5 ms
2. Core i5-3340 3.1GHz mit integrierter Graphik
Auflösung 320x200x8
GetImage ............ 208 ms
PutImage ............ 87 ms
PutImageTrans ..... 11 ms
Auflösung 640x480x8
GetImage ............ 85 ms
PutImage ............ 52 ms
PutImageTrans ..... 7 ms
Das mit der größeren Auflösung muss ich bei dem ersten Rechner nochmal nachholen, ich finde es jedenfalls interessant, dass die Zeiten bei der OnChip-Graphik von der Auflösung bzw. der Lage des Graphikspeichers abhängig sind (320x200x8 = $A000:000, 640x480x8 LFB irgendwo im hinteren/höheren Speicherbereich). Aber insgesamt kommt die integrierte Graphik viel besser mit dem direkten Speicherauslesen klar, auch wenn sie bei den restlichen Tests beim Schreiben in den Graphikspeicher dann doch deutlich abfällt gegen die dedizierten Graphikkarten.
Re: VESA Graphikroutinen in Assembler
Nutzt du MTRR auf dem Core2Duo ?
Gggf. hat das damit zutun.
So genau kenne ich mich da aber auch nicht aus.
Edit:
Mit fastvid müsstest du die unter DOS einschalten können.
http://www.mdgx.com/umb.htm#MTF
Gggf. hat das damit zutun.
So genau kenne ich mich da aber auch nicht aus.
Edit:
Mit fastvid müsstest du die unter DOS einschalten können.
http://www.mdgx.com/umb.htm#MTF
https://www.shadowcircuit.de - Die kleine Community rund um Retro Computing
https://www.retroianer.de
https://www.retroianer.de
Re: VESA Graphikroutinen in Assembler
<ganz viel Mist gelöscht>
Das Tool funktioniert soweit und bringt ein wenig Verbesserung, allerdings nur beim Schreiben ins VideoRAM, beim Lesen bringt das nichts. Da hab ich mich zuerst selbst ausgetrickst mit einem DoubleBuffering im System-RAM (dort erhalte ich 5ms sowohl für PutImage als auch GetImage), aber wenn die Zugriffe aufs Graphik-RAM gehen, ist und bleibt das alles lahm![Sad :-(](./images/smilies/icon_e_sad.gif)
Das Tool funktioniert soweit und bringt ein wenig Verbesserung, allerdings nur beim Schreiben ins VideoRAM, beim Lesen bringt das nichts. Da hab ich mich zuerst selbst ausgetrickst mit einem DoubleBuffering im System-RAM (dort erhalte ich 5ms sowohl für PutImage als auch GetImage), aber wenn die Zugriffe aufs Graphik-RAM gehen, ist und bleibt das alles lahm
![Sad :-(](./images/smilies/icon_e_sad.gif)
Re: VESA Graphikroutinen in Assembler
Naja, auch auf den DOS-Rechnern (VGA/VESA Karte) ist schreiben in Grafikkarten-RAM schneller als lesen.
Ich hatte mich damals auch darüber gewundert. (Ich habe da mal Zeugs angedacht, um den 1 MB RAM der Grafikkarte als Zwischenspeicher zu nutzen...)
Ich nehme an, daß auf Schreiben optimiert wurde, weil das viel häufiger gebraucht wird. Man geht wohl davon aus, daß der Programmierer "weiß, was er angezeigt hat" und daher das Auslesen nicht nötig sei, bzw eher nur "im Notfall".
Ich hatte allerdings nicht erwartet, daß der Unterschied zwischen Schreiben und Lesen bei aktuellen Systemen derart groß ist.
(Meine halbtransparenten Mehr-Ebenen-Levels werden übrigens ohne Auslesen realisiert, ich mißbrauche hier ein 32bit-Register als Puffer... - aber meine halbtransparenten Sprites lesen - wenn halbtransparenter Pixel auftaucht - den darunterliegenden Pixel aus, um entsprechend zu mischen. Ja, mein Zeug puffert nicht irgendwoanders hin, sondern schreibt immer direkt in die Grafikkarte. Ich brauche den RAM für wichtigere Dinge...)
Ich hatte mich damals auch darüber gewundert. (Ich habe da mal Zeugs angedacht, um den 1 MB RAM der Grafikkarte als Zwischenspeicher zu nutzen...)
Ich nehme an, daß auf Schreiben optimiert wurde, weil das viel häufiger gebraucht wird. Man geht wohl davon aus, daß der Programmierer "weiß, was er angezeigt hat" und daher das Auslesen nicht nötig sei, bzw eher nur "im Notfall".
Ich hatte allerdings nicht erwartet, daß der Unterschied zwischen Schreiben und Lesen bei aktuellen Systemen derart groß ist.
(Meine halbtransparenten Mehr-Ebenen-Levels werden übrigens ohne Auslesen realisiert, ich mißbrauche hier ein 32bit-Register als Puffer... - aber meine halbtransparenten Sprites lesen - wenn halbtransparenter Pixel auftaucht - den darunterliegenden Pixel aus, um entsprechend zu mischen. Ja, mein Zeug puffert nicht irgendwoanders hin, sondern schreibt immer direkt in die Grafikkarte. Ich brauche den RAM für wichtigere Dinge...)
Re: VESA Graphikroutinen in Assembler
Hi zusammen,
habe diesen wirklich hochinteressanten Thread jetz erst wieder gefunden
Also ich wollte die main.exe mal auf meinem 486er mit S3 Trio64 ausprobieren und habe auch S3VBE geladen. Aber es funktioniert nicht. Es bricht mit der Meldung ab, dass es keine Vesa-Grafikkarte findet. Muss ich die Quellcodes nochmal mit dem von dir verwendeten Assembler neu linken?
Mein naechstes Ziel auf Basis dieser super Vorarbeit ist es, die VESA Modi (101h, 105h usw.) unter Borland Pascal mit Hilfe des integrierten Turbo Assemblers umzusetzen und fuer meine Programme nutzbar zu machen. Bisher bin ich aus Zeitmangel aber noch nicht dazu gekommen.
Habe die Settings.ini auch schonmal editiert, weil die Trio64 den 640x400 Grafikmodus nicht unterstuetzt, aber die Fehlermeldung war die Gleiche. Bei naechster Gelegenheit mach ich nochmal ein Foto von der Meldung, hab den genauen Wortlaut jetz nicht im Kopf...
habe diesen wirklich hochinteressanten Thread jetz erst wieder gefunden
![Shocked :shock:](./images/smilies/icon_eek.gif)
Also ich wollte die main.exe mal auf meinem 486er mit S3 Trio64 ausprobieren und habe auch S3VBE geladen. Aber es funktioniert nicht. Es bricht mit der Meldung ab, dass es keine Vesa-Grafikkarte findet. Muss ich die Quellcodes nochmal mit dem von dir verwendeten Assembler neu linken?
Mein naechstes Ziel auf Basis dieser super Vorarbeit ist es, die VESA Modi (101h, 105h usw.) unter Borland Pascal mit Hilfe des integrierten Turbo Assemblers umzusetzen und fuer meine Programme nutzbar zu machen. Bisher bin ich aus Zeitmangel aber noch nicht dazu gekommen.
Habe die Settings.ini auch schonmal editiert, weil die Trio64 den 640x400 Grafikmodus nicht unterstuetzt, aber die Fehlermeldung war die Gleiche. Bei naechster Gelegenheit mach ich nochmal ein Foto von der Meldung, hab den genauen Wortlaut jetz nicht im Kopf...
Fan von klassischer PC Hardware.
1) Am5x86 auf ASUS VL/I 486SV2GX4, 1MB L2, 64MB RAM, VLB-Monster
2) Am5x86 auf ECS UM8810P-AIO, 512KB L2, 64MB RAM, PCI-486er
Komplett-PCs und Hardware gesucht? -> Mein Hardware Flohmarkt
1) Am5x86 auf ASUS VL/I 486SV2GX4, 1MB L2, 64MB RAM, VLB-Monster
2) Am5x86 auf ECS UM8810P-AIO, 512KB L2, 64MB RAM, PCI-486er
Komplett-PCs und Hardware gesucht? -> Mein Hardware Flohmarkt
Re: VESA Graphikroutinen in Assembler
Falls manche Grafikkarten in VESA bestimmte Modi nicht unterstützen, obwohl sie technisch (also"OEM") vorhanden sind und funktioniern würden, hilft der bekannte
SciTech Display Doctor (SDD)
formerly known as
UniVBE
Wenn man das lädt (ein Treiber) werden plötzlich viel mehr VESA-Modi sichtbar. Außerdem hilft es auch auf alten Geräten, die eine VGA ganz ohne VESA hatten, um VESA-Modi zur Verfügung zu stellen. Schönes Ding.
SciTech Display Doctor (SDD)
formerly known as
UniVBE
Wenn man das lädt (ein Treiber) werden plötzlich viel mehr VESA-Modi sichtbar. Außerdem hilft es auch auf alten Geräten, die eine VGA ganz ohne VESA hatten, um VESA-Modi zur Verfügung zu stellen. Schönes Ding.
Re: VESA Graphikroutinen in Assembler
Statt UniVBE hab ich ja extra S3VBE20 Version 3.18 verwendet, um meine VLB Trio64 aus Anfang '95 auf VBE 2.0 zu bringen. Andere Testprogramme und alle Spiele, die VBE 2.0 Modi nutzen, funktionieren ja auch wunderbar.
Nur bekomme ich die schoene Demo aus diesem Thread iwie (noch) nicht zum Laufen![Frowning :frown:](./images/smilies/icon_frown.gif)
Nur bekomme ich die schoene Demo aus diesem Thread iwie (noch) nicht zum Laufen
![Frowning :frown:](./images/smilies/icon_frown.gif)
Fan von klassischer PC Hardware.
1) Am5x86 auf ASUS VL/I 486SV2GX4, 1MB L2, 64MB RAM, VLB-Monster
2) Am5x86 auf ECS UM8810P-AIO, 512KB L2, 64MB RAM, PCI-486er
Komplett-PCs und Hardware gesucht? -> Mein Hardware Flohmarkt
1) Am5x86 auf ASUS VL/I 486SV2GX4, 1MB L2, 64MB RAM, VLB-Monster
2) Am5x86 auf ECS UM8810P-AIO, 512KB L2, 64MB RAM, PCI-486er
Komplett-PCs und Hardware gesucht? -> Mein Hardware Flohmarkt