Portzugriife sind relativ langsam.bttr hat geschrieben:Nicht unbedingt. Die Frage ist ja, wie lange das Bank-Switching im Vergleich zum Schreiben von 64k Pixeln dauert.
Mit dem linearen Framebuffer verzichtet man bestenfalls auf die Verwendung der Video-BIOS-Pixelsetztroutine um den Bildschirm zu befüllen.(Über den "vbeFarPtr" ginge es am Int 10h vorbei, aber natürlich auch über's Video-BIOS.)
DWORD im EAX-Register in hexadezimale ASCIIs wandeln und ausgeben:Dosenware hat geschrieben:(man koennt ich kotzen, dass das in Pascal integrierte Assembler offenbar keine ordentlichen Offset und Segmentadressen zurueckliefert...)
kennst du eine funktion mit der ich Zahlen (nach moeglichkeit von byte bis comp) in Strings umwandeln kann?
Code: Alles auswählen
ASCII DB "00000000", "$" ; Platz für 8 Hexadezimale ASCIIs
;-------------------------------------
mov ax, DATA
mov ds, ax
mov eax, 6789ABCDh ; Beispielwert
call HEX
mov dx, OFFSET ASCII
mov ah, 9
int 21h
;-------------------------------------
; Subroutine
;-------------------------------------
HEX: mov di, OFFSET ASCII ; Doppel-Word nach Hex-Zeichen wandeln
mov cl, 8 ; 8 Zeichen
A: rol eax, 4 ; 1 Nibble weiter
mov bl, al
and bl, 0Fh ; nur low-Nibble
add bl, 30h ; nach ASCII wandeln
cmp bl, 39h ; größer als Ziffer neun?
jna short B
add bl, 7 ; dann Buchstabe von "A" bis "F"
B: mov [di], bl ; ASCII retten (nach ds:di)
inc di ; Zeiger erhöhen
dec cl ; Ziffer-Anzahl verringern
jnz A
ret
Code: Alles auswählen
WERT32 DB 20h, 20h, 20h, 20h, 20h, 20h, 20h, 20h, 20h, 20h
DB 0Dh, 0Ah, "$"
;-------------------------------------
mov ax, DATA
mov ds, ax
mov eax, 0FFFFFFFFh ; Werte von 0 bis 4.294.967.295
call DEZOUT32
mov dx, OFFSET WERT32
mov ah, 9
int 21h
;-------------------------------------
; Subroutine
;-------------------------------------------
DEZOUT32: mov ebx, 1000000000
mov cl, 0Ah ; maximal Zehn Ziffern
xor si, si
mov di, OFFSET WERT32
ASC32: xor edx, edx
div ebx
mov ebp, edx ; Rest retten
add al, 30h ; nach ASCII wandeln
and si, si ; schon ein Ascii eingetragen?
jnz short STORE32
cmp al, "0" ; Ascii = "0"?
jz short NULL32
STORE32: mov [di], al ; Ascii-Ziffer eintragen (nach ds:di)
inc si ; Ascii-Zähler erhöhen
NULL32: inc di ; Zeiger erhöhen
mov eax, ebx ; Teiler holen
mov ebx, 0Ah
xor edx, edx
div ebx ; durch Zehn
mov ebx, eax ; Wert retten
mov eax, ebp ; Rest holen
dec cl
jnz ASC32
ret
Im Prinzip kommt das hin, nur läuft AGP 1x auf 66 MHz, so dass man annehmen kann, dass der AGP die doppelte Transferrate eines normalen PCI 32 Bit 33 MHz Steckplatzes erreicht. Wieviel davon softwareseitig ankommt ist eine andere Frage.freecrac hat geschrieben: AGP-Karten werden unter DOS wohl nur auf PCI-Geschwindigkeit laufen. Für eine AGP-Übertragungsgeschwindigkeit muss man wohl diesen speziellen AGP-Transfermode erst einstellen bevor es schenller gehen kann.
Wie man das macht weiss ich allerdings nicht.
Wohl nur wenn dieser AGP-Transfer-Mode auch eingeschaltet wurde. Ich vermute sonst verhält sich eine AGP-Karte wie eine PCI-Karte und die volle Geschwindigkeit bleibt einfach ungenutzt.elianda hat geschrieben:Im Prinzip kommt das hin, nur läuft AGP 1x auf 66 MHz, so dass man annehmen kann, dass der AGP die doppelte Transferrate eines normalen PCI 32 Bit 33 MHz Steckplatzes erreicht.freecrac hat geschrieben: AGP-Karten werden unter DOS wohl nur auf PCI-Geschwindigkeit laufen. Für eine AGP-Übertragungsgeschwindigkeit muss man wohl diesen speziellen AGP-Transfermode erst einstellen bevor es schenller gehen kann.
Wie man das macht weiss ich allerdings nicht.
Zwischen dem zyklischen Befüllen des Bildspeichers wird das darzustellende Bild berechnet und aufbereitet. Das nimmt auch eine gewisse Zeit in Anspruch. Wenn beides länger dauert als der Zyklus den der Rasterstrahl unten abgeschaltet und ober wieder eingeschaltet wird haben wir ein erstes Zeitproblem einen fliessenden Ablauf zu gewährleisten.Wieviel davon softwareseitig ankommt ist eine andere Frage.
Ausreichend flott steht in diesem Zusammenhang damit wie (wenig) aufwendig die Spiele gestaltet sind.Für mich sieht es jedoch oft so aus, dass halbwegs moderne Local-Bus Karten (also PCI, VLB usw.) für DOS-Spiele ausreichend flott sind.
Das denke ich auch.Der Geschwindigkeitsunterschied ist bei den ISA-Karten noch viel relevanter.
Von den bei mir eingesteckten 4GB Ram bleiben nur noch ca. 2.8 GB nutzbar, der Rest ist belegt. Wie groß die UMBs sind habe ich jetzt nicht geschaut.Ich finde, dass andere Größen auch wichtig werden. Beispielsweise die BIOS-ROM Größe. Man hört häufiger, dass sich Leute modernere Karten in Retro Rechner verbauen und sich dann wundern, dass keine UMBs mehr zum hochladen zur Verfügung stehen.
Gemessen habe ich es noch nicht. Ich benutze heute selber nur noch Vesamodi mit LFB, weil mir die Bankumschltung zu umständlich ist.Oder wie der Unterschied zwischen LFB und Banked Betrieb ist.
Vermutlich weil es früher nur wenige Karten gab die LFB schon unterstützten und man kompatibel zu den älteren Karten bleiben wollte.Gerade die frühen Super-VGA Spiele nutzen trotz der höheren Auflösungen Banked Mode.
Jede Bankumschaltung (die ja letztendlich auch vom Bios über die entsprechende(n) Port(s) vorgenommen werden) dauert eben eine gewisse Zeit. Ich denke das diese Portzugriffe um einiges mehr an Zeit verschlingen, als der Biosaufruf mit allen darin abgearbeiteten Befehle zusammengerechnet ohne die eigentlichen Portzugriff(e) für die Bankumschaltung, so das es nur ein marginaler Unterschied ist ob man die Umschaltung über die Ports selber vornimmt, oder das Bios dieses erledigen läßt. Bei meiner ET4000 habe ich im BIOS die Ports für die Bankumschaltung gefunden und habe meine Anwendung entsprechend geändert in dem ich den Biosaufruf herausnahm und dort durch Portzugriffe ersetzte.Es stellt sich zwangsläufig die Frage ob die Bankumschaltung über das BIOS eine Geschwindigkeitsbremse ist.
Ich denke schon das die Zeit für die Bankumschaltung besonders in höheren Video-Modi relevant ist wenn bildschirmfüllende Veränderungen vorgenommen werden sollen.Wenn dies lange dauert, kann die Fillrate der Karte noch so gut sein und man merkt nichts davon.
66Mhz*32Bit ist bereits der langsamste Modus, da brauchst du nichts mehr einzuschalten.freecrac hat geschrieben: Wohl nur wenn dieser AGP-Transfer-Mode auch eingeschaltet wurde. Ich vermute sonst verhält sich eine AGP-Karte wie eine PCI-Karte und die volle Geschwindigkeit bleibt einfach ungenutzt.
hat aber nichts mit dem Bios der Geräte zu tun (eher mit dem Bios des Mainboards), das sind IO-Adressen.Von den bei mir eingesteckten 4GB Ram bleiben nur noch ca. 2.8 GB nutzbar, der Rest ist belegt.
kommt darauf an, die Matroxkarten laufen bei mir nur mit Firmwareversion 1.2, weil in der Version 1.8 einige Vesamodi zwar LFB unterstuetzen, dafuer aber langsamer sind, siehe: http://www.dosforum.de/viewtopic.php?p=5595#p5595Es stellt sich zwangsläufig die Frage ob die Bankumschaltung über das BIOS eine Geschwindigkeitsbremse ist.
Wieso eigentlich 66 Mhz, ich denke PCI(ohne X oder e) läuft mit 33 Mhz, so das jede AGP-Schnittstelle genau mit dieser Geschwindigkeit läuft, solange bis der schnellere AGP-Transfer-Mode eingeschaltet wird.Dosenware hat geschrieben:66Mhz*32Bit ist bereits der langsamste Modus, da brauchst du nichts mehr einzuschalten.freecrac hat geschrieben: Wohl nur wenn dieser AGP-Transfer-Mode auch eingeschaltet wurde. Ich vermute sonst verhält sich eine AGP-Karte wie eine PCI-Karte und die volle Geschwindigkeit bleibt einfach ungenutzt.
Doch auch, denn die Geräte blenden ihr Geräte-Bios und auch ihre Portadressen verwaltet vom Mainboardbios in unser Ram mit ein. Die Grafikkarte belegt dabei ebenfalls einen großen Adressbereich für Rom, IO und zwei Framebuffer.hat aber nichts mit dem Bios der Geräte zu tun (eher mit dem Bios des Mainboards), das sind IO-Adressen.Von den bei mir eingesteckten 4GB Ram bleiben nur noch ca. 2.8 GB nutzbar, der Rest ist belegt.
Das finde ich schon merkwürdig wenn Anwendungen mit LFB-Modi langsamer laufen als mit Banked-Modi, da bei LFB-Modi ja keinerlei Unterstützung vom Bios mehr benötigt wird für die Bankumschaltung wenn der betreffende Mode erst einmal eingeschaltet wurde.kommt darauf an, die Matroxkarten laufen bei mir nur mit Firmwareversion 1.2, weil in der Version 1.8 einige Vesamodi zwar LFB unterstuetzen, dafuer aber langsamer sind, siehe: http://www.dosforum.de/viewtopic.php?p=5595#p5595Es stellt sich zwangsläufig die Frage ob die Bankumschaltung über das BIOS eine Geschwindigkeitsbremse ist.
Super, dort werde ich gleich mal hinein schnuppern.elianda hat geschrieben:Für AGP siehe z.B. hier http://books.google.de/books?id=u6RE2pc ... &q&f=false
Ist das ein Hinweis darauf das Schreibzugriffe nach A000:0 möglicherweise schneller vollzogen werden können als in den LFB?Eine Frage beim schreiben in den Grafikkartenspeicher ist ja oft die Umsetzung. Die einfachste Annahme ist, dass die Bytes des Framebuffers den RAM der Grafikkarte abbilden und deren DAC die Daten im gleichen Format ausliest zur Darstellung. Das muss aber nicht zwangsläufig der Fall sein. Es kann auch sein, dass die Speicherlayouts sich unterscheiden und der Grafikchip Speicherzugriffe mit längerer Latenz benötigt.
Ja das kenne ich auch vom Ramspeicher, hierbei kann man bei Schreib- und Lese-Zugriffen Rücksicht auf den Cache nehmen und auch für ein Daten- und Code-Alignment sorgen. Falls darauf keine Rücksicht genommen wird, können wir mit einer Verzögerung rechnen.Wenn z.B. aus einem Word Write auf den Framebuffer zwei Bytezugriffe auf verschiedene Speicherseiten des Grafikspeichers folgen.
PCI gibts in den Varianten 33/66MHz 32/64Bit EDIT: Afair auch noch 3,3/5V, wobei bei normalen Nutzern fast ausschließlich die 33MHz/32bit Variante zum einsatz kam/kommt.freecrac hat geschrieben:Wieso eigentlich 66 Mhz, ich denke PCI(ohne X oder e) läuft mit 33 Mhz
Die Biosroutinen sind irgendwo zwischen C000 und FFFF eingeblendet - also den Ort fuer die UMBs.Doch auch, denn die Geräte blenden ihr Geräte-Bios und auch ihre Portadressen verwaltet vom Mainboardbios in unser Ram mit ein.
Aha, du hast recht ich habe mal hier geschaut: http://www.ece.mtu.edu/faculty/btdavis/ ... PCI_22.pdfDosenware hat geschrieben:PCI gibts in den Varianten 33/66MHz 32/64Bit EDIT: Afair auch noch 3,3/5V, wobei bei normalen Nutzern fast ausschließlich die 33MHz/32bit Variante zum einsatz kam/kommt.freecrac hat geschrieben:Wieso eigentlich 66 Mhz, ich denke PCI(ohne X oder e) läuft mit 33 Mhz
stell dir AGP in der langsamsten Variante also einfach als 66MHz/32bit PCI vor
Ok.- PCI X/E sind schon wieder ganz andere Geschichten.
Genau.Die Biosroutinen sind irgendwo zwischen C000 und FFFF eingeblendet - also den Ort fuer die UMBs.Doch auch, denn die Geräte blenden ihr Geräte-Bios und auch ihre Portadressen verwaltet vom Mainboardbios in unser Ram mit ein.
Wobei dieser Bereich wohl für Memory Mapped I/O gemeint ist?Bei den Portadressen spielt die Größe keine wirkliche Rolle, da reserviert das Mainboardbios ueblicherweise ~500MB fuer diesen Zweck.
Ohne Memmorymanager ala emm386.exe kann jede DOS-Anwendung doch selber in den PM schalten und den gesamten 4GB-Adressraum nach belieben und Möglichkeit auch selber verwalten.Wichtiger ist der Ort (naja, in einem Dosforum eigentlich nicht - welches Dosprogramm braucht schon Gigabyteweise Speicher?),
denn den Speicher der dahinter noch frei ist koennen die wenigsten Systeme verwalten,
Ich hatte schon vor dem Kauf des Asus Striker 2 vermutet das so kommen wird, von Pech kann also nicht wirklich die Rede sein.mit deinen 2,8 Gb hattest du also nur das Pech, dass die Portadressen an einer recht niedrigen Speicheradresse eingeblendet wurden, bei mir geht das erst ab 3,25GB los.
Daran aendert auch andere Hardware nichts, solange das Mainboard(bios) dasselbe bleibt - nur zwischen C000-FFFF kann sich dann einiges veraendern.
der download klappt leider nichtCptKlotz hat geschrieben: Den Benchmark bekommt Ihr hier http://dos.skillreactor.org/addons/silv ... PBENCH.ZIP.
