Linear Frame Buffer bei BP7

Diskussion zum Thema Programmierung unter DOS (Intel x86)
Benutzeravatar
Dosenware
DOS-Gott
Beiträge: 3745
Registriert: Mi 24. Mai 2006, 20:29

Linear Frame Buffer bei BP7

Beitrag von Dosenware »

Gruß,

so langsam bastel ich mal wieder an etwas - Problem dabei: 800x600x16bit d.h. ich "brauche" (bzw. hätte sehr sehr gerne) größere zusammenhängende Speicherbereiche zum linearen Addressieren im Protected Mode von BP7.

Alternativ geht auch ein segmentierter LFB (zwischen den Variablen hin und herschalten geht immernoch schneller als das Bankswitching).

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

Re: Linear Frame Buffer bei BP7

Beitrag von freecrac »

Dosenware hat geschrieben:Gruß,

so langsam bastel ich mal wieder an etwas - Problem dabei: 800x600x16bit d.h. ich "brauche" (bzw. hätte sehr sehr gerne) größere zusammenhängende Speicherbereiche zum linearen Addressieren im Protected Mode von BP7.

Alternativ geht auch ein segmentierter LFB (zwischen den Variablen hin und herschalten geht immernoch schneller als das Bankswitching).

cu
Was meinst du sollte dafür vorher die Kapazität des Monitors übeprüft werden, oder ab wann gibt es dafür überhaupt eine Unterstützung?

Nun habe ich gelesen dass das Auslesen der EDID auch bei einem ausgeschalteten Monitor funktionieren soll.
Das war für mich neu und ausprobiert habe ich das noch nicht.

Code: Alles auswählen

START:    mov      ax, DATEN
	  mov      ds, ax
	  mov      es, ax
	  mov      ax, 4F15h          ; DDC - INSTALLATION CHECK
	  mov      bl, 0
	  int    10h
	  cmp      ax, 4Fh
	  jnz short NODDC
;-------------------------------------
	  mov      ax, 4F15h          ; DDC - READ EDID
	  mov      bl, 1
	  xor      cx, cx
	  xor      dx, dx
	  mov      di, OFFSET EDID
	  int    10h
	  mov      eax, 0FD000000h    ; Text-identifier V/H range
	  mov      bx, 36h
	  cmp      [di+bx], eax       ; di+36h detailed timing #1
	  jz  short H1
	  add      bx, 12h
	  cmp      [di+bx], eax       ; di+48h detailed timing #2
	  jz  short H1
	  add      bx, 12h
	  cmp      [di+bx], eax       ; di+5Ah detailed timing #3
	  jz  short H1
	  add      bx, 12h
	  cmp      [di+bx], eax       ; di+6Ch detailed timing #4
	  jnz short Home

H1:  mov      al, [di+bx+6]      ; MAXHZ

	  mov      al, [di+bx+8]      ; MAXKHZ


;-------------------------------------
HOME: mov     ah, 4Ch            ; Rücksprung, Programm-Ende
	  int    21h
;-------------------------------------
NODDC: mov      dx, OFFSET DDCERR
	  mov      ah, 9
	  int    21h
	  mov      al, 0FFh
	  jmp short HOME


;-------------------------------------
EDID   DB 0, 0, 0, 0, 0, 0, 0, 0      ; 8 padding (all FFh, or 00h FFh..FFh 00h)

       DW 0                           ; big-endian manufacturer ID
				      ; bits 14-10: first letter (01h='A', 02h='B', etc.)
				      ; bits 9-5: second letter
				      ; bits 4-0: third letter

       DW 0                           ; EDID ID code -- identifies monitor model

       DD 0                           ; serial number or FFFFFFFFh
				      ; for "MAG", subtract 7000000 to get actual serial number
				      ; for "OQI", subtract 456150000
				      ; for "PHL", subtract ???
				      ; for "VSC", subtract 640000000

       DB 0                           ; week number of manufacture

       DB 0                           ; manufacture year - 1990

       DB 0                           ; EDID version

       DB 0                           ; EDID revision

       DB 0                           ; video input type
				      ; Bit(s)  Description
				      ;  0      separate sync
				      ;  1      composite sync
				      ;  2      sync on green
				      ;  4-3    unused???
				      ;  6-5    voltage level
				      ;         00 0.700V/0.300V (1.00 Vp-p)
				      ;         01 0.714V/0.286V
				      ;         10 0.100V/0.400V
				      ;         11 reserved
				      ;  7      =1 digital signal, =0 analog

       DB 0                           ; maximum horizontal size in cm

       DB 0                           ; maximum vertical size in cm

       DB 0                           ; gamma factor (gamma = 1.0 + factor/100, so max = 3.55)

       DB 0                           ; DPMS flags
				      ; Bit(s)  Description
				      ;  2-0    unused???
				      ;  3      display type
				      ;         =0 non-RGB multicolor
				      ;         =1 RGB color
				      ;  4      unused???
				      ;  5      Active Off supported
				      ;  6      Suspend supported
				      ;  7      Standby supported

       DB 0                           ; chroma information: green X'/Y' and red X'/Y'
       DB 0                           ; chroma information: white X'/Y' and blue X'/Y'
       DB 0                           ; chroma information: red Y
       DB 0                           ; chroma information: red X
       DB 0                           ; chroma information: green Y
       DB 0                           ; chroma information: green X
       DB 0                           ; chroma information: blue Y
       DB 0                           ; chroma information: blue X
       DB 0                           ; chroma information: white Y
       DB 0                           ; chroma information: white X
       DB 0                           ; established timings 1
				      ; Bit(s)  Description
				      ;  0      720x400 @ 70 Hz (VGA 640x400, IBM)
				      ;  1      720x400 @ 88 Hz (XGA2)
				      ;  2      640x480 @ 60 Hz (VGA)
				      ;  3      640x480 @ 67 Hz (Mac II, Apple)
				      ;  4      640x480 @ 72 Hz (VESA)
				      ;  5      640x480 @ 75 Hz (VESA)
				      ;  6      800x600 @ 56 Hz (VESA)
				      ;  7      800x600 @ 60 Hz (VESA)

       DB 0                           ; established timings 2
				      ; Bit(s)  Description     (Table 00131)
				      ;  0      800x600 @ 72 Hz (VESA)
				      ;  1      800x600 @ 75 Hz (VESA)
				      ;  2      832x624 @ 75 Hz (Mac II)
				      ;  3      1024x768 @ 87 Hz interlaced (8514A)
				      ;  4      1024x768 @ 60 Hz (VESA)
				      ;  5      1024x768 @ 70 Hz (VESA)
				      ;  6      1024x768 @ 75 Hz (VESA)
				      ;  7      1280x1024 @ 75 Hz (VESA)

       DB 0                           ; manufacturer's reserved timing or 00h for none
				      ; bit 7: 1152x870 @ 75 Hz (Mac II, Apple)

       DW 0, 0, 0, 0, 0, 0, 0, 0      ; standard timing identification
				      ; resolution (low byte) and vertical frequency (high byte) for
				      ; each of eight modes
				      ; Bit(s)  Description
				      ;  5-0    vertical refresh frequency - 60 (Hz)
				      ;  7-6    aspect ratio (Y resolution = X resolution * aspect ratio)
				      ;         00 ???
				      ;         01 0.75
				      ;         10 0.8
				      ;         11 0.5625
				      ; Note:   if both bytes of the timing are 00h or 01h, then the Standard Timing
				      ;           is "None"
				      ;         X resolution = (lowbyte + 31) * 8
; detailed timing description #1
				      ; Format of EDID Text Identification Strings:
       DB 0, 0, 0                     ; (to distinguish from detailed timing description)
       DB 0                           ; text identifier
				      ;  FFh serial number
				      ;  FEh vendor name
				      ;  FDh vertical/horizontal frequency range
				      ;  FCh model name
				      ;  other = 14 BYTEs text, may be terminated with either a NUL (00h) or LF (0Ah)
       DB 0                           ; ???
MAXHZ  DB 0                           ; minimum vertical refresh frequency in Hz
       DB 0                           ; maximum vertical refresh
       DB 0                           ; minimum horizontal frequency in kHz
MAXKHZ DB 0                           ; maximum horizontal frequency
       DB 0FFh                        ; ???

;       DB 0                          ; horizontal frequency in kHz (if 00h, may be text)
;       DB 0                          ; vertical frequency in Hz
;       DB 0                          ; horizontal active time (pixels) and X resolution
;       DB 0                          ; horizontal blanking time (pixels)
;       DB 0                          ; horizontal active time 2 / horizontal blanking time 2
;       DB 0                          ; vertical active time (lines) and Y resolution
;       DB 0                          ; vertical blanking time (lines)
;       DB 0                          ; vertical active time 2 / vertical blanking time 2
;       DB 0                          ; horizontal sync offset (pixels)
;       DB 0                          ; horizontal sync pulsewidth (pixels)
;       DB 0                          ; vertical sync offset / vertical sync pulsewidth
;       DB 0                          ; vertical/horizontal sync offset 2 / vert/hor. sync pulsewidth 2
;       DB 0                          ; horizontal image size (mm)
;       DB 0                          ; vertical image size (mm)
;       DB 0                          ; horizontal image size 2 / vertical image size 2
;       DB 0                          ; horizontal border (pixels)
;       DB 0                          ; vertical border (lines)
;       DB 0                          ; type of display
;                                      ; Bit(s) Description
;                                      ;  7     interlaced
;                                      ;  6-5   stereo mode
;                                      ;        00 normal display (no stereo)
;                                      ;        01 stereo, right stereo sync high
;                                      ;        10 stereo, left stereo sync high
;                                      ;        11 undefined
;                                      ;  4-3   sync type
;                                      ;        00 sync analog composite
;                                      ;        01 sync bipolar analog composite
;                                      ;        10 sync digital composite
;                                      ;        11 sync digital separate
;                                      ; ---sync digital separate---
;                                      ;  2     vertical sync polarity (0 = negative, 1 = positive)
;                                      ;  1     horizontal sync polarity (0 = negative, 1 = positive)
;                                      ; ---other sync types---
;                                      ;  2     serrate
;                                      ;  1     sync location (0 = on green, 1 = on RGB)
;                                      ;  0     not used???
; detailed timing description #2
       DB 0, 0, 0, 0, 0, 0
       DB 0, 0, 0, 0, 0, 0
       DB 0, 0, 0, 0, 0, 0
; detailed timing description #3
       DB 0, 0, 0, 0, 0, 0
       DB 0, 0, 0, 0, 0, 0
       DB 0, 0, 0, 0, 0, 0
; detailed timing description #4
       DB 0, 0, 0, 0, 0, 0
       DB 0, 0, 0, 0, 0, 0
       DB 0, 0, 0, 0, 0, 0

       DB 0                           ; unused???

       DB 0                           ; checksum (radix-complement: 256-low byte of 16-bit sum of 00h-7Eh)

;-------------------------------------
DDCERR DB 0Dh, 0Ah, "Der Monitor hat kein DDC !$", 0Dh, 0Ah
Public documents from vesa.org: (Other VESA Standards and Documents)
EEDIDguideV1.pdf
EEDIDverifGuideRa.pdf

Dirk
wobo
DOS-Guru
Beiträge: 613
Registriert: So 17. Okt 2010, 14:40

Re: Linear Frame Buffer bei BP7

Beitrag von wobo »

Dosenware hat geschrieben:Gruß,

so langsam bastel ich mal wieder an etwas - Problem dabei: 800x600x16bit d.h. ich "brauche" (bzw. hätte sehr sehr gerne) größere zusammenhängende Speicherbereiche zum linearen Addressieren im Protected Mode von BP7.

Alternativ geht auch ein segmentierter LFB (zwischen den Variablen hin und herschalten geht immernoch schneller als das Bankswitching).

cu
Keine Ahnung: ich hatte noch nie was mit BP7 und/oder PMode zu tun. Unter TP 7.0 und 6.0 legt die TP-Speicherverwaltung zwei nachfolgende Aufrufe zur Heap-Allokation ja hintereinander an. Ein

GetMem( p1, 65528 );
GetMem( p2, 65528 );
GetMem( p3, 16 );

reserviert einen (mind.) 128kb-großen Bereich. Unter BP7.0 und PMode wäre ich mir aber nicht so sicher.

Vielleicht solltest Du einmal FreePascal ausprobieren. 800x600p16 klingt nach High-End-Dos-Maschine. Da dürfte dann auch FreePascal "rund" laufen.

Meinst Du einen linearen logischen oder einen physikalischen Speicherbereich? Oder willst Du direkt den LFB adressieren a la absolute - Anweisung im Real Mode?
Benutzeravatar
Dosenware
DOS-Gott
Beiträge: 3745
Registriert: Mi 24. Mai 2006, 20:29

Re: Linear Frame Buffer bei BP7

Beitrag von Dosenware »

Linear Physisch, Linear Frame Buffer halt - wenn das ganze logisch in mehrere 64k Segmente unterteilt ist (mit Pascal fast unvermeidlich), ist das kein Problem.
Variblen hin und herschalten geht schneller als Bankswitching.
Und Protected Mode.
___________________
Aktuell überlege ich auch wegen einem Sheduler - leider scheint mir aber nur die ganz dumme Variante realisierbar (bräuchte sonst zumindest mehrere Stacksegmente - außerdem pusht und popt Pascal ziemlich heftig) - wodurch sehr viel in einem Interrupt erledigt werden muss (Sound/Animation/...)... andererseits wird das wohl eh etwas für die schnelleren Rechner - Schätze das ganze wird am Ende so 8 Mb brauchen, bin halt kein Speichersparer.
freecrac
DOS-Guru
Beiträge: 861
Registriert: Mi 21. Apr 2010, 11:44
Wohnort: Hamburg Horn

Re: Linear Frame Buffer bei BP7

Beitrag von freecrac »

Die lineare Adresse des Framebuffers, die wir vom VBE 2+Bios über die Mode-Info für einen vorhanden Vesamode bekommen, ist eine physikalische Adresse vom LFB. Bei allen Karten die ich bisher getestet habe war die Adresse des LFBs für alle vorhandenen Modi einer Karte immer die selbe Adresse. Aber von Karte zu Karte und vielicht auch vom Mainboard zu Mainboard ist es eine andere Adresse. Diesen letzten Umstand habe ich aber noch nicht getestet.

Ich habe gelesen das man die Adresse des LFBs auch über den PCI-Bus ermitteln kann, ich selber habe das aber noch nicht probiert.

...

Insofern man sich im Protected-Mode befindet macht es eigentlich nur wenig Sinn den LFB in 64 KB grosse Segmente zu unterteilen, weil damit dann ja der linaere Zugriff auf den gesamten Framebuffer in einem Stück nicht mehr möglich ist.

So wie ich es jetzt verstanden habe gibt es mit Pascal aber Schwierigkeiten auf Segmente, die grösser als 64KB sind, in einem Durchgang zuzugreifen, womit auch das Arbeiten im Protectmode erschwert wird.
Habe ich das richtig verstanden?

Dirk
Benutzeravatar
Dosenware
DOS-Gott
Beiträge: 3745
Registriert: Mi 24. Mai 2006, 20:29

Re: Linear Frame Buffer bei BP7

Beitrag von Dosenware »

Jepp, BP7 kann nur maximal 64k große Datenstrukturen verwalten (alles andere muss mit Zeigern auf 64k Segmente zusammengebastelt werden).

Mir geht es im wesentlichen nur darum das Bankswitching einzusparen.
Also wird der Lineare Speicherbereich entweder in 64k Segmente zerhackstückelt (Variablen durchzuschalten geht ja recht schnell) oder ich muss mir was mit Assembler basteln....

Hmm... kann BP7 auf den LFB überhaupt zugreifen? Der liegt ja recht weit hinten...

EDIT: ich seh grad: 16Bit Protected Mode=max 1Gb - der LFB liegt üblicherweise weiter hinten... also muss ich da wohl etwas mit asm basteln - oder doch mit Bankswitching arbeiten.
freecrac
DOS-Guru
Beiträge: 861
Registriert: Mi 21. Apr 2010, 11:44
Wohnort: Hamburg Horn

Re: Linear Frame Buffer bei BP7

Beitrag von freecrac »

Dosenware hat geschrieben:Jepp, BP7 kann nur maximal 64k große Datenstrukturen verwalten (alles andere muss mit Zeigern auf 64k Segmente zusammengebastelt werden).

Mir geht es im wesentlichen nur darum das Bankswitching einzusparen.
Also wird der Lineare Speicherbereich entweder in 64k Segmente zerhackstückelt (Variablen durchzuschalten geht ja recht schnell) oder ich muss mir was mit Assembler basteln....
Daran habe ich auch gedacht.
Hmm... kann BP7 auf den LFB überhaupt zugreifen? Der liegt ja recht weit hinten...

EDIT: ich seh grad: 16Bit Protected Mode=max 1Gb - der LFB liegt üblicherweise weiter hinten... also muss ich da wohl etwas mit asm basteln - oder doch mit Bankswitching arbeiten.
Halt ganz langsam, keine Panik.
Ab 80386+ haben wir neben den neuen Operand-size und auch Address-size-Prefixen zusätzlich auch grössere Segmente-Einträge für die Segmente-Grösse bekommen. Diese Address-size-Prefixe lassen sich im RM, im PM, im Virtual86-Mode und im 16 Bit-Addressmode, sowie auch im 32 bit-Adressmode verwenden. Die Segment-Grösse und den damit adressierbaren Adressbereich richtet sich dabei entweder nach den Descriptor-Einträgen in einer GDT/LDT, oder wenn es die nicht gibt sind die Segmente auf 64 KB defaultmäßig begrenzt.

Das bedeutet auf einem 80386+(mit 21 Adressleitungen) kann man im 16 Bit PM so wie auch im 16 bit Unrealmode den gesamten 4GB Adressraum adressieren und auch den LFB mit Daten fülllen.

...

Der einzige Unterschied auf einem 80386+ zwischem dem 16 bit Adressmode und den 32 bit Adressmode ist die Bedeutung und Verwendung der Operandsize und Adresssize Prefixe, die für jeden einzenlnen Befehl und für die Dauer eines Befehls verwendet werden können. Diese Prefixe überschreiben die defaultmäßig eingestelle Größe der Operanden und Adressen in Abhängigkeit welcher Adressmode verwendet wird. Die defaultmäßige Grösse der Operanden/Adressen und der jeweilige Adressmode läßt sich im D-Bit(default adressmode bit) verändern.

[use 16]
Wobei wenn wir im 16 bit Adressmode 32 Bit Operanden oder 32 bit Adressen verwenden wollen dann müssen wir vor jedem Opcode solche Size-Prefix plazieren, andernfalls werden nur 16 Bit verwendet.

[use 32]
Im 32 bit Adressmode ändert sich diese Situation hierbei grundlegend, so das wenn wir 32 bit Operanden und Adressen verwenden wollen, dann müssen wir diese Prefixe weglassen und nur wenn wir 16 bit Operanden und Adressen verwenden wollen, dann müssen wir diese Prefixe verwenden und zu dem jeweiligen Befehl plazieren.

(Das Setzen und Weglassen solcher Prefixe erledigt gewöhnlich der jeweilige Assembler und insofern man die obigen Assembler-Directiven an den richtigen Stellen sinnvoll verwendet und im Falle das der Adressmode verändert wird, brauchen wir uns darum auch nicht weiter kümmern, wenn solche Directiven verfügbar sind wir nicht alles von Hand coden.)

Dirk
wobo
DOS-Guru
Beiträge: 613
Registriert: So 17. Okt 2010, 14:40

Re: Linear Frame Buffer bei BP7

Beitrag von wobo »

freecrac hat geschrieben:Die lineare Adresse des Framebuffers, die wir vom VBE 2+Bios über die Mode-Info für einen vorhanden Vesamode bekommen, ist eine physikalische Adresse vom LFB. Bei allen Karten die ich bisher getestet habe war die Adresse des LFBs für alle vorhandenen Modi einer Karte immer die selbe Adresse. Aber von Karte zu Karte und vielicht auch vom Mainboard zu Mainboard ist es eine andere Adresse. Diesen letzten Umstand habe ich aber noch nicht getestet.
Ich kann nur für DOS-typische, also VL/ISA- Karten sprechen: dort kann man den lfb oftmals per Registerbefehle pro Karte verschieden setzen. Das war meines Wissens notwendig, weil einige VL-Boards aus Kostengründen die Adressleitungen von zB. A28-A31 eingespart hatten. Der lfb musste dann innerhalb der ersten 64 oder 256 MB platziert werden können. Auch isa-Karten hatten oftmals einen in 1 MB-Schritten verschiebbaren lfb - vielleicht wurden auch schon auf isa boards Adressleitungen gespart, zumal ja viele isa boards max. 4 MB aufnehmen konnten (was auf die Einsparung von 2 Adressleitungen hindeutet).

Das von Dir angesprochene Speichermodell (Flat4gRM bzw. "unreal") funktioniert wunderbar mit TP 6.0 / 7.0, mit DosBox v0.73 und auch mit VESA/lfb. Allerdings will Dosenware ja unbedingt Protected Mode - da geht das zwar auch wie Du schreibst, im Netz habe ich bisher nicht besonders viel dazu gefunden (vgl.http://www.monstersoft.com/tutorial1/PM_intro.html). Und so einfach wie im Real Mode dürfte das nicht gehen, weil man ja auf das Zusammenspiel mit Borlands 16bit-pmode-extender achten müßte (denke ich mal).

Im Real Mode interessiert sich Turbo Pascal (=Real Mode Version von Borland Pascal) ja nicht dafür, was oberhalb der 1 MB-Grenze passiert. Das läßt einem natürlich "freie Hand".

@Dosenware (bei der Gelegenheit): Wie setzt man denn unter BP einen Deskriptor eine fixe Speicherstelle? Gibt es da eine extra Funktion? Für die Standardsegmente ($A0000,$B8000...) sind ja schon Deskriptoren definiert (SEGA0000 etc.) - wie geht das für noch nicht definierte Speicherbereiche, die wie der LFB fix im Speicher liegen?
freecrac
DOS-Guru
Beiträge: 861
Registriert: Mi 21. Apr 2010, 11:44
Wohnort: Hamburg Horn

Re: Linear Frame Buffer bei BP7

Beitrag von freecrac »

wobo hat geschrieben:Ich kann nur für DOS-typische, also VL/ISA- Karten sprechen: dort kann man den lfb oftmals per Registerbefehle pro Karte verschieden setzen. Das war meines Wissens notwendig, weil einige VL-Boards aus Kostengründen die Adressleitungen von zB. A28-A31 eingespart hatten. Der lfb musste dann innerhalb der ersten 64 oder 256 MB platziert werden können. Auch isa-Karten hatten oftmals einen in 1 MB-Schritten verschiebbaren lfb - vielleicht wurden auch schon auf isa boards Adressleitungen gespart, zumal ja viele isa boards max. 4 MB aufnehmen konnten (was auf die Einsparung von 2 Adressleitungen hindeutet).
Aha. Ich wusste noch gar nicht das isa-Karten auch schon einen LFB unterstützen.
Das von Dir angesprochene Speichermodell (Flat4gRM bzw. "unreal") funktioniert wunderbar mit TP 6.0 / 7.0, mit DosBox v0.73 und auch mit VESA/lfb.
Huch, auch das ist für mich neu, dass man innerhalb der DosBox, die doch unter Windows 32bit im PM läuft, selber in den PM schalten darf und es dann möglich wird den LFB zu verwenden. Bist du sicher das so etwas geht?
Allerdings will Dosenware ja unbedingt Protected Mode - da geht das zwar auch wie Du schreibst, im Netz habe ich bisher nicht besonders viel dazu gefunden (vgl.http://www.monstersoft.com/tutorial1/PM_intro.html).
http://www.monstersoft.com/tutorial1/PM_intro.html
16-bit Protected Mode
.....
The most memory that can be allocated is 16 megabytes.
Diese Angaben ist in Hinblick auf die nachfolgende Definition vom 32-bit Protected Mode, welcher ja einen 80386er voraussetzt, auf jeden Fall zumindest irreführend und für einen 80386 auch falsch, weil auch mit einem 80386er kann man den 16-bit Protected Mode verwenden und dann kann man damit ebenfalls 4 Gigabytes addressieren und davon den freien Speicher allozieren.

Solche falschen, bzw. unvollständigen Angaben führen oft zu Missverständnissen und diese findet man im Internet sehr oft darüber und so habe ich schon einige Male versucht das richtig zu stellen. So gibt es nun zumindest auf der deutschen wikipedia-Seite über den PM darauf einen ersten Hinweis.
http://de.wikipedia.org/wiki/Protected_Mode
32-Bit Protected Mode

Mit dem 386er wurde der Protected Mode auf 32 Bit erweitert, und bisher ungenutzte Felder in den Deskriptortabellen erlauben den Zugriff auf bis zu 4 GB physischer Hauptspeicher in 8192 Segmenten zu je maximal 4 GB ansprechen kann. Folgende Erweiterungen wurden gemacht:

Segmentlimit – Es wurde auf 20 Bit erweitert, so dass ein Segment bis zu 1 MiB groß sein kann. Um größere Segmente zu unterstützen, ohne das Längenfeld noch größer zu machen, wurde ein zusätzliches "Granularitätsbit" (G) eingeführt. Ist dieses Bit gesetzt, wird die Segmentlänge nicht mehr in Bytes, sondern in 4-KiB-Blöcken interpretiert. Damit sind Segmentgrößen bis 4 GiB möglich.
Startadresse – Sie wurde auf 32 Bit erweitert, so dass die Startadresse den gesamten physischen Adressraum abbilden kann
Operandengröße – Dieses Bit legt fest, ob ein Codesegment 16- oder 32-Bit-Code enthält, oder ob ein Stacksegment über den 16-Bit-Stackpointer SP oder den 32-Bit-Stackpointer ESP angesprochen werden soll.

Diese Erweiterungen beherrscht der 386er (und alle Nachfolgeprozessoren) auch im 16-Bit Protected Mode, so dass 16-Bit-Programme, die die 32-Bit-Befehlserweiterungen benutzen, den zusätzlichen Speicher auch ansprechen können.
...
Und so einfach wie im Real Mode dürfte das nicht gehen, weil man ja auf das Zusammenspiel mit Borlands 16bit-pmode-extender achten müßte (denke ich mal).
Ich hoffe das man diesen pmode-extender nicht zwingend verwenden muss und man mit einem Inline-assembler-code dann ohne weitere Probleme selber in den PM schalten und auf den Speicher und den LFB mit erweiterten Segmenten in einem Stück zugreifen können, so dass der LFB gar nicht in kleine 64KB grosse Segmente unterteilt werden braucht.
Im Real Mode interessiert sich Turbo Pascal (=Real Mode Version von Borland Pascal) ja nicht dafür, was oberhalb der 1 MB-Grenze passiert. Das läßt einem natürlich "freie Hand".
Genauso hatte ich es gedacht.
@Dosenware (bei der Gelegenheit): Wie setzt man denn unter BP einen Deskriptor eine fixe Speicherstelle? Gibt es da eine extra Funktion? Für die Standardsegmente ($A0000,$B8000...) sind ja schon Deskriptoren definiert (SEGA0000 etc.) - wie geht das für noch nicht definierte Speicherbereiche, die wie der LFB fix im Speicher liegen?
Sonnst müssen wir die Adresse in unserem eigenen Deskriptor halt selber eintragen, im Falle das solche hohen Adressen vom LFB in deren kleineren Deskriptoren nicht hineinpassen und nur 80286-PM-Deskriptoren von BP unterstützt werden.

Dirk
wobo
DOS-Guru
Beiträge: 613
Registriert: So 17. Okt 2010, 14:40

Re: Linear Frame Buffer bei BP7

Beitrag von wobo »

freecrac hat geschrieben:...
Aha. Ich wusste noch gar nicht das isa-Karten auch schon einen LFB unterstützen.
Nicht alle natürlich, sondern nur die wenigstens (und natürlich auch nicht nach VESA 2.0, sondern proprietär)
freecrac hat geschrieben:
Das von Dir angesprochene Speichermodell (Flat4gRM bzw. "unreal") funktioniert wunderbar mit TP 6.0 / 7.0, mit DosBox v0.73 und auch mit VESA/lfb.
Huch, auch das ist für mich neu, dass man innerhalb der DosBox, die doch unter Windows 32bit im PM läuft, selber in den PM schalten darf und es dann möglich wird den LFB zu verwenden. Bist du sicher das so etwas geht?
Mit DosBox meinte ich den (spiele-)Emulator, nicht das Dos-Fenster von windows! Und der Emulator emuliert ja nur das umschalten in den pmode... Es geht jedenfalls Flat4g/unreal unter dem Emulator. Das habe ich schon mehrfach ausprobiert. Die Kombination unreal/lfb hatte ich aber noch nicht unter DosBox ausprobiert. Ich weiss jetzt aber gar nicht, ob DosBox überhaupt vesa lfb unterstützt, oder nur standard vga bzw. vesa 1.2 (bank switching)
Benutzeravatar
Dosenware
DOS-Gott
Beiträge: 3745
Registriert: Mi 24. Mai 2006, 20:29

Re: Linear Frame Buffer bei BP7

Beitrag von Dosenware »

wobo hat geschrieben:Ich weiss jetzt aber gar nicht, ob DosBox überhaupt vesa lfb unterstützt, oder nur standard vga bzw. vesa 1.2 (bank switching)
Shiny sagt: wird unterstützt.

______
Bei Unreal u. Co habe ich Bedenken wegen der Kompatibilität, das Ergebnis soll auf verschiedenen Rechnern und in der Dosenbox laufen.
In Bp7 ist der PM halt der offizielle Weg um an mehr Speicher zu kommen - ich hatte seinerzeit mal etwas experimentiert und konnte als Maximum 64Mb aus BP herauskitzeln.

___
Läuft grad etwas zäh, habe im Moment viel um die Ohren (verkürztes WE (hab ab So. Nachtschicht), Rechner von Kumpel platt, letzte Woche war ich platt, Leben...)
wobo
DOS-Guru
Beiträge: 613
Registriert: So 17. Okt 2010, 14:40

Re: Linear Frame Buffer bei BP7

Beitrag von wobo »

Dosenware hat geschrieben: Bei Unreal u. Co habe ich Bedenken wegen der Kompatibilität, das Ergebnis soll auf verschiedenen Rechnern und in der Dosenbox laufen.
In Bp7 ist der PM halt der offizielle Weg um an mehr Speicher zu kommen - ich hatte seinerzeit mal etwas experimentiert und konnte als Maximum 64Mb aus BP herauskitzeln.
Mit unreal unter DosBox hatte ich bisher noch nie Probleme (egal, ob DosBox unter win2000, unter WinXp oder unter div. Linuxen). Auch unter real DOS hatte ich bisher kein einziges Problem, beginnend vom 386sx16 bis zum amd duron 750; Aber das muss ja leider nichts heißen.

Grundsätzlich würde ich aber auch eher pmode unter BP 7.0 bevorzugen. Es ist technisch wesentlich anspruchsvoller als unter unreal etwas zu programmieren. Aber das Thema 16bit pmode und BP 7.0 würde mich schon sehr reizen. Allein ich habe nur TP und einen beschränkten Horizont ;-)
Dosenware hat geschrieben:___
Läuft grad etwas zäh, habe im Moment viel um die Ohren (verkürztes WE (hab ab So. Nachtschicht), Rechner von Kumpel platt, letzte Woche war ich platt, Leben...)
Kenn ich, kenn ich. Aber hier im Forum nimmt man das einem - so mein Eindruck - ja nicht so krumm, wenn man mal 1-2 Wochen oder länger braucht, um zu antworten.
Benutzeravatar
Dosenware
DOS-Gott
Beiträge: 3745
Registriert: Mi 24. Mai 2006, 20:29

Re: Linear Frame Buffer bei BP7

Beitrag von Dosenware »

Also, ich werde jetzt vmtl. mit Freepascal weitermachen - wobei ich hoffe dass die Compilate schneller sind als die Installationsroutine.
___________________________

Bei Borland Pascal gibt es anscheinend sogar einen 48Bit Mode (16Bit Selektor, 32Bit Offset) und wohl auch einen eigenen Extender dafür, leide habe ich dazu auf die schnelle keine weiteren Informationen gefunden.
http://www.monstersoft.com/tutorial1/48bit_intro.html
http://www.askos.de/ram/#dpmi (nach "Zwitter" suchen)

Und: Der Unrealmode dürfte sehr kompatibel sein, lt. Netz wurde er schon damals oft für Spiele verwendet.
freecrac
DOS-Guru
Beiträge: 861
Registriert: Mi 21. Apr 2010, 11:44
Wohnort: Hamburg Horn

Re: Linear Frame Buffer bei BP7

Beitrag von freecrac »

Dosenware hat geschrieben:Also, ich werde jetzt vmtl....
prima... ich hoffe es ist eine gute Entscheidung.
Und: Der Unrealmode dürfte sehr kompatibel sein, lt. Netz wurde er schon damals oft für Spiele verwendet.
Zumindest stehen im 16 bit-Unrealmode weiterhin DOS- und Bios-Interrupts zur Verfügung. Womit ein Modewechsel mit einer anderen Auflösung jederzeit über die Interrupts möglich bleibt. Und die oberen 16 Bit in den 32 Bit Registern werden von DOS in den meisten Fällen doch unberücksichtigt gelassen und nehmen keinen Einfluss unf bleiben dann einfach unverändert erhalten.

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

Re: Linear Frame Buffer bei BP7

Beitrag von freecrac »

Hohe Videomodi ergeben viel Bildmaterial und so ist es zweckmäßig ein Speicherbereich zu verwenden, wo das Bild aufbereitet und berechnet wird und wenn es fertig berechnet ist, von dort aus zum LFB übertragen werden kann.

Die wichtigsten Methoden es herauszufinden welcher Speicher und Adressbereiche belegt, oder frei sind:
http://wiki.osdev.org/Detecting_Memory_%28x86%29
("Memory Map Via GRUB" sollte wohl zuverlässig sein.)

Dirk
Antworten