Probleme mit VESA auf neuen Rechnern.

Probleme mit VESA auf neuen Rechnern.

Beitragvon DOSferatu » Do 11. Sep 2008, 20:56

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)...
DOSferatu
DOS-Übermensch
 
Beiträge: 1095
Registriert: Di 25. Sep 2007, 11:05

Beitragvon Dosenware » Do 11. Sep 2008, 22:21

manche Karten nutzen afair nur 32kb im Blankedmode...

kannst du den delinquenten mal online stellen? wuerde gern mal schauen was mein Wind dazu sagt...
Benutzeravatar
Dosenware
DOS-Gott
 
Beiträge: 3529
Registriert: Mi 24. Mai 2006, 19:29

Beitragvon DOSferatu » Fr 12. Sep 2008, 02:03

Dosenware hat geschrieben:manche Karten nutzen afair nur 32kb im Blankedmode...

Das sind nur sehr alte Karten (bevor es VESA gab und die dann mit UniVBE geVESAt wurden), die neuen haben alle 64k.
Außerdem meldet VESA auch 64kB Bankgröße. (Hab mal so Testprogramm dafür gemacht, das alles über VESA meldet.)

Dosenware hat geschrieben:kannst du den delinquenten mal online stellen? wuerde gern mal schauen was mein Wind dazu sagt...

Nö, lieber nicht. Ist ein Programm in ganz frühem Anfangsstadium. Will ich ungern jetzt schon rausgeben.
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...
DOSferatu
DOS-Übermensch
 
Beiträge: 1095
Registriert: Di 25. Sep 2007, 11:05

Beitragvon elianda » Fr 12. Sep 2008, 12:37

Ist das Problem auch bei Duke3D unter 800x600 vorhanden?
Diverse Retro-Computer vorhanden.
elianda
DOS-Übermensch
 
Beiträge: 1140
Registriert: Mi 31. Jan 2007, 19:04
Wohnort: Halle

Beitragvon DOSferatu » Mo 15. Sep 2008, 14:46

elianda hat geschrieben:Ist das Problem auch bei Duke3D unter 800x600 vorhanden?

Entschuldiung, daß ich jetzt erst antworte- Ich war so beschäftigt...
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...)
DOSferatu
DOS-Übermensch
 
Beiträge: 1095
Registriert: Di 25. Sep 2007, 11:05

Re: Probleme mit VESA auf neuen Rechnern.

Beitragvon freecrac » Mi 21. Apr 2010, 23:36

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).


Auch mit dem 16 Bit-Adressmode(im Protectmode oder dem Unrealmode/Bigrealmode) kann man den gesamten 4GB-Adressraum adressieren.

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, 15:41, insgesamt 2-mal geändert.
freecrac
DOS-Guru
 
Beiträge: 861
Registriert: Mi 21. Apr 2010, 10:44
Wohnort: Hamburg Horn

Re: Probleme mit VESA auf neuen Rechnern.

Beitragvon DOSferatu » Mi 21. Apr 2010, 23:58

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?
DOSferatu
DOS-Übermensch
 
Beiträge: 1095
Registriert: Di 25. Sep 2007, 11:05

Re: Probleme mit VESA auf neuen Rechnern.

Beitragvon freecrac » Do 22. Apr 2010, 12:13

DOSferatu 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").

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ück
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.

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.

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 nicht
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


Siehe dazu auch meinen Beitrag in der Newsgroup "de.comp.os.msdos":
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:
viewtopic.php?f=15&t=78&p=15190#p15190

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...

Zusammen mit Windows oder auch im V86-Mode vom emm386 oder vergleichbaren Memmorymanager kann man den Unrealmode nicht verwenden.

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.

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ürlich
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.

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"...

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.
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.

@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?

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.
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, 11:40, insgesamt 5-mal geändert.
freecrac
DOS-Guru
 
Beiträge: 861
Registriert: Mi 21. Apr 2010, 10:44
Wohnort: Hamburg Horn

Re: Probleme mit VESA auf neuen Rechnern.

Beitragvon freecrac » Do 22. Apr 2010, 14:35

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.
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)
;---------------------------------

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=15&t=2921&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.
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)
;--------------------------------------


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
Zuletzt geändert von freecrac am Mo 20. Sep 2010, 19:47, insgesamt 3-mal geändert.
freecrac
DOS-Guru
 
Beiträge: 861
Registriert: Mi 21. Apr 2010, 10:44
Wohnort: Hamburg Horn

Re: Probleme mit VESA auf neuen Rechnern.

Beitragvon DOSferatu » Do 22. Apr 2010, 20:38

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.
DOSferatu
DOS-Übermensch
 
Beiträge: 1095
Registriert: Di 25. Sep 2007, 11:05

Re: Probleme mit VESA auf neuen Rechnern.

Beitragvon freecrac » Fr 23. Apr 2010, 08:35

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.


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.

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.


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.

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.

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 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.

Dirk
freecrac
DOS-Guru
 
Beiträge: 861
Registriert: Mi 21. Apr 2010, 10:44
Wohnort: Hamburg Horn

Re: Probleme mit VESA auf neuen Rechnern.

Beitragvon DOSferatu » Fr 23. Apr 2010, 11:19

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.


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"...
DOSferatu
DOS-Übermensch
 
Beiträge: 1095
Registriert: Di 25. Sep 2007, 11:05

Re: Probleme mit VESA auf neuen Rechnern.

Beitragvon freecrac » Fr 23. Apr 2010, 13:11

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"...


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.

Gibt es ein HIMEM.SYS das mehr als 64MB XMS verwaltet?

Dirk
freecrac
DOS-Guru
 
Beiträge: 861
Registriert: Mi 21. Apr 2010, 10:44
Wohnort: Hamburg Horn

Re: Probleme mit VESA auf neuen Rechnern.

Beitragvon DOSferatu » So 25. Apr 2010, 22:52

freecrac hat geschrieben:Gibt es ein HIMEM.SYS das mehr als 64MB XMS verwaltet?


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.

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.
DOSferatu
DOS-Übermensch
 
Beiträge: 1095
Registriert: Di 25. Sep 2007, 11:05

Re: Probleme mit VESA auf neuen Rechnern.

Beitragvon freecrac » Mo 26. Apr 2010, 06:50

DOSferatu hat geschrieben:
freecrac hat geschrieben:Gibt es ein HIMEM.SYS das mehr als 64MB XMS verwaltet?


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.

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.


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 die
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
freecrac
DOS-Guru
 
Beiträge: 861
Registriert: Mi 21. Apr 2010, 10:44
Wohnort: Hamburg Horn

Nächste

Zurück zu Programmierung

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste