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
Linear Frame Buffer bei BP7
Re: Linear Frame Buffer bei BP7
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?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
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
EEDIDguideV1.pdf
EEDIDverifGuideRa.pdf
Dirk
Re: Linear Frame Buffer bei BP7
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. EinDosenware 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
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?
Re: Linear Frame Buffer bei BP7
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.
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.
Re: Linear Frame Buffer bei BP7
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
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
Re: Linear Frame Buffer bei BP7
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.
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.
Re: Linear Frame Buffer bei BP7
Daran habe ich auch gedacht.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....
Halt ganz langsam, keine Panik.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.
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
Re: Linear Frame Buffer bei BP7
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).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.
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?
Re: Linear Frame Buffer bei BP7
Aha. Ich wusste noch gar nicht das isa-Karten auch schon einen LFB unterstützen.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).
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?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.
http://www.monstersoft.com/tutorial1/PM_intro.htmlAllerdings 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).
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.16-bit Protected Mode
.....
The most memory that can be allocated is 16 megabytes.
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.
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.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).
Genauso hatte ich es gedacht.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".
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.@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?
Dirk
Re: Linear Frame Buffer bei BP7
Nicht alle natürlich, sondern nur die wenigstens (und natürlich auch nicht nach VESA 2.0, sondern proprietär)freecrac hat geschrieben:...
Aha. Ich wusste noch gar nicht das isa-Karten auch schon einen LFB unterstützen.
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)freecrac hat geschrieben: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?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.
Re: Linear Frame Buffer bei BP7
Shiny sagt: wird unterstützt.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)
______
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...)
Re: Linear Frame Buffer bei BP7
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.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.
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
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.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...)
Re: Linear Frame Buffer bei BP7
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.
___________________________
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.
Re: Linear Frame Buffer bei BP7
prima... ich hoffe es ist eine gute Entscheidung.Dosenware hat geschrieben:Also, ich werde jetzt vmtl....
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.Und: Der Unrealmode dürfte sehr kompatibel sein, lt. Netz wurde er schon damals oft für Spiele verwendet.
Dirk
Re: Linear Frame Buffer bei BP7
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
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