Ja, guten Tag. Ich habe mal eine Frage, zwecks Programmierung unter VESA.
Also: Ich weiß, wie VESA funktioniert. Benutze das schon (erfolgreich) seit Jahren. Ich nutze (weil 16bit / RealMode DOS) die "banked" Variante von VESA (nicht den Linearen Framebuffer, weil das in 16-Bit keinen Sinn macht).
Und normalerweise habe ich keine Probleme.
Aber ich lasse mein Zug auch bei Kumpeln testen. Und auf seinen beiden Notebooks:
- Sony VGN-SZ3VWX
- und EEE-PC (dieses neue Teil da)
haben die Grafiken so seltsame schwarze Balken zwischendrin, immer an anderen Stellen, wenn das Programm startet. Sieht so aus, als wenn der bestimmte Speicherbereiche irgendwie "ausblendet" (ist so Balken, der halt auf halber Zeile anfängt, paar Zeilen schwarz, dann wieder so irgendwie habe Zeile). Diese Balken sind nicht so groß wie eine 64kB-Bank, sondern schmaler. (Achja: Das ist Shared Memory - also SystemRAM wird von der Grafikkarte mit benutzt.) Habe den Verdacht, daß der Protected Mode diese Speicherbereiche für Beschreiben ausblendet und in der DOS-Emulation vergißt, wieder freizumachen.)
Wenn ich da in der Grafik etwas animiere, bleiben diese schwarzen Balken bestehen und das animierte bewegt sich unter den schwarzen Balken hindurch.
Kumpel hat schon gesagt, es wird stärker, wenn er die CPU-Leistung runtersetzt (also vielleicht irgendein Timing-Problem?)
In beiden Rechnern ist dieser Grafikchip (meldet VESA) :
Produkt: Intel 82945GM Family Graphics Controller
VESA-BIOS: Intel 82945GM Chip Accelerated VGA BIOS
Wenn er das Programm / die Programme verläßt - und in Textmode (also 80x25, 16 Farben) schalte, (mov ax, 0003h ; int 10h), stürzen beide Rechner komplett ab - nicht nur der Task - sondern das ganze System - nur hardwaremäßig zu resetten...
(Anmerkung: Ich dachte immer, XP wäre so "sicher" - wie kann sich ein PROTECTED MODE BETRIEBSSYSTEM von 2003 von nem 16-Bit (Real Mode) DOS-Programm so einfach komplett killen lassen???)
Was für eine Scheiße ist das und wie kann ich sie beheben?
(Sieht mir nach nem Treiberproblem aus. Entweder der Grafikkarten-VESA-Treiber schlampig programmiert - hatte sowas mal bei der ATI Radeon 9600 / 9800 Serie bei Leuten festgestellt - oder der Windows-Grafiktreiber spinnt. Kumpel sagt auch, daß er früher keine Probleme mit meinem Zeug hat, aber seit er den intel-Grafik-Treiber drauf hat, gibts da Probleme. Wahrscheinlich ist die VESA-Emulation nicht einfach "durchgeleitet", sondern von denen (intel) selbst programmiert - und das etwas... mangelhaft.)
Anmerkung: Er hat's auf den Rechnern grad in reinem DOS getestet - und da gibt es (wie zu erwarten war) keines dieser Probleme... Äußerst bizarr...
Anmerkung: Ich halte mich exakt an die VESA-Spezifikationen, fummle da nicht mit Registern rum, sondern benutze nur die dafür vorgesehenen Software-Int 10h Aufrufe.
Kennt jemand dieses Problem und weiß, wie man es umgehen kann? (Wahrscheinlich gar nicht. Außer: Treiber abschießen, anderen Treiber rauf (wenns sowas gibt)...
Probleme mit VESA auf neuen Rechnern.
Das sind nur sehr alte Karten (bevor es VESA gab und die dann mit UniVBE geVESAt wurden), die neuen haben alle 64k.Dosenware hat geschrieben:manche Karten nutzen afair nur 32kb im Blankedmode...
Außerdem meldet VESA auch 64kB Bankgröße. (Hab mal so Testprogramm dafür gemacht, das alles über VESA meldet.)
Nö, lieber nicht. Ist ein Programm in ganz frühem Anfangsstadium. Will ich ungern jetzt schon rausgeben.Dosenware hat geschrieben:kannst du den delinquenten mal online stellen? wuerde gern mal schauen was mein Wind dazu sagt...
Normalerweise gibts da auch nicht wegen Win diese Probleme. Es muß wahrscheinlich am Treiber liegen, der das für mich testet, sagt auch, daß er das früher bei meinem VESA Zeug nicht hatte. Ist halt schade... - Da macht man schonmal was hochauflösendes (800x600) und dann spinnt wieder irgendwas. Es nervt...
Entschuldiung, daß ich jetzt erst antworte- Ich war so beschäftigt...elianda hat geschrieben:Ist das Problem auch bei Duke3D unter 800x600 vorhanden?
Duke 3D hat der gerade nicht auf seinem Rechner. (Er wohnt 800 km von mir entfernt.)
Aber er hat es mit einem DOS-Demo vom RealTech (das auch VESA ist, 640x480) getestet - da ist der Rechner ihm gleich abgestürzt.
Das Problem muß am Treiber liegen, er hat da eine DOS-Partition drauf erstellt und es in DOS laufen lassen und da geht es.
Hab es von ihm auch mal von meinem "Crown System" (eine "GUI", (in DOS) die von einem selbstentwickelten (tokensierten) Skript-BASIC gesteuert wird.) testen lassen. Der Mauspfeil geht UNTER den schwarzen Streifen durch, so als würden die das Bild überlagern.
Es liegt wohl wirklich an einem liederlich programmierten Grafiktreiber, der VESA nicht richtig emuliert - und wenn der Treiber schon zu doof ist, das zu machen, dann stattdessen das originale VESA (von der Grafikkarte, das ja offensichtlich korrekt funktioniert) durchzuleiten.
Die Grafikkarte benutze da Shared Memory. Und mein Verdacht ist der: Da Windows in 32bit (Protected Mode) läuft und man im Protected Mode bestimmte SPeicherbereiche für Lese-/Schreibzugriffe sperren kann, wird genau dies passieren und bei Benutzung des DOS-Fensters werden diese nicht wieder freigegeben.
Offensichtlich rechnet niemand damit, daß im DOS-Fenster unter Windows jemand VESA benutzt - denn ich kriege VESA da auch nur mit einem Trick hin:
Wenn man im Windows-Fenster VESA anspricht, liefern die AX=$4Fxx, INT $10 Funktionen eben nichts zurück - so als wäre kein VESA da. Man muß Windows erst in Vollbild schalten, damit er dann VESA findet. Weil man das vom DOS-Fenster aus nicht einfach so machen kann, hab ich einen Trick herausgefunden, um Windows zu zwingen, in Vollbild zu schalten: Man schaltet einfach in einen VGA-Grafikmode - am besten Mode $13 (hex) - das ist dieser gebräuchlichste (320x200, 256 Farben), der wirklich überall funktioniert (es sei denn, man hat nichtmal VGA...) und dann bleibt Windows nichts anderes übrig, als in Vollbild zu schalten. Und dann kann findet man auch VESA.
Aber möglicherweise war das "DOS-Fenster" von Windows gar nicht dazu gedacht, daß man da VESA findet und vielleicht machen die (der Treiber) ja dann wirklich nur z.B. die ersten 256 kB (den VGA-Speicher) des Grafikspeichers "frei"...
Mann, verdammt... Nur Idioten da in Redmond. Und bei Intel (wo der Treiber herkommt), scheinbar auch. Jedes neue System von MS wurde von mal zu mal langsamer und unbrauchbarer...
(Reg ich mich auf? Nö... Dann können eben Windows-Nutzer, die miese Treiber benutzen, mein Zeug nicht benutzen. Wahrscheinlich könnte ich sogar, wenn ich mich monatelang damit abquälen würde, irgendeinen Workaround finden, um diese Unzulänglichkeiten zu umgehen. --- Und dann bringt Intel vielleicht 'ne neue Version von dem Treiber 'raus und dann geht der Workaround wieder nicht... Ist das der Mühe Wert? Ich meine nein...)
Re: Probleme mit VESA auf neuen Rechnern.
Auch mit dem 16 Bit-Adressmode(im Protectmode oder dem Unrealmode/Bigrealmode) kann man den gesamten 4GB-Adressraum adressieren.DOSferatu hat geschrieben:Ja, guten Tag. Ich habe mal eine Frage, zwecks Programmierung unter VESA.
......Ich nutze (weil 16bit / RealMode DOS) die "banked" Variante von VESA (nicht den Linearen Framebuffer, weil das in 16-Bit keinen Sinn macht).
Kurze Info für alle 80386+:
Es gibt den 16Bit-Protectmode und den 32Bit-Protectmode.
Es gibt den uns allen bekannten 16Bit-Realmode und auch den 32Bit-Realmode.
Dann gibt es noch den Unrealmode/Bigrealmode den man ebenfalls zusammen mit dem 16 Bit-Adressmode, oder auch mit dem 32 Bit-Adressmode verwenden kann.
In allen Modi ob PM oder RM, oder auch dem Unrealmode, im 16Bit und auch im 32Bit Adressmode sind alle 32 Bit-Register vorhanden und können verwendet werden.
Im PM egal ob im 16Bit oder im 32Bit Adressmode bilden die 32Bit-Offset-Register zusammen mit den Selektoren und den darauf zeigenden Segment und dessen Segmentgrösse in der GDT/LDT
zusammen die Adresse im 4GB-Adressraum(virtuelle Adressierung/Paging lassen wir mal unberücksichtig). Im RM ist die Adressbildung auf 1 MB+64KB-1 begrenzt und bildet sich aus einem Segment-Register und einem 16Bit-Offset(Register/Adresse).
Die Segmente sind auf 64KB begrenzt. Im Unrealmode wird ähnlich wie im RM die Adresse über Segmente gebildet, nur das hier die Segmentgröße auf 4GB erhöht wurde und wir damit nun über ein erhöhtes Segment(Register) und einem 32Bit-Offset(Register/Adresse) eine 4GB Adresse bilden können.
Nun zu den beiden Adresmodi(16 und 32Bit ):
Der Unterschied zwischen dem 16 Bit-Adressmode und dem 32 Bit-Adressmode liegt einzig und allein darin wie Registersize-, Operandsize- und Adresssize-Prefixe
von der CPU interpretiert werden! Mit der Größe des adressierbaren Adressbereiches hat das gar nichts tun.
Beispiele:
[16 Bit-Adressmode]
Wenn man im 16 Bit-Adressmode ein 32 Bit-Register benutzen möchte muss vor dem jeweiligen Opcode ein Registersize-Prefix plaziert werden damit die CPU
weiss das hier ein 32 Bit-Register verwendet werden soll. Ohne dieses Registersize-Prefix werden nur die unteren 16 Bit des Registers für die Operation verwendet.
[32 Bit-Adressmode]
Wenn man im 32 Bit-Adressmode ein 32 Bit-Register benutzen möchte, braucht/darf man kein Registersize-Prefix vor dem Opcode plazieren und umgekehrt
wenn man ein 16 Bit-Register benutzen möchte, muss man ein Registersize-Prefix vor dem Opcode plazieren.
...
Ich benutze den Unrealmode(im 16Bit-Adressmode) um Vesamodi mit linaeren Framebuffer zu benutzen. Bei Interesse bin ich gerne bereit dieses in allen Details zu erklären.
Dirk
Zuletzt geändert von freecrac am Do 22. Apr 2010, 16:41, insgesamt 2-mal geändert.
Re: Probleme mit VESA auf neuen Rechnern.
Ich kenne den "Unreal" "4G" "Real Huge" oder was es sonst für kunstvolle Bezeichnungen dafür gibt, habe ihn aber noch nicht benutzt. Er ist eine Art Hybrid zwischen 16bit Mode ("Real Mode") und 32bit Mode ("Protected Mode"). Und ich weiß auch, daß der quasi mit einem kleinen "Hack" erzeugt wird: Man schaltet in PM, setzt die Segmentgrenzen von 16bit auf 32bit und schaltet zurück zum RM - und schon hat man einen 32bit Adreßraum. Aber das funktioniert nur unter bestimmten Bedingungen (PC darf nicht schon im V86 Mode sein und so) und ich bezweifle, ob mein DOS-Kram dann auch noch unter WIndows läuft...
Wie gesagt, ich bin mir dessen bewußt, habe es aber noch nie benutzt. Und normalerweise sollte der "Banked" Mode eigentlich immer funktionieren. Es gibt ein Bit in den Flags (bei der VESA Abfrage), das gesetzt ist, wenn Banked nicht geht.
Und ich weiß, über Zugriff mit linearem Framebuffer (wenn supportet) würde man natürlich mehr Performance herausholen können.
Ich habe auch schon vor etlichen Jahren mal Codebeispiele gefunden, wie man den 4G einschaltet. Aber mein ganzes Zeug (meine Units, meine ASM-Subroutinen) sind so auf diesen RealMode ausgelegt...
Aber in Assembler benutze ich auch die 32bit Präfixe. Weil das ASM im Pascal nur maximal 286er Code erlaubt, erzeuge ich 386er Assembler (erweiterte Segmentregister, 32bit Register, etc) mit diesen Präfixbytes "von Hand"...
@freecrac:
Aber ich bin wohl nicht so versiert wie Du. Finds cool, daß hier mal jemand ist, der als Coder so richtig abgeht. Da könnte ich noch eine Menge lernen.
Was programmierst Du denn so? Tools? Demos? Spiele? Ich würde gerne mal etwas davon sehen - gibt es eine Webseite oder einen Link?
Wie gesagt, ich bin mir dessen bewußt, habe es aber noch nie benutzt. Und normalerweise sollte der "Banked" Mode eigentlich immer funktionieren. Es gibt ein Bit in den Flags (bei der VESA Abfrage), das gesetzt ist, wenn Banked nicht geht.
Und ich weiß, über Zugriff mit linearem Framebuffer (wenn supportet) würde man natürlich mehr Performance herausholen können.
Ich habe auch schon vor etlichen Jahren mal Codebeispiele gefunden, wie man den 4G einschaltet. Aber mein ganzes Zeug (meine Units, meine ASM-Subroutinen) sind so auf diesen RealMode ausgelegt...
Aber in Assembler benutze ich auch die 32bit Präfixe. Weil das ASM im Pascal nur maximal 286er Code erlaubt, erzeuge ich 386er Assembler (erweiterte Segmentregister, 32bit Register, etc) mit diesen Präfixbytes "von Hand"...
@freecrac:
Aber ich bin wohl nicht so versiert wie Du. Finds cool, daß hier mal jemand ist, der als Coder so richtig abgeht. Da könnte ich noch eine Menge lernen.
Was programmierst Du denn so? Tools? Demos? Spiele? Ich würde gerne mal etwas davon sehen - gibt es eine Webseite oder einen Link?
Re: Probleme mit VESA auf neuen Rechnern.
So wie ich den Unrealmode benutze ist es eher eine Mischung aus 16Bit PM und 16Bit RM, denn den 32Bitmode schalte ich nicht an, sondern ich bleibe im 16Bit -Adressmode, schalte den PM an, erweitere das DS-Segment und schalte wieder zurückDOSferatu hat geschrieben:Ich kenne den "Unreal" "4G" "Real Huge" oder was es sonst für kunstvolle Bezeichnungen dafür gibt, habe ihn aber noch nicht benutzt. Er ist eine Art Hybrid zwischen 16bit Mode ("Real Mode") und 32bit Mode ("Protected Mode").
in den RM der mit einem erweiterten Segment als Unrealmode bezeichnet wird. DOS kann man damit ohne Probleme benutzen, es gibt nur die Einschränkung das keine Anwendung danach in den PM schalten darf, denn sonst wird die dortige
Segmentgröße verwendet und falls dort die Segmente auf 64KB begrenzt werden und damit wieder zurück in den RM geschaltet wird ist damit der Unrealmode quasi wierder abgeschaltet.
Auch dürfen keine Memmorymangager ala emm386 benutzt werden, da diese es verhindern das man selber in den PM schaltet.
Der 32Bit-Adressmode hat mit der Größe des adressierbaren Adressraumes nichts zu tun, denn die Segmentgröße im verwendeten GDT/LDT bestimmt einzig und alleine darüber ob man den gesamten Adressraum adressieren kann, oder nichtUnd ich weiß auch, daß der quasi mit einem kleinen "Hack" erzeugt wird: Man schaltet in PM, setzt die Segmentgrenzen von 16bit auf 32bit und schaltet zurück zum RM - und schon hat man einen 32bit Adreßraum.
und das geht ebenso im PM mit dem 16Bit-Adressmode.
Siehe dazu auch die GDT und im Detail das Flag für den 16Bit- und/oder den 32Bit-Adressmode(wird in folgender Beschreibung als "Sz: Size bit" bezeichnet) und die Bytes für die Segmentlänge die den Adressraum definieren:
http://wiki.osdev.org/Global_Descriptor_Table
-------------------------
Hier die von mir verwendete Befehle um in den Unrealmode zu schalten. Zum besseren Verständniss habe ich mal alles Andere weggelassen, diese Befehle müssen also noch in eine Anwendung eingebettet werden:
Code: Alles auswählen
cli ; IRQs abschalten, da wir keine IRQs im PM nutzen wollen und dafür somit auch keine entsprechnde IRQ-Tabelle für den PM benötigen
in al, 70h
or al, 80h ; NMIs abschalten
out 70h, al
call ESEG ; in den Unrealmode schalten(nur DS wird erweitert); der 16Bit-Adressmode wird beibehalten
in al, 70h ; NMIs einschalten
and al, 7Fh
out 70h, al
sti ; IRQs für den Unrealmode wieder anschalten
;..........Hier Testroutine einbauen...........
; Ich verwende DS für den Datenbereich, sowie für alle linearen Zugriffe des gesamten 4GB Adressraumes. Den linearen Offset(hier framebuffer) berechne ich dabei wie folgt:
mov ax, DATEN ; Zeiger auf Datensegment innerahlb unserer Anwendung
mov ds, ax
mov bx, OFFSET VMINFO ; Wir haben uns für den verwendeten VESA-Mode die Modeinfo schon vorher in unseren Datenbereich nach "VWINFO" geholt
mov ebx, DWORD PTR[bx+28h] ; linearen Bild-Offset aus Vesamode-Info holen
xor esi, esi
mov si, DATEN ; Zeiger auf unser Datenssegment
shl esi, 4
sub ebx, esi
;...
; Nun kann man z.B. mit:
; mov [ebx], eax ; Adresse bildet sich aus "DS:EBX"
; den Inhalt vom EAX-Register in den Framebuffer(oberste linke Ecke) schreiben und damit fortlaufend den gesamten Bildschirm linear adressieren in dem wir das 32Bit-Offsetregister erhöhen.
; Das DS-Segmentregister kann dabei auf unseren deklarierten Datenbereich innerhalb unsere Anwendung im unteren Megabyte zeigen, so das wir auf unsere Daten dort ebenfalls zugreifen können.
; ..........
;..........Programm beenden......
;----------------------------------------------------------------------------
; Subroutinen und GDT im Codesegment
;----------------------------------------------------------------------------
GDTZEIGER DW ? ; Länge der GDT
DW ? ; Adresse low -Word:SEGMENTE
DW ? ; Adresse high-Word:SEGMENTE
DW 0 ; reserviert
SEGMENTE DW 0 ; Bits: 0-15 Seg.länge(Bit0-15)
DW 0 ; Bits: 0-15 Basis-Adresse Deskriptor-Table
DB 0 ; Bits:16-23 Basis-Adresse Deskriptor-Table
DB 0 ; Bits: 0- 7 Zugriffsrechte
DB 0 ; Bits: 0- 3 Seg.länge(Bit16-19)/Bit7:1=4KByte/0=1Byte
DB 0 ; Bits:24-31 Basis-Adresse Deskriptor-Table
DW 0FFFFh ; Segmentlänge Bits: 0-15
DW 0 ; Adresse low Bits: 0-15
DB 0 ; Adresse high Bits:16-23
DB 9Ah ; Zugriffsrechte
DB 0 ; Seg.Länge Bits:16-19 im Bit0-3 /Bit7:1=4KByte/0=1Byte
DB 0 ; Bits:24-31
DW 0FFFFh ; Segmentlänge Bits: 0-15
DW 0 ; Adresse low Bits: 0-15
DB 0 ; Adresse high Bits:16-23
DB 92h ; Zugriffsrechte
DB 0 ; Seg.Länge Bits:16-19 im Bit0-3 /Bit7:1=4KByte/0=1Byte
DB 0 ; Bits:24-31
; Damit wird das DS-Segment geladen und abweichend vom Realmode wird die Segmentlänge(ersten 16Bit + zusammen mit den beiden untersten Bytes mit 0FFh) hier auf 4GB erweitert.
DW 0FFFFh ; Segmentlänge Bits: 0-15
DW 0 ; Seg.Adresse Bits: 0-15
DB 0 ; Seg.Adresse Bits:16-23
DB 92h ; Zugriffsrechte
DB 0FFh ; Seg.Länge Bits:16-19 im Bit0-3//Bit7:1=4KByte/0=1Byte
DB 0FFh ; Bits:24-31
SEGMENTE_END label WORD
Gdt_Groesse equ (OFFSET SEGMENTE_END - SEGMENTE -1)
;----------------------------------------------------------------------------
; Hier nun die eigentlich Subroutine die den Unrealmode anschaltet
;----------------------------------------------------------------------------
ESEG: xor eax, eax
mov ax, cs
mov ds, ax
shl eax, 4 ; EAX ist nun physikalische
mov ebx, eax ; Segmentstartadresse
mov WORD PTR[SEGMENTE+0Ah], ax ; in den Deskriptoren
mov WORD PTR[SEGMENTE+12h], ax ; für CS
ror eax, 10h ; und SS in der
mov BYTE PTR[SEGMENTE+0Ch], al ; GDT abspeichern
mov BYTE PTR[SEGMENTE+14h], al
xor eax, eax ; EAX auf null
mov ax, OFFSET SEGMENTE ; 16-Bit-Offset
add ebx, eax ; GDT-Adresse im
mov WORD PTR[GDTZEIGER], Gdt_Groesse ; GDT-Deskriptor
mov DWORD PTR[GDTZEIGER+2], ebx
pushf ; Flags retten
lgdt FWORD PTR[GDTZEIGER] ; GDT laden
mov dx, ss ; SS retten
mov eax, cr0 ; Steuerwort 0 nach EAX
or al, 1 ; Protected Mode ein
mov cr0, eax ; im Steuerwort
; Prefetch-Puffer löschen
DB 0EAh ; die folgenden Zeilen
DW (OFFSET PMODE) ; erzeugen:
DW 8 ; JMP FAR CS:PMODE
;------------------------------------------------
PMODE: mov ax, 10h ; SS-Selektor auf 64
mov ss, ax ; KByte begrenzen
mov ax, 18h
mov ds, ax ; DS-Selektor erweitern
mov eax, cr0 ; Steuerwort 0 nach EAX
and eax, not 1 ; Protected Mode aus
mov cr0, eax ; im Steuerwort
; Prefetch-Puffer löschen
DB 0EAh ; Die folgenden Zeilen er-
DW (OFFSET RMODE) ; zeugen das Kommando
AKTSEG DW (SEG RMODE) ; JMP FAR CS:RMODE
;---------------------------------------------
RMODE: mov ss, dx ; SS zurueck
popf ; Flags holen
;----------------------------------------------------------------------------
BIT_FREI: call W_8042 ; Adressleitung freischalten
jnz BACK
mov al, 0D1h
out 64h, al
call W_8042
jnz BACK
mov al, 0DFh
out 60h, al
;---------------------------------------
W_8042: xor cx, cx
STATUS: in al, 64h
and al, 2
loopnz STATUS
BACK: ret
http://groups.google.de/group/de.comp.o ... d80c?hl=de
Im Abschnitt: [--Detailiertere Anleitung für den Unrealmode--] . Dort habe ich den Code in ein Roh-Gerüst zum assemblieren hineingelegt so das man mit MASM 5 eine ausführbaren Anwendung erzeugen kann.
MASM 5 kann man hier herunterladen:
http://microprocessados.lesc.ufc.br/dow ... masm51.zip
Ein Rohgerüst für MASM 5 um eigenen Anwendungen zu erstellen habe ich unter "Programmierung unter DOS" plaziert:
http://www.dosforum.de/viewtopic.php?f= ... 190#p15190
Zusammen mit Windows oder auch im V86-Mode vom emm386 oder vergleichbaren Memmorymanager kann man den Unrealmode nicht verwenden.Aber das funktioniert nur unter bestimmten Bedingungen (PC darf nicht schon im V86 Mode sein und so) und ich bezweifle, ob mein DOS-Kram dann auch noch unter WIndows läuft...
Letzendlich muss man bei jeden "Banked" Mode immer die jeweilige 64KB große Bank einschalten um den gesamten Bildschirm adressieren zu können und dafür muss man mindestens ein Portzugriff machen der natürlichWie gesagt, ich bin mir dessen bewußt, habe es aber noch nie benutzt. Und normalerweise sollte der "Banked" Mode eigentlich immer funktionieren. Es gibt ein Bit in den Flags (bei der VESA Abfrage), das gesetzt ist, wenn Banked nicht geht.
Und ich weiß, über Zugriff mit linearem Framebuffer (wenn supportet) würde man natürlich mehr Performance herausholen können.
einiges an Zeit für die Umschaltung benötigt. Auch muss die Adressberechnung hierbei aufwendiger gestaltet sein, da man nun bei jedem Pixel den man setzen möchte die jeweilige Bank berücksichtigen und auch berechnen muss.
Ups, das ist natürlich etwas aufwendig. Wenn ich unter puren DOS mit MASM 5 programmiere und z.B MMX-Register verwenden möchte muss ich diese auch von Hand als Bytes dort eintragen, da MASM 5 noch keine MMX-Register kennt.Ich habe auch schon vor etlichen Jahren mal Codebeispiele gefunden, wie man den 4G einschaltet. Aber mein ganzes Zeug (meine Units, meine ASM-Subroutinen) sind so auf diesen RealMode ausgelegt...
Aber in Assembler benutze ich auch die 32bit Präfixe. Weil das ASM im Pascal nur maximal 286er Code erlaubt, erzeuge ich 386er Assembler (erweiterte Segmentregister, 32bit Register, etc) mit diesen Präfixbytes "von Hand"...
MASM 6 kennt zwar schon MMX-Register braucht aber zur Ausführung Windows. Dort kann ich dann einfach die Mnemonics für MMX-Befehle verwenden. Damit man mit MASM 6 aber eine 16Bit-Realmode/Unrealmode-Anwendung erzeugen kann
muss man link.exe von MASM 5 verwenden. Auch muss man dann natürlich um die Anwendung ausführen zu können jedesmal DOS booten und dann zum Assemblieren wieder Windows booten. Wenn sich dann viele Fehler im Opcode eingeschlichen
haben, kann das dann schnell zur Boot-Orgie ausarten.
Ich programiere kleine Demos, aber meine Webseite ist im Moment offline. Ich hoffe das mein obiger Beispiel-Code dir den Unrealmode etwas näher gebracht hat. Möglicherweise kannst du diesen Code in deine eigenen Anwendungen einbauen.@freecrac:
Aber ich bin wohl nicht so versiert wie Du. Finds cool, daß hier mal jemand ist, der als Coder so richtig abgeht. Da könnte ich noch eine Menge lernen.
Was programmierst Du denn so? Tools? Demos? Spiele? Ich würde gerne mal etwas davon sehen - gibt es eine Webseite oder einen Link?
Falls du jedoch auch Anwendungen komplett mit Assembler programmieren möchtest kann ich dir gerne auch ein Assembler-Rohgerüst(für eine 16Bit-DOS-Anwendung) posten das man dann für eigene Anwendungen benutzen kann.
Dirk
Zuletzt geändert von freecrac am So 23. Mai 2010, 12:40, insgesamt 5-mal geändert.
Re: Probleme mit VESA auf neuen Rechnern.
Für Vesamodi mit höherer Refreshrate als 60hz braucht man ein VBE3-Bios und einen analogen CRT-Monitor.
Im folgenden Beispiel wird gezeigt wie man für eine pure DOS-Anwendung einen linearen Vesamode mit 1024x768x32 mit 100hz Refreshrate einschaltet. Dafür kann man z.B. eine GF4 und ein 19" CRT-Monitor mit 96khz verwenden.
Zu Beginn werden vom verwendeten CRT-Monitor dessen Parameter geholt um sicherzustellen das wir nur Parameter verwenden die er auch verträgt. (Anderenfalls schalten sich moderne CRT-Monitore mit einer entsprechenden Fehlermeldung ab, oder ältere CRT-Monitore können dadurch beschädigt werden.) BNC-Monitor-Kabel sind dafür weniger geeignet, da dort keine DDC-Leitung vorhanden ist. Wenn man die Spezifikation des verwendeten Monitors jedoch gemau kennt, kann man aber auch (etwas abweichend von diesem Beispiel) ohne Abfrage der Monitordaten höhere Hz-Werte für den gewünschten Vesamode einstellen.
Die nun verwendeten Zeilen müssen in eine Anwendung eingebettet werden die in den Unrealmode schaltet um einen linearen Zugriff auf den Framebuffer zu ermöglichen(siehe dazu meinen Beitrag über den Unrealmode). Die verwendeten Mnemonics entsprechen dem MASM-Syntax.
Beitrag erneut geändert: U.a werden hierbei die EDID-Monitorinformationen ausgewertet. Siehe darüber auch meinen neueren Beitrag hier: http://www.dosforum.de/viewtopic.php?f= ... 1&start=15
Die von mir verwendeten Dokumente kann man als "VESA PUBLIC STANDARDS" von "vesa.org" kostenlos herunterladen.
vbe3.pdf
EEDIDguideV1.pdf
EEDIDverifGuideRa.pdf
Seit Jahresbeginn funktionieren jedoch die alten direckten Links die man für die Dokumente auch mit Google finden konnte nicht mehr. Die VESA-Gruppe möchte es wohl lieber das man sich auch bei ihnen registriert wenn man die Dokumente herunterladen möchte. Wenn man sich dort registreirt hat, kommt man auch zu einer Seite wo gewünschte Doku zu finden sind, die aber nur solange man angemeldet ist auch erreichbar und abfrufbar bleiben. Danach funktionieren die Links nicht mehr.
(Das "vbe3.pdf" habe ich auch auf einer anderen Internetadresse mit Google gefunden, ich habe aber den Verdacht das der verantwortliche Admin für das dortigen Doku keine Verbreitungsrechte hat. Deshalb poste ich den Link dazu nicht.)
Startseite:
http://www.vesa.org/
Registrieren:
https://fs16.formsite.com/VESA/form7148 ... index.html
Abweichend von den oben verwendeten Vesamode mit 100hz und den dafür verwendeten Datenbereich der beginnend mit "CRTC" deklariert ist habe ich noch andere Parameter für verschieden andere Vesa-Modi.
(Leider bin ich noch nicht dazu gekommen die CRTC-Parameter via GTF selber zu berechnen. Zum Teil habe ich sie mir vom VBEHZ-Tool berechnen lassen, oder habe sie von einer Grafiktreiber-Ausgabe abgeschrieben.)
Wenn man die Werte etwas von "horizontal Total" z.B. erhöht/verringert verschiebt sich die Bildausgabe horizontal.
Abschliessend möchte ich auch noch erwähnen das alle Versuche die ihr mit dem obigen Code/Daten selber macht in eurer eigenen Verantwortung liegen und das ich für eventuelle Schäden keinerlei Haftung übernehme.
Dirk
Im folgenden Beispiel wird gezeigt wie man für eine pure DOS-Anwendung einen linearen Vesamode mit 1024x768x32 mit 100hz Refreshrate einschaltet. Dafür kann man z.B. eine GF4 und ein 19" CRT-Monitor mit 96khz verwenden.
Zu Beginn werden vom verwendeten CRT-Monitor dessen Parameter geholt um sicherzustellen das wir nur Parameter verwenden die er auch verträgt. (Anderenfalls schalten sich moderne CRT-Monitore mit einer entsprechenden Fehlermeldung ab, oder ältere CRT-Monitore können dadurch beschädigt werden.) BNC-Monitor-Kabel sind dafür weniger geeignet, da dort keine DDC-Leitung vorhanden ist. Wenn man die Spezifikation des verwendeten Monitors jedoch gemau kennt, kann man aber auch (etwas abweichend von diesem Beispiel) ohne Abfrage der Monitordaten höhere Hz-Werte für den gewünschten Vesamode einstellen.
Die nun verwendeten Zeilen müssen in eine Anwendung eingebettet werden die in den Unrealmode schaltet um einen linearen Zugriff auf den Framebuffer zu ermöglichen(siehe dazu meinen Beitrag über den Unrealmode). Die verwendeten Mnemonics entsprechen dem MASM-Syntax.
Code: Alles auswählen
; Verwendete Konstante:
MaxX = 1024
MaxY = 768
; Befehle für den Code Bereich:
mov ax, DATEN ; Zeiger auf Datensegment
mov ds, ax
mov es, ax
mov di, OFFSET VINF ; Vesa-Bios-Analyse
mov ax, 4F00h ; es:di 256 byte
int 10h
cmp ax, 4Fh
jnz NOVESA ; FEHLER: wird nicht unterstützt
mov dl, [di+5] ; major version number of Vesa
cmp dl, 2 ; kleiner als Version 2 ?
jb NOVESA ; FEHLER: wird nicht unterstützt
lfs si, [di+0Eh] ; pointer of modelist VIDEOMODE SUCHEN
mov bx, OFFSET MODI
DEYU: mov ax, fs:[si] ; VESA modi herauscopieren
lea si, [si+2]
mov [bx], ax ; mode retten
lea bx, [bx+2]
cmp ax, 0FFFFh ; end of modelist ?
jnz DEYU
NIVE: mov si, OFFSET MODI ; Zeiger auf Vesa-Modi 80 Byte
NEVE: mov cx, [si] ; mode holen
lea si, [si+2]
cmp cx, 0FFFFh ; end of modelist ?
jz NOVESA ; FEHLER: wird nicht unterstützt
add cx, 4000h ; mode + linear acess
mov ax, 4F01h ; Modus-Spezifische Info holen
mov bp, cx ; mode retten
int 10h ; es:di 256 byte
cmp ax, 4Fh
jnz NOVESA ; FEHLER: wird nicht unterstützt
cmp WORD PTR[di+12h], MaxX
jnz NEVE
cmp WORD PTR[di+14h], MaxY
jnz NEVE
cmp BYTE PTR[di+19h], 20h ; 32 Bit per pixel?
jnz NEVE
and BYTE PTR[di], 80h ; linear access enable ?
jz NOVESA ; FEHLER: wird nicht unterstützt
cmp DWORD PTR[di+28h], 0 ; linearer Bild-Offset vorhanden ?
jz NOFSET ; FEHLER: linear wird nicht unterstützt
;--------------------------------------
cmp dl, 3 ; MONITOR-PARAMETER HOLEN
jnz VBEMODE ; Vesa 3 ?
lea bp, [bp+800h] ; modenummer + CRT
mov ax, 4F15h ; DDC - INSTALLATION CHECK
xor bl, bl
int 10h
cmp ax, 4Fh
jnz NODDC
mov ax, 4F15h ; DDC - READ EDID
mov bl, 1
xor cx, cx
xor dx, dx
mov di, OFFSET EDID ; es:di 128 byte
int 10h
cmp ax, 4Fh
jnz short NODDC
mov eax, 0FD000000h ; Text-identifier V/H range
mov bx, 36h
cmp eax, [di+bx] ; di+36h detailed timing #1
jz short DDCOK
lea bx, [bx+12h]
cmp eax, [di+bx] ; di+48h detailed timing #2
jz short DDCOK
lea bx, [bx+12h]
cmp eax, [di+bx] ; di+5Ah detailed timing #3
jz short DDCOK
lea bx, [bx+12h]
cmp eax, [di+bx] ; di+6Ch detailed timing #4
jnz short NODDC
DDCOK: mov al, [di+bx+6] ; MAXHZ
mov dl, [di+bx+8] ; MAXKHZ
cmp al, 90 ; 90hz
jb MONERR
cmp dl, 80 ; 80khz ?
jb MONERR
;------------------------------------
mov di, OFFSET CRTC
mov ecx, DWORD PTR[di+0Dh]
mov ax, 4F0Bh ; get/set Pixel-Clock
xor bl, bl ; 0=get
mov dx, bp ; Vesa-Modenummer
int 10h
cmp ax, 4Fh
jnz NOVESA ; FEHLER: Funktion nicht verfügbar
mov DWORD PTR[di+0Dh], ecx ; pixelclock
xor eax, eax ; RefreshRate berechnen aus CRT(?)
mov ax, [di] ; horizontal Total
xor ebx, ebx
mov bx, [di+6] ; vertikal Total
mul ebx
mov ebx, eax
mov eax, ecx ; Pixeltakt
mov esi, 10
xor edx, edx
div esi
xor edx, edx
div ebx
mov [di+11h], ax ; RefreshRate=Pixeltakt/(HTotal*Vtotal)
;--------------------------------------
VBEMODE: mov ax, 4F02h ; Vesa-Video-Mode einschalten
mov bx, bp ; Video_Mode mit linearen Zugriff
int 10h
cmp ax, 4Fh
jnz NOVESA ; FEHLER:Video-Mode nicht verfügbar
;--------------------------------------
mov di, OFFSET VINF ; Ziel-Offset
mov dx, [di+10h] ; Zeilen-Länge holen (Xmax*BytejePixel)
mov cx, [di+14h] ; Ymax
mov [XMAX], dx
mov [YMAX], cx
xor eax, eax
mov ax, DATEN ; Daten-Segment
xor ebx, ebx
mov bx, ax
mov eax, [di+28h] ; linearer Bild-Offset holen
shl ebx, 4 ; Daten-Segment in 32Bit-Offset wandeln
sub eax, ebx ; Bild-Offset:1.Bildzeile (ds:Reg32)
mov DWORD PTR[VIDADR], eax ; Lineare Video-Adresse retten
;-----------
; ---- Hier kann unsere Grafikausgabe beginnen --
; wir setzen einen Pixel links oben (Der Unrealmode muss an dieser Stelle schon angeschaltet sein.)
mov ebx, -1
mov [eax], ebx
; Textmode 3 anschalten und Anwendung beeenden
;----Programm Ende----
;------------------ Fehlermeldung ausgeben und sprung zum Beenden
NOVESA:
;------------------
NOFSET:
;------------------
NODDC:
;------------------
MONERR:
;----Subroutinen---
;--------------------------------------------------------------------------------------------------------------------------
; Daten für den Datenbereich; mit dieser Segmentadresse wird das DS und ES Segment-Register geladen
;--------------------------------------------------------------------------------------------------------------------------
VINF DB 200h dup (0AAh) ; Vesa-Info(4F00) + Mode-Info(4F01)
MODI DW 50h dup (0FFFFh) ; Vesa-Modi aus 4F00h di+0Eh ->pointer
;----------
CRTC DW 1456 ; horizontal Total in Pixel
HORIANF DW 1122 ; horizontal Sync-Start in Pixel
HORIEND DW 216 ; horizontal Sync-End in Pixel
VERTOTA DW 814 ; vertical Total in Lines
VERTANF DW 768 ; vertical Sync-Start in Lines
VERTEND DW 42 ; vertical Sync-End in Lines
DOIFLAG DB 04h ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 118309000 ; Pixel clock in hz
REFRATE DW 10000 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;----------
XMAX DW MaxX, 0
YMAX DW MaxY, 0
EDID DB 80h dup (55h) ; DDC-Moni-Info
VIDADR DD 0 ; Lineare Video-Adresse (ds:Reg32)
;---------------------------------
Die von mir verwendeten Dokumente kann man als "VESA PUBLIC STANDARDS" von "vesa.org" kostenlos herunterladen.
vbe3.pdf
EEDIDguideV1.pdf
EEDIDverifGuideRa.pdf
Seit Jahresbeginn funktionieren jedoch die alten direckten Links die man für die Dokumente auch mit Google finden konnte nicht mehr. Die VESA-Gruppe möchte es wohl lieber das man sich auch bei ihnen registriert wenn man die Dokumente herunterladen möchte. Wenn man sich dort registreirt hat, kommt man auch zu einer Seite wo gewünschte Doku zu finden sind, die aber nur solange man angemeldet ist auch erreichbar und abfrufbar bleiben. Danach funktionieren die Links nicht mehr.
(Das "vbe3.pdf" habe ich auch auf einer anderen Internetadresse mit Google gefunden, ich habe aber den Verdacht das der verantwortliche Admin für das dortigen Doku keine Verbreitungsrechte hat. Deshalb poste ich den Link dazu nicht.)
Startseite:
http://www.vesa.org/
Registrieren:
https://fs16.formsite.com/VESA/form7148 ... index.html
Abweichend von den oben verwendeten Vesamode mit 100hz und den dafür verwendeten Datenbereich der beginnend mit "CRTC" deklariert ist habe ich noch andere Parameter für verschieden andere Vesa-Modi.
(Leider bin ich noch nicht dazu gekommen die CRTC-Parameter via GTF selber zu berechnen. Zum Teil habe ich sie mir vom VBEHZ-Tool berechnen lassen, oder habe sie von einer Grafiktreiber-Ausgabe abgeschrieben.)
Wenn man die Werte etwas von "horizontal Total" z.B. erhöht/verringert verschiebt sich die Bildausgabe horizontal.
Code: Alles auswählen
;--------------------------------------
; 640x480x32 85 Hz
;--------------------------------------
CRTC DW 832 ; horizontal Total in Pixel
HORIANF DW 700 ; horizontal Sync-Start in Pixel
HORIEND DW 64 ; horizontal Sync-End in Pixel
VERTOTA DW 509 ; vertical Total in Lines
VERTANF DW 480 ; vertical Sync-Start in Lines
VERTEND DW 25 ; vertical Sync-End in Lines
DOIFLAG DB 0Ch ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 35993000 ; Pixel clock in hz
REFRATE DW 8499 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;--------------------------------------
; 640x480x32 120 Hz
;--------------------------------------
CRTC DW 848 ; horizontal Total in Pixel
HORIANF DW 680 ; horizontal Sync-Start in Pixel
HORIEND DW 88 ; horizontal Sync-End in Pixel
VERTOTA DW 515 ; vertical Total in Lines
VERTANF DW 480 ; vertical Sync-Start in Lines
VERTEND DW 31 ; vertical Sync-End in Lines
DOIFLAG DB 04h ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 52414000 ; Pixel clock in hz
REFRATE DW 12001 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;--------------------------------------
; 640x480x32 150 Hz
;--------------------------------------
CRTC DW 864 ; horizontal Total in Pixel
HORIANF DW 700 ; horizontal Sync-Start in Pixel
HORIEND DW 96 ; horizontal Sync-End in Pixel
VERTOTA DW 524 ; vertical Total in Lines
VERTANF DW 480 ; vertical Sync-Start in Lines
VERTEND DW 40 ; vertical Sync-End in Lines
DOIFLAG DB 04h ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 68010000 ; Pixel clock in hz
REFRATE DW 15021 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;--------------------------------------
; 640x480x32 160 Hz
;--------------------------------------
CRTC DW 864 ; horizontal Total in Pixel
HORIANF DW 700 ; horizontal Sync-Start in Pixel
HORIEND DW 112 ; horizontal Sync-End in Pixel
VERTOTA DW 527 ; vertical Total in Lines
VERTANF DW 480 ; vertical Sync-Start in Lines
VERTEND DW 43 ; vertical Sync-End in Lines
DOIFLAG DB 00h ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 72852000 ; Pixel clock in hz
REFRATE DW 16000 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;--------------------------------------
; 640x480 160 Hz VBEHZ-Tool
;--------------------------------------
CRTC DW 816 ; horizontal Total in Pixel
HORIANF DW 648 ; horizontal Sync-Start in Pixel
HORIEND DW 672 ; horizontal Sync-End in Pixel
VERTOTA DW 512 ; vertical Total in Lines
VERTANF DW 481 ; vertical Sync-Start in Lines
VERTEND DW 484 ; vertical Sync-End in Lines
DOIFLAG DB 00h ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 66846720 ; Pixel clock in hz
REFRATE DW 16000 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;--------------------------------------
; 800x600 75 Hz VBEHZ-Tool
;--------------------------------------
CRTC DW 1072 ; horizontal Total in Pixel
HORIANF DW 832 ; horizontal Sync-Start in Pixel
HORIEND DW 936 ; horizontal Sync-End in Pixel
VERTOTA DW 636 ; vertical Total in Lines
VERTANF DW 601 ; vertical Sync-Start in Lines
VERTEND DW 604 ; vertical Sync-End in Lines
DOIFLAG DB 00h ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 51134400 ; Pixel clock in hz
REFRATE DW 7500 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;--------------------------------------
; 800x600 85 Hz VBEHZ-Tool
;--------------------------------------
CRTC DW 1072 ; horizontal Total in Pixel
HORIANF DW 832 ; horizontal Sync-Start in Pixel
HORIEND DW 936 ; horizontal Sync-End in Pixel
VERTOTA DW 636 ; vertical Total in Lines
VERTANF DW 601 ; vertical Sync-Start in Lines
VERTEND DW 604 ; vertical Sync-End in Lines
DOIFLAG DB 00h ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 57952320 ; Pixel clock in hz
REFRATE DW 8500 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;--------------------------------------
; 800x600 100 Hz VBEHZ-Tool
;--------------------------------------
CRTC DW 1072 ; horizontal Total in Pixel
HORIANF DW 832 ; horizontal Sync-Start in Pixel
HORIEND DW 936 ; horizontal Sync-End in Pixel
VERTOTA DW 636 ; vertical Total in Lines
VERTANF DW 601 ; vertical Sync-Start in Lines
VERTEND DW 604 ; vertical Sync-End in Lines
DOIFLAG DB 00h ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 68179200 ; Pixel clock in hz
REFRATE DW 10000 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;--------------------------------------
; 800x600 120 Hz VBEHZ-Tool
;--------------------------------------
CRTC DW 1072 ; horizontal Total in Pixel
HORIANF DW 832 ; horizontal Sync-Start in Pixel
HORIEND DW 936 ; horizontal Sync-End in Pixel
VERTOTA DW 636 ; vertical Total in Lines
VERTANF DW 601 ; vertical Sync-Start in Lines
VERTEND DW 604 ; vertical Sync-End in Lines
DOIFLAG DB 00h ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 81815040 ; Pixel clock in hz
REFRATE DW 12000 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;--------------------------------------
; 800x600x32 140 Hz
;--------------------------------------
CRTC DW 1088 ; horizontal Total in Pixel
HORIANF DW 860 ; horizontal Sync-Start in Pixel
HORIEND DW 18 ; horizontal Sync-End in Pixel
VERTOTA DW 651 ; vertical Total in Lines
VERTANF DW 600 ; vertical Sync-Start in Lines
VERTEND DW 47 ; vertical Sync-End in Lines
DOIFLAG DB 04h ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 99160000 ; Pixel clock in hz
REFRATE DW 14000 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;--------------------------------------
; 800x600x32 144 Hz
;--------------------------------------
CRTC DW 1088 ; horizontal Total in Pixel
HORIANF DW 860 ; horizontal Sync-Start in Pixel
HORIEND DW 18 ; horizontal Sync-End in Pixel
VERTOTA DW 653 ; vertical Total in Lines
VERTANF DW 600 ; vertical Sync-Start in Lines
VERTEND DW 47 ; vertical Sync-End in Lines
DOIFLAG DB 04h ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 102271000 ; Pixel clock in hz
REFRATE DW 14394 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;--------------------------------------
; 800x600 150 Hz VBEHZ-Tool
;--------------------------------------
CRTC DW 1072 ; horizontal Total in Pixel
HORIANF DW 832 ; horizontal Sync-Start in Pixel
HORIEND DW 936 ; horizontal Sync-End in Pixel
VERTOTA DW 636 ; vertical Total in Lines
VERTANF DW 601 ; vertical Sync-Start in Lines
VERTEND DW 604 ; vertical Sync-End in Lines
DOIFLAG DB 00h ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 102268800 ; Pixel clock in hz
REFRATE DW 15000 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;--------------------------------------
; 800x600 160 Hz VBEHZ-Tool
;--------------------------------------
CRTC DW 1072 ; horizontal Total in Pixel
HORIANF DW 832 ; horizontal Sync-Start in Pixel
HORIEND DW 936 ; horizontal Sync-End in Pixel
VERTOTA DW 636 ; vertical Total in Lines
VERTANF DW 601 ; vertical Sync-Start in Lines
VERTEND DW 604 ; vertical Sync-End in Lines
DOIFLAG DB 00h ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 109086720 ; Pixel clock in hz
REFRATE DW 16000 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;--------------------------------------
; 1024x768x32 100 Hz
;--------------------------------------
CRTC DW 1456 ; horizontal Total in Pixel
HORIANF DW 1122 ; horizontal Sync-Start in Pixel
HORIEND DW 216 ; horizontal Sync-End in Pixel
VERTOTA DW 814 ; vertical Total in Lines
VERTANF DW 768 ; vertical Sync-Start in Lines
VERTEND DW 42 ; vertical Sync-End in Lines
DOIFLAG DB 04h ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 118309000 ; Pixel clock in hz
REFRATE DW 10000 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;--------------------------------------
; 1024x768 120 Hz VBEHZ-Tool
;--------------------------------------
CRTC DW 1392 ; horizontal Total in Pixel
HORIANF DW 1096 ; horizontal Sync-Start in Pixel
HORIEND DW 1208 ; horizontal Sync-End in Pixel
VERTOTA DW 814 ; vertical Total in Lines
VERTANF DW 769 ; vertical Sync-Start in Lines
VERTEND DW 772 ; vertical Sync-End in Lines
DOIFLAG DB 00h ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 135970560 ; Pixel clock in hz
REFRATE DW 12000 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;--------------------------------------
; 1024x768 160 Hz VBEHZ-Tool
;--------------------------------------
CRTC DW 1392 ; horizontal Total in Pixel
HORIANF DW 1096 ; horizontal Sync-Start in Pixel
HORIEND DW 1208 ; horizontal Sync-End in Pixel
VERTOTA DW 814 ; vertical Total in Lines
VERTANF DW 769 ; vertical Sync-Start in Lines
VERTEND DW 772 ; vertical Sync-End in Lines
DOIFLAG DB 00h ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 181294080 ; Pixel clock in hz
REFRATE DW 16000 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;--------------------------------------
; 1152x864 70 Hz VBEHZ-Tool
;-------------------------------------
CRTC DW 1552 ; horizontal Total in Pixel
HORIANF DW 1224 ; horizontal Sync-Start in Pixel
HORIEND DW 1352 ; horizontal Sync-End in Pixel
VERTOTA DW 907 ; vertical Total in Lines
VERTANF DW 865 ; vertical Sync-Start in Lines
VERTEND DW 868 ; vertical Sync-End in Lines
DOIFLAG DB 0 ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 98536480 ; Pixel clock in hz
REFRATE DW 7000 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;--------------------------------------
; 1152x864 85 Hz VBEHZ-Tool
;-------------------------------------
CRTC DW 1552 ; horizontal Total in Pixel
HORIANF DW 1224 ; horizontal Sync-Start in Pixel
HORIEND DW 1352 ; horizontal Sync-End in Pixel
VERTOTA DW 907 ; vertical Total in Lines
VERTANF DW 865 ; vertical Sync-Start in Lines
VERTEND DW 868 ; vertical Sync-End in Lines
DOIFLAG DB 0 ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 119651440 ; Pixel clock in hz
REFRATE DW 8500 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;--------------------------------------
; 1152x864 100 Hz VBEHZ-Tool
;-------------------------------------
CRTC DW 1552 ; horizontal Total in Pixel
HORIANF DW 1224 ; horizontal Sync-Start in Pixel
HORIEND DW 1352 ; horizontal Sync-End in Pixel
VERTOTA DW 907 ; vertical Total in Lines
VERTANF DW 865 ; vertical Sync-Start in Lines
VERTEND DW 868 ; vertical Sync-End in Lines
DOIFLAG DB 0 ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 140766400 ; Pixel clock in hz
REFRATE DW 10000 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;--------------------------------------
; 1152x864 120 Hz VBEHZ-Tool
;-------------------------------------
CRTC DW 1552 ; horizontal Total in Pixel
HORIANF DW 1224 ; horizontal Sync-Start in Pixel
HORIEND DW 1352 ; horizontal Sync-End in Pixel
VERTOTA DW 907 ; vertical Total in Lines
VERTANF DW 865 ; vertical Sync-Start in Lines
VERTEND DW 868 ; vertical Sync-End in Lines
DOIFLAG DB 0 ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 168919680 ; Pixel clock in hz
REFRATE DW 12000 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;--------------------------------------
; 1152x864 150 Hz VBEHZ-Tool
;-------------------------------------
CRTC DW 1552 ; horizontal Total in Pixel
HORIANF DW 1224 ; horizontal Sync-Start in Pixel
HORIEND DW 1352 ; horizontal Sync-End in Pixel
VERTOTA DW 907 ; vertical Total in Lines
VERTANF DW 865 ; vertical Sync-Start in Lines
VERTEND DW 868 ; vertical Sync-End in Lines
DOIFLAG DB 0 ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 211149600 ; Pixel clock in hz
REFRATE DW 15000 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;--------------------------------------
; 1280x1024x8 85 Hz
;-------------------------------------
CRTC DW 1728 ; horizontal Total in Pixel
HORIANF DW 1336 ; horizontal Sync-Start in Pixel
HORIEND DW 208 ; horizontal Sync-End in Pixel
VERTOTA DW 1072 ; vertical Total in Lines
VERTANF DW 1024 ; vertical Sync-Start in Lines
VERTEND DW 44 ; vertical Sync-End in Lines
DOIFLAG DB 0 ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 157498000 ; Pixel clock in hz
REFRATE DW 8502 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;--------------------------------------
; 1280x1024 120 Hz VBEHZ-Tool
;--------------------------------------
CRTC DW 1728 ; horizontal Total in Pixel
HORIANF DW 1352 ; horizontal Sync-Start in Pixel
HORIEND DW 1504 ; horizontal Sync-End in Pixel
VERTOTA DW 1066 ; vertical Total in Lines
VERTANF DW 1025 ; vertical Sync-Start in Lines
VERTEND DW 1028 ; vertical Sync-End in Lines
DOIFLAG DB 00h ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 221045760 ; Pixel clock in hz
REFRATE DW 12000 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;--------------------------------------
; 1280x1024 130 Hz VBEHZ-Tool
;--------------------------------------
CRTC DW 1728 ; horizontal Total in Pixel
HORIANF DW 1352 ; horizontal Sync-Start in Pixel
HORIEND DW 1504 ; horizontal Sync-End in Pixel
VERTOTA DW 1066 ; vertical Total in Lines
VERTANF DW 1025 ; vertical Sync-Start in Lines
VERTEND DW 1028 ; vertical Sync-End in Lines
DOIFLAG DB 00h ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 238453113 ; Pixel clock in hz
REFRATE DW 12945 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;--------------------------------------
; 1600x1200x8 72 Hz
;--------------------------------------
CRTC DW 2176 ; horizontal Total in Pixel
HORIANF DW 1808 ; horizontal Sync-Start in Pixel
HORIEND DW 272 ; horizontal Sync-End in Pixel
VERTOTA DW 1251 ; vertical Total in Lines
VERTANF DW 1200 ; vertical Sync-Start in Lines
VERTEND DW 47 ; vertical Sync-End in Lines
DOIFLAG DB 04h ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 195977000 ; Pixel clock in hz
REFRATE DW 7199 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;--------------------------------------
; 1600x1200x16 72 Hz
;--------------------------------------
CRTC DW 2176 ; horizontal Total in Pixel
HORIANF DW 1728 ; horizontal Sync-Start in Pixel
HORIEND DW 272 ; horizontal Sync-End in Pixel
VERTOTA DW 1251 ; vertical Total in Lines
VERTANF DW 1200 ; vertical Sync-Start in Lines
VERTEND DW 47 ; vertical Sync-End in Lines
DOIFLAG DB 04h ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 195977000 ; Pixel clock in hz
REFRATE DW 7199 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;--------------------------------------
; 1600x1200 85 Hz VBEHZ-Tool
;--------------------------------------
CRTC DW 2160 ; horizontal Total in Pixel
HORIANF DW 1688 ; horizontal Sync-Start in Pixel
HORIEND DW 1824 ; horizontal Sync-End in Pixel
VERTOTA DW 1242 ; vertical Total in Lines
VERTANF DW 1201 ; vertical Sync-Start in Lines
VERTEND DW 1206 ; vertical Sync-End in Lines
DOIFLAG DB 00h ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 228031200 ; Pixel clock in hz
REFRATE DW 8500 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;--------------------------------------
; 1600x1200 100 Hz VBEHZ-Tool
;--------------------------------------
CRTC DW 2160 ; horizontal Total in Pixel
HORIANF DW 1688 ; horizontal Sync-Start in Pixel
HORIEND DW 1824 ; horizontal Sync-End in Pixel
VERTOTA DW 1242 ; vertical Total in Lines
VERTANF DW 1201 ; vertical Sync-Start in Lines
VERTEND DW 1206 ; vertical Sync-End in Lines
DOIFLAG DB 00h ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 268272000 ; Pixel clock in hz
REFRATE DW 10000 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;--------------------------------------
; 1600x1200 110 Hz VBEHZ-Tool
;--------------------------------------
CRTC DW 2160 ; horizontal Total in Pixel
HORIANF DW 1688 ; horizontal Sync-Start in Pixel
HORIEND DW 1824 ; horizontal Sync-End in Pixel
VERTOTA DW 1242 ; vertical Total in Lines
VERTANF DW 1201 ; vertical Sync-Start in Lines
VERTEND DW 1206 ; vertical Sync-End in Lines
DOIFLAG DB 00h ; Flag (interlaced,doubleScan,polarity)
PIXCLOC DD 298077019 ; Pixel clock in hz
REFRATE DW 11111 ; Refresh-Rate in 0.01 hz
DB 40 dup (0)
;--------------------------------------
Dirk
Zuletzt geändert von freecrac am Mo 20. Sep 2010, 20:47, insgesamt 3-mal geändert.
Re: Probleme mit VESA auf neuen Rechnern.
Betreffend den "Unrealmode" aka "4G-Mode" aka "Real Huge Mode" aka "wasnichsonstnochalles"... meinen wir wohl beide dasselbe.
Ich benutze halt im normalen 16bit ("Real Mode") auch 32bit Bit Register und die erweiterten Segment-Register (FS,GS), also 32bit Daten, aber nur 16bit Adressen.
Und um den "Unrealmode" zu erreichen, schaltet man eben kurz in den 32bit Mode ("Protected Mode"), ändert die Grenzen der Segmente von 16bit ($FFFF) auf 32bit ($FFFFFFFF) und schaltet wieder zurück in den 16bit Mode ("Real Mode"). Und damit kann man eben direkt auf Adressen-Offsets bis 4GB zugreifen, statt wie vorher nur auf Offsets bis 64kB.
Was die Bankumschaltung beim Pixelsetzen/Grafikzeichnen angeht: Ich merke mir die zuletzt benutzte Bank extern und schalte die Bank nur dann um, wenn die oberen Bits der Adresse nicht mehr der gemerkten Bank entsprechen. Ich gehe bei der Programmierung immer von 64kB Banken aus (habe noch keine Grafikkarte mit kleineren Banken erlebt - ich denke, auf denen werden sowieso auch keine gescheiten VESA-Modi möglich sein) und brauche dazu also nur das HighWord der Adresse mit der entsprechend gemerkten Bank-Nr vergleichen. Außerdem generiere ich Grafiken so, daß ich nicht ständig die Bank testen muß - will sagen: bei vielen Dingen benutze ich spezielle Routinen, um etwas zu "zeichnen" (und nutze den Vorteil, daß Pixel in der Grafikkarte an neben- bzw untereinanderliegenden Adressen liegen) d.h. ich zeichne nicht jede Grafik, indem ich tausende Male eine generalisierte Pixelsubroutine mit den entsprechenden Koordinaten aufrufe.
Aber OK - genug davon. Das gehört ja gar nicht mehr zum Thema.
Sollte ich jemals den Unrealmode benutzen wollen, komme ich auf die entsprechenden Codebeispiele zurück.
Ich benutze halt im normalen 16bit ("Real Mode") auch 32bit Bit Register und die erweiterten Segment-Register (FS,GS), also 32bit Daten, aber nur 16bit Adressen.
Und um den "Unrealmode" zu erreichen, schaltet man eben kurz in den 32bit Mode ("Protected Mode"), ändert die Grenzen der Segmente von 16bit ($FFFF) auf 32bit ($FFFFFFFF) und schaltet wieder zurück in den 16bit Mode ("Real Mode"). Und damit kann man eben direkt auf Adressen-Offsets bis 4GB zugreifen, statt wie vorher nur auf Offsets bis 64kB.
Was die Bankumschaltung beim Pixelsetzen/Grafikzeichnen angeht: Ich merke mir die zuletzt benutzte Bank extern und schalte die Bank nur dann um, wenn die oberen Bits der Adresse nicht mehr der gemerkten Bank entsprechen. Ich gehe bei der Programmierung immer von 64kB Banken aus (habe noch keine Grafikkarte mit kleineren Banken erlebt - ich denke, auf denen werden sowieso auch keine gescheiten VESA-Modi möglich sein) und brauche dazu also nur das HighWord der Adresse mit der entsprechend gemerkten Bank-Nr vergleichen. Außerdem generiere ich Grafiken so, daß ich nicht ständig die Bank testen muß - will sagen: bei vielen Dingen benutze ich spezielle Routinen, um etwas zu "zeichnen" (und nutze den Vorteil, daß Pixel in der Grafikkarte an neben- bzw untereinanderliegenden Adressen liegen) d.h. ich zeichne nicht jede Grafik, indem ich tausende Male eine generalisierte Pixelsubroutine mit den entsprechenden Koordinaten aufrufe.
Aber OK - genug davon. Das gehört ja gar nicht mehr zum Thema.
Sollte ich jemals den Unrealmode benutzen wollen, komme ich auf die entsprechenden Codebeispiele zurück.
Re: Probleme mit VESA auf neuen Rechnern.
Fast richtig, nur der Protected Mode ist nicht automatisch im 32bit (Adress-)Mode, ich schalte in den PM und bleibe im 16-bit (Adress-)Mode. Überwiegend wird der PM zusammen mit dem 32bit (Adress-)Mode genutzt und der RM zusammen mit dem 16-bit (Adress-)Mode. Aber es geht auch andersherum. Der RM kann auch im 32bit (Adress-)Mode betrieben werden, nur kann man dann kein BIOS und DOS mehr nutzen, da beides für den 16-bit (Adress-)Mode entwickelt wurde. Auch kann man den PM zusammen mit dem 16-bit (Adress-)Mode nutzen, nur dann muss jeweils ein Size-Prefix vor den Opcode stehen um 32Bit-Operanden/Register/Adressen benutzen zu können. Da man aber im PM sehr oft 32Bit verwenden möchte und diese Prefixe den Code einer Anwendung aufblähen, ist es zweckmäßig im PM den 32bit (Adress-)Mode zu verwenden. Mit dem zu adressierenden Adressraum hat das überhaupt nichts zu tun. Es ist ein weitverbreiteter Irrtum zu glauben das der 32Bit-Adressmode mit der Segmentlänge etwas zu tun hat und selbst manche Windows/Linux-Programmierer irren sich hierbei, da sie vermutlich selber noch nie in den PM geschaltet haben und lediglich das verwendete OS für ihre Anwendungen benutzen. Woher diese Fehlinformation kam die dann verbreitet wurde weiss ich auch nicht. Fakt ist jedoch das es bei den 16/32-Bit Adressmode nur darum geht wie die jeweiligen Size-Prefixe von der CPU interpretiert und verarbeitet werden.DOSferatu hat geschrieben:Betreffend den "Unrealmode" aka "4G-Mode" aka "Real Huge Mode" aka "wasnichsonstnochalles"... meinen wir wohl beide dasselbe.
Ich benutze halt im normalen 16bit ("Real Mode") auch 32bit Bit Register und die erweiterten Segment-Register (FS,GS), also 32bit Daten, aber nur 16bit Adressen.
Und um den "Unrealmode" zu erreichen, schaltet man eben kurz in den 32bit Mode ("Protected Mode"), ändert die Grenzen der Segmente von 16bit ($FFFF) auf 32bit ($FFFFFFFF) und schaltet wieder zurück in den 16bit Mode ("Real Mode"). Und damit kann man eben direkt auf Adressen-Offsets bis 4GB zugreifen, statt wie vorher nur auf Offsets bis 64kB.
Ich habe es mit Modi mit Bankumschaltung seit der ET4000 auch so gemacht. Als es dann Modi mit linearen Framebuffer gab war ich sehr froh darüber das ich die Bankumschaltung endlich nicht mehr zwingend benutzen muss.Was die Bankumschaltung beim Pixelsetzen/Grafikzeichnen angeht: Ich merke mir die zuletzt benutzte Bank extern und schalte die Bank nur dann um, wenn die oberen Bits der Adresse nicht mehr der gemerkten Bank entsprechen. Ich gehe bei der Programmierung immer von 64kB Banken aus (habe noch keine Grafikkarte mit kleineren Banken erlebt - ich denke, auf denen werden sowieso auch keine gescheiten VESA-Modi möglich sein) und brauche dazu also nur das HighWord der Adresse mit der entsprechend gemerkten Bank-Nr vergleichen. Außerdem generiere ich Grafiken so, daß ich nicht ständig die Bank testen muß - will sagen: bei vielen Dingen benutze ich spezielle Routinen, um etwas zu "zeichnen" (und nutze den Vorteil, daß Pixel in der Grafikkarte an neben- bzw untereinanderliegenden Adressen liegen) d.h. ich zeichne nicht jede Grafik, indem ich tausende Male eine generalisierte Pixelsubroutine mit den entsprechenden Koordinaten aufrufe.
Mir ist aufgefallen das wenn ich einen Mode mit linearen Framebuffer benutze auch der Bereich in 0A000:0h mit dem selben Bild-Inhalt gefüllt war. Auch war bisher die lineare Adresse vom Anfang des Framebuffer bei allen Modi immer gleich.
Aber darauf würde ich mich nicht verlassen und es ist daher ratsam für jeden Mode die Adresse via Modeinfo sich zu holen.
Ich habe den betreffenden Code für den Unrealmode so klein gehalten wie mir möglich war und ich hoffe das es damit möglich ist diesen Part in eigene Anwendung zu integrieren. Wenn es dazu noch irgendwelche Fragen gibt kann ich gerne jedes Dateil noch etwas genauer erklären.Aber OK - genug davon. Das gehört ja gar nicht mehr zum Thema.
Sollte ich jemals den Unrealmode benutzen wollen, komme ich auf die entsprechenden Codebeispiele zurück.
Dirk
Re: Probleme mit VESA auf neuen Rechnern.
Ja, wie gesagt, ich bin mir ja dessen bewußt.freecrac hat geschrieben:Fast richtig, nur der Protected Mode ist nicht automatisch im 32bit (Adress-)Mode, ich schalte in den PM und bleibe im 16-bit (Adress-)Mode. Überwiegend wird der PM zusammen mit dem 32bit (Adress-)Mode genutzt und der RM zusammen mit dem 16-bit (Adress-)Mode. Aber es geht auch andersherum. Der RM kann auch im 32bit (Adress-)Mode betrieben werden, nur kann man dann kein BIOS und DOS mehr nutzen, da beides für den 16-bit (Adress-)Mode entwickelt wurde. Auch kann man den PM zusammen mit dem 16-bit (Adress-)Mode nutzen, nur dann muss jeweils ein Size-Prefix vor den Opcode stehen um 32Bit-Operanden/Register/Adressen benutzen zu können. Da man aber im PM sehr oft 32Bit verwenden möchte und diese Prefixe den Code einer Anwendung aufblähen, ist es zweckmäßig im PM den 32bit (Adress-)Mode zu verwenden. Mit dem zu adressierenden Adressraum hat das überhaupt nichts zu tun. Es ist ein weitverbreiteter Irrtum zu glauben das der 32Bit-Adressmode mit der Segmentlänge etwas zu tun hat und selbst manche Windows/Linux-Programmierer irren sich hierbei, da sie vermutlich selber noch nie in den PM geschaltet haben und lediglich das verwendete OS für ihre Anwendungen benutzen. Woher diese Fehlinformation kam die dann verbreitet wurde weiss ich auch nicht. Fakt ist jedoch das es bei den 16/32-Bit Adressmode nur darum geht wie die jeweiligen Size-Prefixe von der CPU interpretiert und verarbeitet werden.
Im 16Bit-Mode:
ohne Präfix $66: 16bit Daten - mit Präfix $66: 32bit Daten (Register, etc)
ohne Präfix $67: 16bit Offsets - mit Präfix $67: 32bit Offsets [ABER! Wenn kein "UnrealMode", funktioniert das hier nicht!]
Im 32bit-Mode:
ohne Präfix $66: 32bit Daten - mit Präfix $66: 16bit Daten (Register, etc)
ohne Präfix $67: 32bit Offsets - mit Präfix $67: 16bit Offsets
D.h. die Präfixe $66 (für Datenbreite) und $67 (für Offset (also Adressen))Breite haben im 32bit Mode eine genau entgegengesetzte Funktion. Und zusätzlich kann man aber auch den "Protected Mode" so schalten, daß er die Präfixe wie im 16bit Mode behandelt. (Habe mich mal eine Weile theoretisch mit PM beschäftigt und mit der GDT.)
Wie die Präfixe im Unreal-Mode funktionieren, weiß ich nicht - es kommt wohl darauf an, ob man ihn "16bit-mäßig" oder "32bit-mäßig" einstellt.
Was ich damit sagen will, ist einfach nur: Würde das Präfix $67 im 16bit Mode (normaler "Real Mode") gleich die Offsets auf 32bit setzen, bräuchte man ja nicht den Trick mit dem "UnrealMode" machen. Der ist ja nur dazu da, damit die "Maske" für die Offsets von $FFFF auf $FFFFFFFF erweitert werden. Und ja, ich weiß, man kann diese Maske beliebig setzen, man kann auch kleinere Bereiche (Offsets) erlauben. Die Offsets "wrappen" halt an der gesetzten Grenze.
Für Zugriffe auf den Speicher über 1MB benutze ich übrigens HIMEM.SYS. Ja, ich weiß, das ist die langsamere Methode gegenüber dem "UnrealMode"...
Re: Probleme mit VESA auf neuen Rechnern.
Ja genau! Die Adressen bilden sich im RM, so wie auch im Unrealmode jeweils über ein 16Bit-Segmentregister plus ein 16Bit oder 32Bit-Offset(Register/Adresse) und nach dem Anschalten des Rechners sind alle Segmente auf 64KB begrenzt und die 21. Adressleitungen ist auch noch nicht angeschaltet. Bei einem 32Bit-Offsetregister wird im RM der Inhalt vom High-Word(obersten 16Bit) ignoriert und beim Unrealmode für die Adressbildung verwendet.DOSferatu hat geschrieben: Ja, wie gesagt, ich bin mir ja dessen bewußt.
Im 16Bit-Mode:
ohne Präfix $66: 16bit Daten - mit Präfix $66: 32bit Daten (Register, etc)
ohne Präfix $67: 16bit Offsets - mit Präfix $67: 32bit Offsets [ABER! Wenn kein "UnrealMode", funktioniert das hier nicht!]
Im 32bit-Mode:
ohne Präfix $66: 32bit Daten - mit Präfix $66: 16bit Daten (Register, etc)
ohne Präfix $67: 32bit Offsets - mit Präfix $67: 16bit Offsets
D.h. die Präfixe $66 (für Datenbreite) und $67 (für Offset (also Adressen))Breite haben im 32bit Mode eine genau entgegengesetzte Funktion. Und zusätzlich kann man aber auch den "Protected Mode" so schalten, daß er die Präfixe wie im 16bit Mode behandelt. (Habe mich mal eine Weile theoretisch mit PM beschäftigt und mit der GDT.)
Wie die Präfixe im Unreal-Mode funktionieren, weiß ich nicht - es kommt wohl darauf an, ob man ihn "16bit-mäßig" oder "32bit-mäßig" einstellt.
Was ich damit sagen will, ist einfach nur: Würde das Präfix $67 im 16bit Mode (normaler "Real Mode") gleich die Offsets auf 32bit setzen, bräuchte man ja nicht den Trick mit dem "UnrealMode" machen. Der ist ja nur dazu da, damit die "Maske" für die Offsets von $FFFF auf $FFFFFFFF erweitert werden. Und ja, ich weiß, man kann diese Maske beliebig setzen, man kann auch kleinere Bereiche (Offsets) erlauben. Die Offsets "wrappen" halt an der gesetzten Grenze.
Für Zugriffe auf den Speicher über 1MB benutze ich übrigens HIMEM.SYS. Ja, ich weiß, das ist die langsamere Methode gegenüber dem "UnrealMode"...
Gibt es ein HIMEM.SYS das mehr als 64MB XMS verwaltet?
Dirk
Re: Probleme mit VESA auf neuen Rechnern.
Ja, HIMEM.SYS ab Version 3.0 hat zusätzliche Funktionen. D.h. die normalen 16bit-Funktionen von vorher gibt es auch noch. Da man bei der nur mit Word-Registern arbeiten konnte und man bei HIMEM.SYS immer in 1kB-Schritten Speicher belegen kann, kann man halt maximal 65535 kB (also wie bewußten knapp 64 MB) belegen. Ist glaub Funktion 08h.freecrac hat geschrieben:Gibt es ein HIMEM.SYS das mehr als 64MB XMS verwaltet?
Die Version 3.0 hat zusätzliche Funktionen, die den normalen Funktionen plus 80h entsprechen, also z.B. 88h. Diese sind für 32bit Register ausgelegt und man kann also auch in 32bit Größen alles angeben. (Natürlich kann man effektiv nicht 4294967295 kB belegen, das wären ja 4 TB, sondern natürlich nur maximal 4 GB - klar, bei 32bit-Mode.)
EIgentlich ist das auch in der RBIL zu finden. Die Pascal-Unit, die ich mir für "XMS" geschrieben hab (und die größtenteils aus ASM besteht, aber mit Prozedurköpfen in Pascal) prüft halt, ob die HIMEM.SYS Version >=3 ist und wenn ja, benutzt es die 32bit-Variante, sonst die 16bit-Variante der vorigen Versionen.
Ich selbst benutze HIMEM.SYS 3.0. Dachte, daß die mittlerweile sowieso alle haben.
Re: Probleme mit VESA auf neuen Rechnern.
Oh, ohne wirklich zu wissen was diese Version verwalten kann habe ich nun mal in das von mir verwendete Himem.sys hineingeschaut und musste festellen das ich Version 3.10 benutze. Damit können meine Anwendungen für den Unrealmode dieDOSferatu hat geschrieben:Ja, HIMEM.SYS ab Version 3.0 hat zusätzliche Funktionen. D.h. die normalen 16bit-Funktionen von vorher gibt es auch noch. Da man bei der nur mit Word-Registern arbeiten konnte und man bei HIMEM.SYS immer in 1kB-Schritten Speicher belegen kann, kann man halt maximal 65535 kB (also wie bewußten knapp 64 MB) belegen. Ist glaub Funktion 08h.freecrac hat geschrieben:Gibt es ein HIMEM.SYS das mehr als 64MB XMS verwaltet?
Die Version 3.0 hat zusätzliche Funktionen, die den normalen Funktionen plus 80h entsprechen, also z.B. 88h. Diese sind für 32bit Register ausgelegt und man kann also auch in 32bit Größen alles angeben. (Natürlich kann man effektiv nicht 4294967295 kB belegen, das wären ja 4 TB, sondern natürlich nur maximal 4 GB - klar, bei 32bit-Mode.)
EIgentlich ist das auch in der RBIL zu finden. Die Pascal-Unit, die ich mir für "XMS" geschrieben hab (und die größtenteils aus ASM besteht, aber mit Prozedurköpfen in Pascal) prüft halt, ob die HIMEM.SYS Version >=3 ist und wenn ja, benutzt es die 32bit-Variante, sonst die 16bit-Variante der vorigen Versionen.
Ich selbst benutze HIMEM.SYS 3.0. Dachte, daß die mittlerweile sowieso alle haben.
ebenfalls den oberen Speicher verwalten natürlich kollidieren wenn merhr als 64MB XMS angefordert wurde.
http://de.wikipedia.org/wiki/Himem.sys
"Mit MS-DOS 7.0 (Windows 95) wurde diese Beschränkung dann auf 256 MB angehoben. Mit MS-DOS 7.1 (Windows 98) wurden diese Beschränkungen weiter erhöht: DOS kann bis zu 4 GB korrekt verwalten."
(Soll wohl bedeuten das die Beschränkungen weiter herabgesetzt und die verwendbare Speichermenge erhöht wurde.)
Danke für die Info, man lernt ja immer wieder etwas dazu.
Dirk