Discussion:
Testing all video mode - but which ones are graphics ?
(too old to reply)
R.Wieser
2024-02-15 11:04:28 UTC
Permalink
Hello all,

I've got a small program going thru all video-modi by looping AL from 80
upto FF, calling INT 10, AH=00.

I would like to find out which of those modi are graphical. Ralf Browns
memory list shows 0040:0065 to hold some bits regarding the current video
mode. In my case the lower two bits are of interrest

Mode 03, text, shows the value 01. Alas, mode 0D, graphics, also shows 01.
In fact, only modi 4 thru 6 show a 02 there, and modi 0 and 01 show a 00.
Al others show 01.

And I'm pretty sure there are few other graphics modi above mode 06 ...

tl;dr:
How do I find out if a certain mode is graphics ?

Secondary question : if the lower two bits of 0040:0065 are *not* the
current video-modes graphics and textmode capablities, what do they signify
instead ?


## Bummer.

It turns out that selecting at least one video modus causes, on return to
it, my XP desktop to go black, with only the mouse visible & working. Than
after a few seconds the 'puter reboots.

In some other video modi enabeling the mouse causes an NTVDM illegal
instruction error.

Yet other video modi just display a black screen, which accepts neither text
output nor pixel plotting.

On short : even when INT 10h, AH=0Fh returns a selected video modus as
accepted, there is still a chance it won't work (and thats besides the -
expected - "out of range" and "no video signal" ones). :-(


Revised question:
How do I find all INT 10h, ah=00h video modi that wil actually work on my
(XP) 'puter ? (My "is it a graphical mode?" has become secondary).

Regards,
Rudy Wieser
Paul Edwards
2024-02-15 13:32:44 UTC
Permalink
Post by R.Wieser
It turns out that selecting at least one video modus causes, on return to
it, my XP desktop to go black, with only the mouse visible & working. Than
after a few seconds the 'puter reboots.
How do I find all INT 10h, ah=00h video modi that wil actually work on my
(XP) 'puter ? (My "is it a graphical mode?" has become secondary).
Do you mean XT?

Or are you talking about running MSDOS apps under Windows XP?

I don't know the answer to your question - but
someone who does know the answer may not answer
because they are confused about the environment.

BFN. Paul.
R.Wieser
2024-02-15 14:39:11 UTC
Permalink
Paul,
Post by Paul Edwards
Do you mean XT?
Nope. Do those motherboards still exist ? :-)
Post by Paul Edwards
Or are you talking about running MSDOS apps under Windows XP?
Yep.
Post by Paul Edwards
but someone who does know the answer may not answer
because they are confused about the environment.
The full info in that regard is : Windows XPsp3 cmd.exe console in 80x25
full-screen mode.

Regards,
Rudy Wieser
wolfgang kern
2024-02-15 14:32:24 UTC
Permalink
On 15/02/2024 12:04, R.Wieser wrote:

hello Rudy,
Post by R.Wieser
I've got a small program going thru all video-modi by looping AL from 80
upto FF, calling INT 10, AH=00.
...
Post by R.Wieser
And I'm pretty sure there are few other graphics modi above mode 06 ...
How do I find out if a certain mode is graphics ?
How do I find all INT 10h, ah=00h video modi that wil actually work
on > my (XP) 'puter ? (My "is it a graphical mode?" has become secondary).

VESA support is found within:

details are also reported in RBIL 104f00,104f01,014f02

(may need a few 66h override or split instructions)
(and I use some variables as code parts already)
push es
push ds
push 0x8400 ;buffer for returned data
pop es
xor di,di
mov ax,0x4f00
int 0x10
cmp ax,0x004f
jz vesa_ok
:no_vesa
...err-msg
pop/pop/ret
vesa_ok:
lds:si,[es:di+0x0e] ;ds:si points to mode list
mov ax,[es:di+0x12] ;
sll eax,16 ;mov ax to top and clear bottom
mov [cs:xxx+0x0c],eax ;current mode number
movzx eax,word[es:di+0x08] ;
movzx ecx,word[es:di+0x06] ;
sll eax,4
add eax,ecx
mov [cs:xxx+0x04],eax ;linear start address
... ;I get&store vesa version here.
;---
push 0x8420 ;buffer for modelist
pop es
xor di,di
CHECKLOOP:
mov cx,[si] ;
add si.0x02
cmp cx,0xffff ;end mark
jz pop_ret ;all done
mov ax.0x4f01
int 0x10 ;get info for mode number in cx
cmp ax,0x004f
jz error_ret
mov al,[es:di] :mode type (see below)

;store cx in text or graphic list but loop until endmark


---copied from RBIL---
Bitfields for VESA SuperVGA mode attributes:
Bit(s) Description (Table 00080)
0 mode supported by present hardware configuration
1 optional information available (must be =1 for VBE v1.2+)
2 BIOS output supported
3 set if color, clear if monochrome
4 set if graphics mode, clear if text mode *******
---VBE v2.0+ ---
5 mode is not VGA-compatible
6 bank-switched mode not supported
7 linear framebuffer mode supported
8 double-scan mode available (e.g. 320x200 and 320x240)
---VBE v3.0 ---
9 interlaced mode available
10 hardware supports triple buffering
11 hardware supports stereoscopic display
12 dual display start address support
13-15 reserved
---
The INT0x10_AH00 method isn't meant to be looped with all values,
so some may just lock up while others could damage (old) monitors.
And several numbers can represent both text and graphic modes.
many different modes are assigned to the same number by vendors.
So there is no way to tell which is what by using INT10_00.

there once were a list of available modes in the graphic card's BIOS.
__
wolfgang
R.Wieser
2024-02-15 19:39:38 UTC
Permalink
wolfgang,
Post by wolfgang kern
Post by R.Wieser
I've got a small program going thru all video-modi by looping AL from 80
upto FF, calling INT 10, AH=00.
The INT0x10_AH00 method isn't meant to be looped with all values,
so some may just lock up
Which is indeed is a problem I already ran into. In several different ways.
Post by wolfgang kern
while others could damage (old) monitors.
I read about that, but thought that their limited resolutions would mean
they where thrown out long ago (as in, last century). But with the absense
of a "tell me if <number> video mode is supported" system call I saw no
other possibilities.
:-) You're talking about possible damage to ancient monitors (connected to
EGA, MCGA or even older videocards), and than you're presenting a bit of
code thats ment for VESA ? :-p
Post by wolfgang kern
details are also reported in RBIL 104f00,104f01,014f02
I've got Ralf Browns interrupt list (since forever) on my 'puter, so I'm
sure to take a peek.

And thanks for the code, I'm going to take a look at it.


<some time passes>
Post by wolfgang kern
push 0x8400 ;buffer for returned data
push 0x8420 ;buffer for modelist
mov [cs:xxx+0x0c],eax ;current mode number
mov [cs:xxx+0x04],eax ;linear start address
Also, for the "xxx+0x0c" one, why storing 4 bytes when the low two are
always zero ?

furthermore, int 0x10, AX=0x4F00, offset 0E..11 does seem to point to a list
with video modi, but only from 0x100 and up.

Than when I use int 0x10, AX=0x4F01 on the range 0x00...0xFF it doesn't
think that there are any valid video modi below 0x30. And the ones it
thinks are valid all seem to be Graphics modi (bit 4 set in the first byte).

IOW, the above two calls do work, but not for any of the basic (old?) video
modi. And those are the ones I'm pretty-much after.

Regardless of the above, stil thank you for posting it.

Regards,
Rudy Wieser
wolfgang kern
2024-02-16 06:36:52 UTC
Permalink
On 15/02/2024 20:39, R.Wieser wrote:
...
Post by R.Wieser
:-) You're talking about possible damage to ancient monitors (connected to
EGA, MCGA or even older videocards), and than you're presenting a bit of
code thats ment for VESA ? :-p
I still owe one working PC-AT tower from 1998 which had an old TV-like
RGB CRT-monitor (already died RIP) but it used VESA from very start.
Post by R.Wieser
Post by wolfgang kern
details are also reported in RBIL 104f00,104f01,014f02
I've got Ralf Browns interrupt list (since forever) on my 'puter, so I'm
sure to take a peek.
And thanks for the code, I'm going to take a look at it.
<some time passes>
Post by wolfgang kern
push 0x8400 ;buffer for returned data
push 0x8420 ;buffer for modelist
these are just free memory locations, you can use any other even I find
my choice a good solution [at the end of user RAM space].
Post by R.Wieser
Post by wolfgang kern
mov [cs:xxx+0x0c],eax ;current mode number
mov [cs:xxx+0x04],eax ;linear start address
I use them as part of instructions:
CS:xx02:
66 BA dd dd dd dd MOV EDX,immediate quad dd ;screen start address
Post by R.Wieser
Also, for the "xxx+0x0c" one, why storing 4 bytes when the low two are
always zero ?
that's because I prefer linear addressing in graphic modes
the graphic card's LFB (linear frame buffer) is usually above 3rd GB
you'll need either PM32 or UNREAL-mode like I do during boot-up to
access that memory region.
Post by R.Wieser
furthermore, int 0x10, AX=0x4F00, offset 0E..11 does seem to point to a list
with video modi, but only from 0x100 and up.
Yes, VESA mode numbers are all +0x0100
Post by R.Wieser
Than when I use int 0x10, AX=0x4F01 on the range 0x00...0xFF it doesn't
think that there are any valid video modi below 0x30. And the ones it
thinks are valid all seem to be Graphics modi (bit 4 set in the first byte).
IOW, the above two calls do work, but not for any of the basic (old?) video
modi. And those are the ones I'm pretty-much after.
most of these olde were replaced by "new(1995)" Vesa codes.
you may find x/y resolution and pixel-depth in the list which
do what you search for.

only a few "old" modes can be used with VESA.
I use cx=0x0003 for classical text mode
and IIRC modes 0..7 may work similar
Post by R.Wieser
Regardless of the above, stil thank you for posting it.
welcome
__
wolfgang
R.Wieser
2024-02-16 08:11:17 UTC
Permalink
wolfgang,
Post by wolfgang kern
push 0x8400 ;buffer for returned data
push 0x8420 ;buffer for modelist
these are just free memory locations, you can use any other even I find my
choice a good solution [at the end of user RAM space].
I'm sorry ? The segment address 0x8400 is almost smack in the middle of
the 1 M memory space DOS can address. It /might/ not be in use (yet!), but
just writing data in memory not owned by the program is ... not good.

I used a bit of stack space instead.
Post by wolfgang kern
mov [cs:xxx+0x0c],eax ;current mode number
mov [cs:xxx+0x04],eax ;linear start address
66 BA dd dd dd dd MOV EDX,immediate quad dd ;screen start address
Ah, self-modifying code.
that's because I prefer linear addressing in graphic modes
the graphic card's LFB (linear frame buffer) is usually above 3rd GB
you'll need either PM32 or UNREAL-mode like I do during boot-up to access
that memory region.
I understand the need for the storage size, but have no idea why you put the
video mode in the upper two bytes of that 4-byte storage space.
only a few "old" modes can be used with VESA.
I use cx=0x0003 for classical text mode
and IIRC modes 0..7 may work similar
:-) Thats pretty-much the problem : I have no idea which of those "old" mod
are valid. When I use INT 0x10, AH=0x00 to check modi 0x08 thru 0x0C they
seem to be accepted, but give rather odd text screen width and height (last
value is supposed to be the character cell height):

0x08> 0x2 0x02
0x09> 42x43 0x15
0x0A> 17x29 0x08
0x0B> 0x64 0x00
0x0C> 13x16 0x10

I've got no idea how (by what) to weed those out yet.

But looking at where the VESA modi start, I think I may conclude that the
"old" modi are limited to the 0x00....0x2F range. Thats at least something.
:-)

Regards,
Rudy Wieser
wolfgang kern
2024-02-16 09:16:33 UTC
Permalink
Post by R.Wieser
wolfgang,
Post by wolfgang kern
push 0x8400 ;buffer for returned data
push 0x8420 ;buffer for modelist
these are just free memory locations, you can use any other even I find my
choice a good solution [at the end of user RAM space].
I'm sorry ? The segment address 0x8400 is almost smack in the middle of
the 1 M memory space DOS can address. It /might/ not be in use (yet!), but
just writing data in memory not owned by the program is ... not good.
OK, the code is part of my OS, it owns all RAM except what BIOS uses.
Post by R.Wieser
I used a bit of stack space instead.
then you could be on the safer side but I'd store the info somewhere
for later use.
Post by R.Wieser
Post by wolfgang kern
mov [cs:xxx+0x0c],eax ;current mode number
mov [cs:xxx+0x04],eax ;linear start address
66 BA dd dd dd dd MOV EDX,immediate quad dd ;screen start address
Ah, self-modifying code.
yes, I use that a lot even mainly once per item during boot-up and right
after screen mode changes on all involved "variables". [big savings]
Post by R.Wieser
that's because I prefer linear addressing in graphic modes
the graphic card's LFB (linear frame buffer) is usually above 3rd GB
you'll need either PM32 or UNREAL-mode like I do during boot-up to access
that memory region.
I understand the need for the storage size, but have no idea why you put the
video mode in the upper two bytes of that 4-byte storage space.
oh yes, I keep a whole list of screen modes (filtered for my needs) in
memory and use this two free lower bytes as status info and short-keys.
Post by R.Wieser
only a few "old" modes can be used with VESA.
I use cx=0x0003 for classical text mode
and IIRC modes 0..7 may work similar
:-) Thats pretty-much the problem : I have no idea which of those "old" mod
are valid. When I use INT 0x10, AH=0x00 to check modi 0x08 thru 0x0C they
seem to be accepted, but give rather odd text screen width and height (last
0x08> 0x2 0x02
0x09> 42x43 0x15
0x0A> 17x29 0x08
0x0B> 0x64 0x00
0x0C> 13x16 0x10
I've got no idea how (by what) to weed those out yet.
I rare to never used any of the above, my preference is/was always 2^n
aligned modes [512x386 instead of 320x200 a.s.o.] with 8 or 32 bit DAC.
but newer modes aren't 2^n anymore so I had to add instructions for it.
Post by R.Wieser
But looking at where the VESA modi start, I think I may conclude that the
"old" modi are limited to the 0x00....0x2F range. Thats at least something.
:-)
sure worth to give it a try. good luck
__
wolfgang
R.Wieser
2024-02-16 09:35:25 UTC
Permalink
wolfgang,
Post by wolfgang kern
Post by R.Wieser
I'm sorry ? The segment address 0x8400 is almost smack in the middle of
the 1 M memory space DOS can address. It /might/ not be in use (yet!),
but just writing data in memory not owned by the program is ... not good.
OK, the code is part of my OS, it owns all RAM except what BIOS uses.
Ah yes, that explains it.
Post by wolfgang kern
then you could be on the safer side but I'd store the info somewhere
for later use.
The /needed/ info, yes. Which might well be /way/ less than that 0x200
bytes.
Post by wolfgang kern
Post by R.Wieser
0x08> 0x2 0x02
0x09> 42x43 0x15
0x0A> 17x29 0x08
0x0B> 0x64 0x00
0x0C> 13x16 0x10
I've got no idea how (by what) to weed those out yet.
I rare to never used any of the above,
Neither have I, as those modi do not work (on my machine). :-)

Thanks for the help and explanations.

Regards,
Rudy Wieser
R.Wieser
2024-02-17 12:40:44 UTC
Permalink
Post by R.Wieser
How do I find all INT 10h, ah=00h video modi that wil actually work on my
(XP) 'puter ? (My "is it a graphical mode?" has become secondary).
It turns out that INT 0x10, AH=0x1B, BX=0x0000 returns a record with the
first six (three?) bytes containing a bit mask of valid video modi.

So, success !



Ehhrmm... Not so fast please.

It works on my current machine, but on another (also XPsp3) machine *none*
of the "valid" video-modi (using INT 0x10, AH=0x00) actually works : the
puter locks up and can only be gotten outof it thru a power-cycle. :-((

No idea why, or how I could deal with it.

Regards,
Rudy Wieser
wolfgang kern
2024-02-17 16:36:31 UTC
Permalink
Post by R.Wieser
It turns out that INT 0x10, AH=0x1B, BX=0x0000 returns a record with the
first six (three?) bytes containing a bit mask of valid video modi.
three (2.5) bytes. bits 0..19 for modes 00..0x13 (19dec)
Post by R.Wieser
So, success !
supported only if INT10_1B (ax=0x1B00) returns 0x1B in AL
Post by R.Wieser
Ehhrmm... Not so fast please.
It works on my current machine, but on another (also XPsp3) machine *none*
of the "valid" video-modi (using INT 0x10, AH=0x00) actually works : the
puter locks up and can only be gotten outof it thru a power-cycle. :-((
No idea why, or how I could deal with it.
depends on the graphic chip... modern stuff may work only with VESA.
have you tried cx==0x0013 ax==0x4f01 INT_0x10 ?
didn't work on my old PC
__
wolfgang
R.Wieser
2024-02-17 18:10:37 UTC
Permalink
wolfgang,
Post by wolfgang kern
Post by R.Wieser
So, success !
supported only if INT10_1B (ax=0x1B00) returns 0x1B in AL
:-) Yes, I checked that.
Post by wolfgang kern
Post by R.Wieser
No idea why, or how I could deal with it.
depends on the graphic chip... modern stuff may work only with VESA.
That was my conclusion too.
Post by wolfgang kern
have you tried cx==0x0013 ax==0x4f01 INT_0x10 ?
didn't work on my old PC
On the first machine (with the BIOS video modi working) it fails, on the
other machine it succedes.

Question:
I tried to call INT 0x10, AX=0x4F02, CX=0x0100 on the second machine, but I
have no idea what all goes into that es:di area, so I just cleared it. The
machine locked up. :-(

Do you know where that info comes from ?

I could try to (pretty-much randomly) slap something together (from what I
don't know), but as long as you're here ... :-)

Regards,
Rudy Wieser
wolfgang kern
2024-02-17 18:35:32 UTC
Permalink
Post by R.Wieser
wolfgang,
Post by wolfgang kern
Post by R.Wieser
So, success !
supported only if INT10_1B (ax=0x1B00) returns 0x1B in AL
:-) Yes, I checked that.
Post by wolfgang kern
Post by R.Wieser
No idea why, or how I could deal with it.
depends on the graphic chip... modern stuff may work only with VESA.
That was my conclusion too.
Post by wolfgang kern
have you tried cx==0x0013 ax==0x4f01 INT_0x10 ?
didn't work on my old PC
On the first machine (with the BIOS video modi working) it fails, on the
other machine it succedes.
I tried to call INT 0x10, AX=0x4F02, CX=0x0100 on the second machine, but I
have no idea what all goes into that es:di area, so I just cleared it. The
machine locked up. :-(
Do you know where that info comes from ?
RBIL tells on 104F02:

AX = 4F02h
!! BX = new video mode (see #04082,#00083,#00084)
ES:DI -> (VBE 3.0+) CRTC information block,
bit mode bit 11 set(see #04083)
---RBIL copy
Format of VESA VBE CRTC Information Block:
Offset Size Description (Table 04083)
00h WORD total number of pixels horizontally
02h WORD horizontal sync start (in pixels)
04h WORD horizontal sync end (in pixels)
06h WORD total number of scan lines
08h WORD vertical sync start (in scan lines)
0Ah WORD vertical sync end (in scan lines)
0Ch BYTE flags (see #04084)
0Dh DWORD pixel clock, in Hz
11h WORD refresh rate, in 0.01 Hz units
this field MUST be set to pixel_clock / (HTotal * VTotal),
even though it may not actually be used by the VB implementation
13h 40 BYTEs reserved

Bitfields for VESA VBE CRTC Information Block flags:
Bit(s) Description (Table 04084)
0 enable double scanning
1 enable interlacing
2 horizontal sync polarity (0 positive, 1 negative)
3 vertical sync polarity (0 positive, 1 negative)


mode 0100 is graphic 640*400,8bit (256 colors)
my OS rare alters CRTC values, so I have ES:DI as 0:0
Post by R.Wieser
I could try to (pretty-much randomly) slap something together (from what I
don't know), but as long as you're here ... :-)
my lifetime is already limited but I'm still alive for now :)
__
wolfgang
wolfgang kern
2024-02-17 20:38:10 UTC
Permalink
I tried to call INT 0x10, AX=0x4F02, CX=0x0100 ...
try INT 0x10, AX=0x4F02, BX=0x0100
and ES:DI could need to be 0xFFFF:FFFF to ignore CRT setup.
__
wolfgang
R.Wieser
2024-02-18 08:13:38 UTC
Permalink
wolfgang,
Post by wolfgang kern
I tried to call INT 0x10, AX=0x4F02, CX=0x0100 ...
try INT 0x10, AX=0x4F02, BX=0x0100
and ES:DI could need to be 0xFFFF:FFFF to ignore CRT setup.
Thanks for the suggestion.

I already tried doing that (and for other VESA modi too) with ES:DI set to
zero or untouched. It didn't make a difference, the 'puter froze every
time. :-\

As both ways to set a video mode froze the puter I started to suspect the
"OS" (drivers, other stuff installed on it). So, booted from an USB stick
with DOS on it (taken from Win98. Yes, an old stick :-) ).

Surprise surprise, it had no problem with scanning thru the BIOS video modi
(using INT 0x10, AX=0x00??), nor had it any problems with setting VESA mode
0x0100 (using INT 0x10, AX=0x4202, BX=0x0100, ES=DI=0) (though a DIR
outputs scrolling was /slow/. )

In short, I think I need to consider re-installing that 'puter, and at least
check its response before and after I install the videocards drivers.


A question about the INT 0x10, AX=0x4F01 result though : When I look at the
"mode attributes" (offset 0x00) I see that :

Bit 0 is about "mode supported by present hardware configuration". As such
I've ignored any VESA modus where that bit was not set. Is that what I
needed to do, or does that bit have another meaning ?

Bit 2 is about "BIOS output supported". I assume that means that when its
set I can do an INT 0x10, AH=0Eh and expect the character to appear on the
screen (same for plotting pixels using INT 0x10, AH=0x0C). Is that a correct
assumption?

Bit 4 is set if its a graphic mode. I /thought/ I remembered graphics modi
which do not support text output. Have you ever encountered such a mode and
know how to check for them ?

Regards,
Rudy Wieser
wolfgang kern
2024-02-18 08:58:25 UTC
Permalink
Post by R.Wieser
Post by wolfgang kern
I tried to call INT 0x10, AX=0x4F02, CX=0x0100 ...
try INT 0x10, AX=0x4F02, BX=0x0100
and ES:DI could need to be 0xFFFF:FFFF to ignore CRT setup.
Thanks for the suggestion.
I already tried doing that (and for other VESA modi too) with ES:DI set to
zero or untouched. It didn't make a difference, the 'puter froze every
time. :-\
As both ways to set a video mode froze the puter I started to suspect the
"OS" (drivers, other stuff installed on it). So, booted from an USB stick
with DOS on it (taken from Win98. Yes, an old stick :-) ).
Surprise surprise, it had no problem with scanning thru the BIOS video modi
(using INT 0x10, AX=0x00??), nor had it any problems with setting VESA mode
0x0100 (using INT 0x10, AX=0x4202, BX=0x0100, ES=DI=0) (though a DIR
outputs scrolling was /slow/. )
In short, I think I need to consider re-installing that 'puter, and at least
check its response before and after I install the videocards drivers.
YEAH, virtualization kills almost everything :)
And graphic driver software may be just there to support windoze&loonix.

INT_0x10 used direct from Video BIOS w/o detoured by hooks work best.
Post by R.Wieser
A question about the INT 0x10, AX=0x4F01 result though : When I look at the
Bit 0 is about "mode supported by present hardware configuration". As such
I've ignored any VESA modus where that bit was not set. Is that what I
needed to do, or does that bit have another meaning ?
yes.
and there are additional issues with monitors (I hate this EDID story)
Post by R.Wieser
Bit 2 is about "BIOS output supported". I assume that means that when its
set I can do an INT 0x10, AH=0Eh and expect the character to appear on the
screen (same for plotting pixels using INT 0x10, AH=0x0C). Is that a correct
assumption?
yes, but plotting pixels in text modes may not work.
and INT_10_0C is usually pretty slow, I use direct screen write instead.
Post by R.Wieser
Bit 4 is set if its a graphic mode. I /thought/ I remembered graphics modi
which do not support text output. Have you ever encountered such a mode and
know how to check for them ?
some graphic modes may support INT_10_0E for text-out, but I use my own
draw routines for it anyway.
I use my own fonts [16*8 12*8 8*8] for graphic modes,
and use some of my fonts for text modes too with:
---RBIL copy
INT 10 - VIDEO - Realtek RTVGA - SET USER GRAPHICS CHARACTERS
AX = 1110h
ES:BP -> user table
CX = bytes per character
BL = row specifier
00h user set
DL = number of rows
01h 14 rows
02h 25 rows
03h 43 rows
Return: nothing
Note: this function is meant to be called immediately after a mode set;
results are unpredictable at other times
---
I once played around with my very own video-modes by using VGA-registers
funny things like mixed text/graphic can be made but unfortunately work
only for one specific brand and crash on others.
__
wolfgang
R.Wieser
2024-02-18 10:50:28 UTC
Permalink
Wolfgang,
Post by wolfgang kern
Post by R.Wieser
In short, I think I need to consider re-installing that 'puter, and at least
check its response before and after I install the videocards drivers.
YEAH, virtualization kills almost everything :)
I'm not sure which virtualisation you mean, but both the 'puters I mentioned
are bare-metal ones.
Post by wolfgang kern
And graphic driver software may be just there to support windoze&loonix.
Hence my before-and-after checking. :-)
Post by wolfgang kern
INT_0x10 used direct from Video BIOS w/o detoured by hooks work best.
A number of those hooks could be there to make the video card "play nice"
with Windows .though ..

TBH, I was already thinking of a DOS TSR to block the BIOS video modi calls,
so at least my 'puter would not lock up. But that was before I noticed it
wouldn't work with VESA either.
Post by wolfgang kern
Post by R.Wieser
Bit 0 is about "mode supported by present hardware configuration". As such
I've ignored any VESA modus where that bit was not set. Is that what I
needed to do, or does that bit have another meaning ?
yes.
"yes", ignoring such a modus is what you should do, or "yes", it does have
another meaning ? :-)
Post by wolfgang kern
and there are additional issues with monitors (I hate this EDID story)
Oh goody. :-\
Post by wolfgang kern
Post by R.Wieser
Bit 2 is about "BIOS output supported". I assume that means that when its
set I can do an INT 0x10, AH=0Eh and expect the character to appear on the
screen (same for plotting pixels using INT 0x10, AH=0x0C). Is that a correct
assumption?
yes,
Score one for the team! :-)
Post by wolfgang kern
but plotting pixels in text modes may not work.
I thought that went without saying (with the "may not" read as "won't"), but
I guess you've met some "special" people.
Post by wolfgang kern
and INT_10_0C is usually pretty slow, I use direct screen write instead.
I would expect so, as it treats every pixel on its own, repeating all the
calculations and stuff it already did for the previous pixel.
Post by wolfgang kern
Post by R.Wieser
Bit 4 is set if its a graphic mode. I /thought/ I remembered graphics modi
which do not support text output. Have you ever encountered such a mode and
know how to check for them ?
some graphic modes may support INT_10_0E for text-out, but I use my own
draw routines for it anyway.
I'm comfortable with starting with video modi which support text output, and
wait with drawing text myself for a later date/project.
Post by wolfgang kern
I use my own fonts [16*8 12*8 8*8] for graphic modes,
---RBIL copy
INT 10 - VIDEO - Realtek RTVGA - SET USER GRAPHICS CHARACTERS
One of the few times I did something with a font was with a DOS pseudo-virus
called "animo" - once in a while it would animate the "o" character into a
hand-waving figure. Was fun to see people get bug-eyed about what just
happened. :-)
Post by wolfgang kern
I once played around with my very own video-modes by using VGA-registers
funny things like mixed text/graphic can be made but unfortunately work
only for one specific brand and crash on others.
That I can imagine, knowing that each videocard carries its own BIOS and
needs its own Windows drivers.

Regards,
Rudy Wieser
wolfgang kern
2024-02-18 11:31:21 UTC
Permalink
On 18/02/2024 11:50, R.Wieser wrote:
...
Post by R.Wieser
Post by wolfgang kern
Post by R.Wieser
Bit 0 is about "mode supported by present hardware configuration". As such
I've ignored any VESA modus where that bit was not set. Is that what I
needed to do, or does that bit have another meaning ?
yes.
"yes", ignoring such a modus is what you should do, or "yes", it does have
another meaning ? :-)
my single yes to multiple questions always respond to the first! :)
while others may mean the last...
...
Post by R.Wieser
Post by wolfgang kern
some graphic modes may support INT_10_0E for text-out, but I use my own
draw routines for it anyway.
I'm comfortable with starting with video modi which support text output, and
wait with drawing text myself for a later date/project.
yeah, my preferred text-mode was/is mode 0003 [BIOS default].
Post by R.Wieser
Post by wolfgang kern
INT 10 - VIDEO - Realtek RTVGA - SET USER GRAPHICS CHARACTERS
and I had to use this font changer because as a hex-code programmer with
worn eyes I too often misread "Oh" vs Zero and B vs 8.
I still use this hard edged font B/D/O and zero with dot inside in all
modes. And mY 165 KESYS clients like it as well.
__
wolfgang
R.Wieser
2024-02-25 09:55:51 UTC
Permalink
wolfgang,
Post by wolfgang kern
try INT 0x10, AX=0x4F02, BX=0x0100
and ES:DI could need to be 0xFFFF:FFFF to ignore CRT setup.
I just came across this webpage :

https://wiki.osdev.org/VESA_Video_Modes

Somewhere halfway down it says "Set the bit 11 of BX to instruct the BIOS to
use the passed CRTCInfoBlock structure".

IOW, its not about what ES:DI itself contains which determines if the 'CRT
setup' datablock is used.

Phew, I did set, as a test, a few VESA video modes (and expected it to
crash), and couldn't figure out when that that "CRTC information block" was
used (erased it with '-', which was unchanged on return).

I must say that VESA, or rather its support, is nasty. I have a 'puter
which doesn't have (VESA) BIOS support for drawing text and/or pixels on any
modus, and I got another one which supports it on all of them. Not funny
when you want to create a simple, portable DOS program.

By the way: I do not see, in RBIL, any INT 0x10 function to plot a 256+
color pixel. Did I overlook something ?

Regards,
Rudy Wieser.
wolfgang kern
2024-02-25 12:26:11 UTC
Permalink
Post by R.Wieser
wolfgang,
Post by wolfgang kern
try INT 0x10, AX=0x4F02, BX=0x0100
and ES:DI could need to be 0xFFFF:FFFF to ignore CRT setup.
https://wiki.osdev.org/VESA_Video_Modes
Somewhere halfway down it says "Set the bit 11 of BX to instruct the BIOS to
use the passed CRTCInfoBlock structure".
IOW, its not about what ES:DI itself contains which determines if the 'CRT
setup' datablock is used.
yes, that's right, too many years passed since I wrote my code for this.
and I never used this CRT Controls (I used EDID to get info on monitor).
Post by R.Wieser
Phew, I did set, as a test, a few VESA video modes (and expected it to
crash), and couldn't figure out when that that "CRTC information block" was
used (erased it with '-', which was unchanged on return).
I must say that VESA, or rather its support, is nasty. I have a 'puter
which doesn't have (VESA) BIOS support for drawing text and/or pixels on any
modus, and I got another one which supports it on all of them. Not funny
when you want to create a simple, portable DOS program.
yeah, portability was/is a nightmare. therefor I sold my OS only
together with a complete PC (only a few hardware versions) all assembled
by myself.

when I remember my first attempts to show colored graphic on these
four-plan CGA-cards, I'm really happy that we got VESA.
Post by R.Wieser
By the way: I do not see, in RBIL, any INT 0x10 function to plot a 256+
color pixel. Did I overlook something ?
isn't AL large enough ? :)

INT 10 - VIDEO - WRITE GRAPHICS PIXEL
AH = 0Ch
BH = page number
AL = pixel color
if bit 7 set, value is XOR'ed onto screen except in 256-color modes
CX = column
DX = row
Return: nothing
Desc: set a single pixel on the display in graphics modes
Notes: valid only in graphics modes
BH is ignored if the current video mode supports only one page
SeeAlso: AH=0Dh,AH=46h

__
wolfgang
R.Wieser
2024-02-25 18:43:33 UTC
Permalink
wolfgang,
Post by wolfgang kern
Post by R.Wieser
By the way: I do not see, in RBIL, any INT 0x10 function to plot a 256+
color pixel. Did I overlook something ?
isn't AL large enough ? :)
Not to me it isn't - I want Moar!!! :-)
Post by wolfgang kern
INT 10 - VIDEO - WRITE GRAPHICS PIXEL
AH = 0Ch
BH = page number
AL = pixel color
if bit 7 set, value is XOR'ed onto screen except in 256-color modes
One of my 'puters has got a number of 16 and 32 BPP VESA modi available
(modes 0x20...0x22 are 32 BPP). It would be nice if I could actually use
them.

I just tried to draw a (diagonal) line in a 32 BPP mode with AL=0xFF, but
all I get is (understandable) blue.

Regards,
Rudy Wieser
wolfgang kern
2024-02-25 22:47:23 UTC
Permalink
Post by R.Wieser
Post by wolfgang kern
Post by R.Wieser
By the way: I do not see, in RBIL, any INT 0x10 function to plot a 256+
color pixel. Did I overlook something ?
isn't AL large enough ? :)
Not to me it isn't - I want Moar!!! :-)
Post by wolfgang kern
INT 10 - VIDEO - WRITE GRAPHICS PIXEL
AH = 0Ch
BH = page number
AL = pixel color
if bit 7 set, value is XOR'ed onto screen except in 256-color modes
One of my 'puters has got a number of 16 and 32 BPP VESA modi available
(modes 0x20...0x22 are 32 BPP). It would be nice if I could actually use
them.
I just tried to draw a (diagonal) line in a 32 BPP mode with AL=0xFF, but
all I get is (understandable) blue.
the drawing method for (odd) 15 and 16 bit pixels would be similar to
16+16 color text-mode. [alternating Hi/Lo bytes]
[32 bit would need a set of four consecutive bytes]

but because pixel drawing with INT10 is awful slow, almost nobody do.
Direct screen write to Video-Memory was the way to go since the begin.
that's why they added (1977 ?) the ES-register to access 0xA0000...

But most VESA modes use LFB (Linear Frame Buffer) which is usually at
3rd GB and need either PM32 or UNREAL to access it at all.

after I calculated equalized HUE values for a 256 color palette,
I arranged DAC RGB-values (stored as 32 bit even only 24 bit used)
to form a set of 64 gray plus 192 rainbow colors.

This let me show astonishing good images with only 8 bit/pixel.
And by using 32bit registers I can draw four pixels at once.

I finally (1992) added 32 bit RGB_A support to my routines, but mainly
used just my 8 bit palette,
So I never supported 15 and 16 bit color depth.
__
wolfgang
R.Wieser
2024-02-26 07:30:24 UTC
Permalink
wolfgang,
Post by wolfgang kern
the drawing method for (odd) 15 and 16 bit pixels would be similar
to 16+16 color text-mode. [alternating Hi/Lo bytes]
[32 bit would need a set of four consecutive bytes]
Thats what I thought of too, but the diagonal (X=Y) line I did draw (for
testing purposes) was, in 32 bpp mode, the same color everywhere. Which
makes sense, but seems to mean that I can only touch byte 0 (blue), but not
bytes 1,2 and 3.
Post by wolfgang kern
but because pixel drawing with INT10 is awful slow, almost nobody
do Direct screen write to Video-Memory was the way to go since the
begin.that's why they added (1977 ?) the ES-register to access 0xA0000...
The ES registers existence is a direct result from wanting to do direct
video-memory access ? Thats a new one to me. I always though it was a
logical conclusion of the need for larger memory models (with 64K+ data
segments).
Post by wolfgang kern
But most VESA modes use LFB (Linear Frame Buffer) which is usually at 3rd
GB and need either PM32 or UNREAL to access it at all.
I know of that way to do it myself (and you mentioned it once or twice), but
was hoping that BIOS support for a certain VESA video mode also meant that
there would be a INT 10h method to plot such 256+ color pixels. You know,
trying to do the minimum ammount of work to get the largest result. :-)
Post by wolfgang kern
after I calculated equalized HUE values for a 256 color palette,
I arranged DAC RGB-values (stored as 32 bit even only 24 bit used)
to form a set of 64 gray plus 192 rainbow colors.
Yep, I've found and used such an array of DAC colors too. Was a bit
surprised to see multiple black colors at the end of the list. Assumed it
was for private use..
Post by wolfgang kern
This let me show astonishing good images with only 8 bit/pixel.
:-) I think that 8 bpp will do fine for me too. I'm currently just trying
to inventorize what all I can use (and how). You know, the 'information
gathering' phase.

To be honest, being able to use a higher resolution (than 320x200) is more
important to me than being able to use 16 or 32 bit colors.

Thanks for the info.

Regards,
Rudy Wieser
wolfgang kern
2024-02-26 08:02:00 UTC
Permalink
Post by R.Wieser
wolfgang,
Post by wolfgang kern
the drawing method for (odd) 15 and 16 bit pixels would be similar
to 16+16 color text-mode. [alternating Hi/Lo bytes]
[32 bit would need a set of four consecutive bytes]
Thats what I thought of too, but the diagonal (X=Y) line I did draw (for
testing purposes) was, in 32 bpp mode, the same color everywhere. Which
makes sense, but seems to mean that I can only touch byte 0 (blue), but not
bytes 1,2 and 3.
? have you tried an iterated sequence of:
AL=00 INT10
AL=ff INT10
AL=00 INT10
Al=80 INT10
Post by R.Wieser
Post by wolfgang kern
but because pixel drawing with INT10 is awful slow, almost nobody
do Direct screen write to Video-Memory was the way to go since the
begin.that's why they added (1977 ?) the ES-register to access 0xA0000...
The ES registers existence is a direct result from wanting to do direct
video-memory access ? Thats a new one to me. I always though it was a
logical conclusion of the need for larger memory models (with 64K+ data
segments).
exact, video-RAM were often apart add-ons in the range 8000..BFFF
Post by R.Wieser
Post by wolfgang kern
But most VESA modes use LFB (Linear Frame Buffer) which is usually at 3rd
GB and need either PM32 or UNREAL to access it at all.
I know of that way to do it myself (and you mentioned it once or twice), but
was hoping that BIOS support for a certain VESA video mode also meant that
there would be a INT 10h method to plot such 256+ color pixels. You know,
trying to do the minimum ammount of work to get the largest result. :-)
minimum work would be after you decided to write direct to screen :)
Post by R.Wieser
Post by wolfgang kern
after I calculated equalized HUE values for a 256 color palette,
I arranged DAC RGB-values (stored as 32 bit even only 24 bit used)
to form a set of 64 gray plus 192 rainbow colors.
Yep, I've found and used such an array of DAC colors too. Was a bit
surprised to see multiple black colors at the end of the list. Assumed it
was for private use..
I use 0x20 as BLACK and 0x00 as transparent (keep what's there).
Post by R.Wieser
Post by wolfgang kern
This let me show astonishing good images with only 8 bit/pixel.
:-) I think that 8 bpp will do fine for me too. I'm currently just trying
to inventorize what all I can use (and how). You know, the 'information
gathering' phase.
yes, been there... decades ago.
Post by R.Wieser
To be honest, being able to use a higher resolution (than 320x200) is more
important to me than being able to use 16 or 32 bit colors.
Thanks for the info.
welcome
__
wolfgang
R.Wieser
2024-02-26 10:45:20 UTC
Permalink
wolfgang,
Post by wolfgang kern
AL=00 INT10
AL=ff INT10
AL=00 INT10
Al=80 INT10
Ah, I didn't think of that one. Alas, I'm getting a light-blue line.
Post by wolfgang kern
exact, video-RAM were often apart add-ons in the range 8000..BFFF
True. But the video-bios code could just point DS to that (64KByte) area
and than do its thing. AFAICS no ES needed.
Post by wolfgang kern
minimum work would be after you decided to write direct to screen :)
The last time I looked VESA doesn't /need/ to support linear mode, which
would mean I would be forced to support bank-switched mode too ... with its
granularity and whole shebang. Full support for every possibility would
need quite a bit of code. :-(

Regards,
Rudy Wieser
wolfgang kern
2024-02-26 18:42:01 UTC
Permalink
On 26/02/2024 11:45, R.Wieser wrote:
...

how about:
CX=0000 DX=0008
iterate:
AL=ff INT10 INC cx
AL=ff INT10 INC cx
AL=ff INT10 INC cx
Al=ff INT10 INC cx
cmp CX,max JB iterate
Post by R.Wieser
Ah, I didn't think of that one. Alas, I'm getting a light-blue line.
light blue coz last write was 80.
Post by R.Wieser
Post by wolfgang kern
exact, video-RAM were often apart add-ons in the range 8000..BFFF
True. But the video-bios code could just point DS to that (64KByte) area
and than do its thing. AFAICS no ES needed.
it works as DS->ES because Video ROM cannot use CS as data base and
stack space was kept pretty small back then.
look at: MOVS LODS STOS and see which segment registers they imply.
Post by R.Wieser
Post by wolfgang kern
minimum work would be after you decided to write direct to screen :)
The last time I looked VESA doesn't /need/ to support linear mode, which
would mean I would be forced to support bank-switched mode too ... with its
granularity and whole shebang. Full support for every possibility would
need quite a bit of code. :-(
yes, we don't need to support every possible mode,
I just use text mode 0003 and only all the 2^n aligned 8/32 bit.
so my list contain less than 16 modes.

banking graphic is a PITA and slows down everything.
8 bit modes are available with 32 or 64KB at A0000/A8000
32 bit modes usually use LFB. I use all my graphic modes with LFB.
__
wolfgang
R.Wieser
2024-02-27 08:55:58 UTC
Permalink
wolfgang,
[snip]

The diagonal line I used to test with should than have shown multiple
colors, which it didn't. I also tried that same diagonal line starting at
1,0 (to see if I would than be accessing the 'Green' byte. Alas, the result
was the same hard-blue colored line.

I also thought of using DI and BL for the other three color bytes. Nope,
doesn't work. :-\

Ah, DI could be used as a pointer to a color structure ...

The biggest problem with these experiments is that what we're trying isn't
described/documented (might work for one video-card but not another).
Post by wolfgang kern
Post by R.Wieser
Ah, I didn't think of that one. Alas, I'm getting a light-blue line.
light blue coz last write was 80.
Yep.
Post by wolfgang kern
Post by R.Wieser
True. But the video-bios code could just point DS to that (64KByte) area
and than do its thing. AFAICS no ES needed.
it works as DS->ES because Video ROM cannot use CS as data base and stack
space was kept pretty small back then.
??? I don't get that "because" reasoning, sorry.

I think you misunderstood me : I tried to imagine an ES-less processor and
see if that would make it impossible for a video-BIOS to function. I don't
think so, as its (thanwhile) video-memory space was just 64 KByte.
Post by wolfgang kern
look at: MOVS LODS STOS and see which segment registers they imply.
I know, I know. :-)

But thats what we *have*. The question is, in regard to the (thanwhile)
video-card, if we *needed* it - supporting your claim that "that's why they
added (1977 ?) the ES-register to access 0xA0000...".

And than I have to take the "added" in the above as "initially designed", as
it has been part of the x86 from the very beginning.

The logic that the ES register would have been "added" just so a program
could do some direct video-memory access doesn't sound as well as that it
was to enable programs to handle "huge" ammounts of program data.

Its much more likely that programmers realized that, with the aid of the ES
register, they could do directly access video-memory and subsequently did
so.

But it has a bit of the "which came first, the chicken or the egg ?" smell
to it.

Than again, it might be similar to where the term "bug" has been said to
origionate from (a literal bug stuck in one of the contacts of a thenwhile
relays-driven computer causing its results to be wrong)
Post by wolfgang kern
yes, we don't need to support every possible mode,
While that might be a quite logical choice (covering most of the current
cases), to me it means that a VESA using program might not run on every VESA
offering video-card.

... and as I'm in the "discovery phase" ...
Post by wolfgang kern
banking graphic is a PITA and slows down everything.
Tell me about it ... :-(

It was the reason I, years ago, stopped trying to use VESA - that and the
"video-modi numbers mean nothing, you have to search if your video-cards
VESA supports a certain resolution and color-depth" approach.

VESA has been designed by a commission (with little eye to practical
application), and it shows. :-\
Post by wolfgang kern
8 bit modes are available with 32 or 64KB at A0000/A8000
When checking the different possible VESA video-modi (0x4F01) I see an
0xA000 value at the "start segment of window A" offset (0x08) - but its
description says "0000h if not supported". No idea who/what should support
it (and when!) though (RBIL doesn't say). My /guess/ is that its related to
the "bank switching" capability, but who knows ...

But yes, it would give an easy (as long as its supported :-) ) extra 8bpp
640x480 and 800x600 modi (1024x768 would already be too big). I didn't think
of that.

And funny, the "physical address of linear video buffer" value (at offset
0x28) doesn't mention an "if (not) supported" clause (in RBIL).
Post by wolfgang kern
32 bit modes usually use LFB. I use all my graphic modes with LFB.
About that (LFB), I can imagine that under DOS writing/reading that
video-memory space won't be a problem (no GDT problems). I could imagine
its a bit different when I try to do the same under a Windows "command
console" (XPsp3). Do you have any insights to that ?

Regards,
Rudy Wieser
R.Wieser
2024-02-27 09:54:19 UTC
Permalink
Post by R.Wieser
But yes, it would give an easy (as long as its supported :-) ) extra 8bpp
640x480 and 800x600 modi (1024x768 would already be too big). I didn't
think of that.
Whoops! Scratch that. Its below 64, but both of the above result in 6
digits, not 5. :-|

In that case, which modi did you think of ?

Yes, I could use an 800x600 1bpp mode, but although I said that I do not
really need 256+ colors, just two colors / monochrome is the other side of
the range. :-)

Regards,
Rudy Wieser
wolfgang kern
2024-02-27 11:05:35 UTC
Permalink
On 27/02/2024 09:55, R.Wieser wrote:

are you sure to set a 32 bit mode ?

when I draw a pixel to screen in 32 bit mode I can be:
MOV [ES: r/m],RAX
or just alter individual bytes.

...[AFAICS no ES needed]
Post by R.Wieser
Post by wolfgang kern
it works as DS->ES because Video ROM cannot use CS as data base and stack
space was kept pretty small back then.
??? I don't get that "because" reasoning, sorry.
VBIOS resides in a ROM and it would need two apart DS for moving data
from user space to video RAM :)
Post by R.Wieser
I think you misunderstood me : I tried to imagine an ES-less processor and
see if that would make it impossible for a video-BIOS to function. I don't
think so, as its (thanwhile) video-memory space was just 64 KByte.
yes, 64 KB. this spans a whole segment,
so NO, DS cannot be shared between video RAM and user data.

but you could ransack EBDI at 0x98000 to share 32KB parts.
Post by R.Wieser
And than I have to take the "added" in the above as "initially designed", as
it has been part of the x86 from the very beginning.
OK, I said added. Added to the design of 8086.
intel COP4, 8080, 8085 and also Zilog Z80 didn't have segment-registers.
...
Post by R.Wieser
Than again, it might be similar to where the term "bug" has been said to
origionate from (a literal bug stuck in one of the contacts of a thenwhile
relays-driven computer causing its results to be wrong)
:)
Post by R.Wieser
Post by wolfgang kern
yes, we don't need to support every possible mode,
While that might be a quite logical choice (covering most of the current
cases), to me it means that a VESA using program might not run on every VESA
offering video-card.
that's why there is the INT10_4F_00.
an OS has to check for available graphic modes which fit the monitor.
Post by R.Wieser
... and as I'm in the "discovery phase" ...
adventuring hardware can be funny :) I like that
.
Post by R.Wieser
Post by wolfgang kern
banking graphic is a PITA and slows down everything.
Tell me about it ... :-(
always needs to tell the video card the new start address
recalculation of x,y positions are inevitable for every dot.
then think about a diagonal line crossing 2 or even 3 banks.
Post by R.Wieser
It was the reason I, years ago, stopped trying to use VESA - that and the
"video-modi numbers mean nothing, you have to search if your video-cards
VESA supports a certain resolution and color-depth" approach.
VESA has been designed by a commission (with little eye to practical
application), and it shows. :-\
Post by wolfgang kern
8 bit modes are available with 32 or 64KB at A0000/A8000
When checking the different possible VESA video-modi (0x4F01) I see an
0xA000 value at the "start segment of window A" offset (0x08) - but its
description says "0000h if not supported". No idea who/what should support
it (and when!) though (RBIL doesn't say). My /guess/ is that its related to
the "bank switching" capability, but who knows ...
I'd forget about these A and B windows.
(2*64K isn't enough, 1024*768,256 needs 12*64KB)

from my KESYS docs (my OS ignore all that's not mentioned here):
-----------
int10_4F_01
word [es:di]
bit 7 LINEAR mode supported (capital if set)
bit 4 GRAPHIC/text
bit 3 COLOR/mono
bit 0 HW supported

word [es:di+0x12] X-width
word [es:di+0x14] Y-width ;I actually read/CMP 4 bytes at once.

byte [es:di+0x19] bits/pixel
dword[es:di+0x28] FLAT pointer start address of LFB
dword[es:di+0x3E] max. pixel clock (Hz)
---------
Post by R.Wieser
But yes, it would give an easy (as long as its supported :-) ) extra 8bpp
640x480 and 800x600 modi (1024x768 would already be too big). I didn't think
of that.
1024*768*256 is my favorite resolution and it uses LFB (in 3rd GB)
Post by R.Wieser
And funny, the "physical address of linear video buffer" value (at offset
0x28) doesn't mention an "if (not) supported" clause (in RBIL).
Post by wolfgang kern
32 bit modes usually use LFB. I use all my graphic modes with LFB.
About that (LFB), I can imagine that under DOS writing/reading that
video-memory space won't be a problem (no GDT problems).
yes as long it's in 1st MB aka 0A0000 [320*200√ but not 512*384].
no, you need GDT if you want UNREAL mode.
Post by R.Wieser
I could imagine
its a bit different when I try to do the same under a Windows "command
console" (XPsp3). Do you have any insights to that ?
never tried, what I heard VMEM could be virtual/emulated (like INT10)
__
wolfgang
R.Wieser
2024-03-04 14:39:34 UTC
Permalink
wolfgang,

My apologies for the late reply, my attention was pulled elsewhere ...
Post by wolfgang kern
are you sure to set a 32 bit mode ?
I've been using vesa mode 0x20, which is reported as being 320x200x32.
Post by wolfgang kern
MOV [ES: r/m],RAX
or just alter individual bytes.
Thats something to try, /but only after/ I have done my stinking best to
figure out the promised "bios support" as returned by INT 0x10, AX=0x4201 in
the "mode attributes" (first two bytes).
Post by wolfgang kern
VBIOS resides in a ROM and it would need two apart DS for moving
data from user space to video RAM :)
True. But (the thanwhile) BIOS video output (char or graphical) certainly
doesn't.
Post by wolfgang kern
yes, 64 KB. this spans a whole segment,
so NO, DS cannot be shared between video RAM and user data.
I didn't say anything about /sharing/ that DS segment. Quite the opposite
actually.

Just ask yourself : could a 8086-era PC output text to the screen using INT
0x10 calls ? If so, it didn't need a block move from user to video memory.
Hence, the existence of the ES register is unlikely to have been dictated by
it.

... and I'm sure that someone like you could come up with a way to switch
the DS register between a read (from user memory) and subsequent write (to
video memory).
Post by wolfgang kern
OK, I said added. Added to the design of 8086.
I think I may assume that the processor was designed *before* the hardware
it was used on. And that includes the video card. If that is so you have
a chronology problem. :-)
Post by wolfgang kern
Post by R.Wieser
While that might be a quite logical choice (covering most of the current
cases), to me it means that a VESA using program might not run on every
VESA offering video-card.
that's why there is the INT10_4F_00.
an OS has to check for available graphic modes which fit the monitor.
Yes, and than you see that none of the VESA video-modi offered by your
current 'puter matches what you wrote your program for*, which means that it
can't, won't run.

* Write it for lineair memory usage and not having the desired resolution
supporting it. Writing for bank-switched mode and not having the desired
resolution supporting it. Writing for BIOS writes not having the desired
resolution supporting it.

IOW, there seems to be no minimum "this will always work" support for it.
Which forces you to write the program to support *all* methods, and have it
select the apropriate method at runtime.
Post by wolfgang kern
I'd forget about these A and B windows.
(2*64K isn't enough, 1024*768,256 needs 12*64KB)
I do not even have an idea wat what those "windows" are for. But I do know
that, the way RBIL put it, they could not be present at all.
Post by wolfgang kern
bit 7 LINEAR mode supported (capital if set)
Same here

RBIL: 6 bank-switched mode *not* supported

Yeah, you /could/ get a mode with bit 6 set and bit 7 clear. Fun times. :-(
Post by wolfgang kern
bit 4 GRAPHIC/text
No indication if a certain graphics mode supports text output ... (I do not
consider that to be a given).
Post by wolfgang kern
bit 0 HW supported
I have *no* idea why this bit even exists. Why does int10_4F_01 return
succes if the mode unusable for the video card ? It doesn't make any sense.
Post by wolfgang kern
dword[es:di+0x28] FLAT pointer start address of LFB
Here (on one 'puter) it returns a 0xF8000000 address for all VESA modi.
Post by wolfgang kern
yes as long it's in 1st MB aka 0A0000 [320*200? but not 512*384].
:-) In that case I will use a BIOS video mode, thankyouverymuch.
Post by wolfgang kern
no, you need GDT if you want UNREAL mode.
I don't *want* it, but I need(?) something to be able to read-write in that
lineair memory. Or can I just load EDI with whatever is the "physical
address of linear video buffer" field and start writing ?

Regards,
Rudy Wieser
wolfgang kern
2024-03-04 16:56:02 UTC
Permalink
On 04/03/2024 15:39, R.Wieser wrote:
...
Post by R.Wieser
Just ask yourself : could a 8086-era PC output text to the screen using INT
0x10 calls ? If so, it didn't need a block move from user to video memory.
Hence, the existence of the ES register is unlikely to have been dictated by
it.
I'm not good with history, X86 XT may already have used INT10.
the older ones had their graphic-memory within reach, so no ES needed.
Post by R.Wieser
... and I'm sure that someone like you could come up with a way to switch
the DS register between a read (from user memory) and subsequent write (to
video memory).
no way! this would make it awful slow aka unusable.
Post by R.Wieser
Post by wolfgang kern
OK, I said added. Added to the design of 8086.
I think I may assume that the processor was designed *before* the hardware
it was used on. And that includes the video card. If that is so you have
a chronology problem. :-)
development of CPUs and graphic cards were/and still are independent.
so we saw a lot of combined variations in the past.
we have now a standard with VESA, all these SVGA,XVGA.. became obsolete.
Post by R.Wieser
Post by wolfgang kern
Post by R.Wieser
While that might be a quite logical choice (covering most of the current
cases), to me it means that a VESA using program might not run on every
VESA offering video-card.
that's why there is the INT10_4F_00.
an OS has to check for available graphic modes which fit the monitor.
Yes, and than you see that none of the VESA video-modi offered by your
current 'puter matches what you wrote your program for*, which means that it
can't, won't run.
who writes graphic programs for only one resolution ...?
just look what all the games offer: available resolution options.
Post by R.Wieser
* Write it for lineair memory usage and not having the desired resolution
supporting it. Writing for bank-switched mode and not having the desired
resolution supporting it. Writing for BIOS writes not having the desired
resolution supporting it.
IOW, there seems to be no minimum "this will always work" support for it.
Which forces you to write the program to support *all* methods, and have it
select the appropriate method at runtime.
old age game developers had this problem too.
so they offered just 320*240 4 colors or mono.

I myself decided for given standards:
BIOS text mode 0003 1024x768 (16+16 colors)[direct at 0xB8000]
wide used graphic mode 1024x768,256 colors [direct at 15th MB]
changed to LFB after VESA Ws available.
Post by R.Wieser
Post by wolfgang kern
bit 7 LINEAR mode supported (capital if set)
Same here
RBIL: 6 bank-switched mode *not* supported
Yeah, you /could/ get a mode with bit 6 set and bit 7 clear. Fun times. :-(
haven't seen any.
Post by R.Wieser
Post by wolfgang kern
bit 4 GRAPHIC/text
No indication if a certain graphics mode supports text output ...
(I do not consider that to be a given).
yes, but you can use the (ugly) ROM font for your text draw.
Post by R.Wieser
Post by wolfgang kern
bit 0 HW supported
I have *no* idea why this bit even exists. Why does int10_4F_01 return
succes if the mode unusable for the video card ? It doesn't make any sense.
all of INT10 routines are part of the Video-Bios which is Hardware(ROM).
Post by R.Wieser
Post by wolfgang kern
dword[es:di+0x28] FLAT pointer start address of LFB
Here (on one 'puter) it returns a 0xF8000000 address for all VESA modi.
yep, that's the Address of first top/left pixel
mine show 0xC800_0000 and on another 0xF000_0000
windoze show this values for current mode in "device manager"[resources]
Post by R.Wieser
Post by wolfgang kern
yes as long it's in 1st MB aka 0A0000 [320*200 ok but not 512*384].
:-) In that case I will use a BIOS video mode, thankyouverymuch.
Post by wolfgang kern
no, you need GDT if you want UNREAL mode.
I don't *want* it, but I need(?) something to be able to read-write in that
lineair memory. Or can I just load EDI with whatever is the "physical
address of linear video buffer" field and start writing ?
no, you need to either enter PM or run UNREAL-mode.
if you can read the GDT entries, you might find one that fits.

PUSH xx ;the found FLAT DATA selector
POP ES ;
REP MOVS ;or REP STOS (b/w/d)

If you lucky and run your DOS in an emulated environment it may already
be in UNREAL mode.
My last recent analysis [2014] of a VBIOS shows that it uses UNREAL to
test its memory during RM16 start-up.
__
wolfgang
R.Wieser
2024-03-04 21:34:44 UTC
Permalink
wolfgang,
Post by wolfgang kern
Post by R.Wieser
... and I'm sure that someone like you could come up with a way to switch
the DS register between a read (from user memory) and subsequent write (to
video memory).
no way! this would make it awful slow aka unusable.
"awful slow" as compared to ....? If there would be no ES register and
the DS register would be all you had, you would be glad to be able to do it
that way - as the other methods would likely be even slower.

Just remember about how the early "protected mode" switching-back had to be
done my telling the keyboard controller to pull a (kind of) "reset" line
low, and we where glad to be able to do it - nonwithstanding it being rather
slow *in comparision to* the later versions, which could do both the
switching to and back with a command in the processor itself.
Post by wolfgang kern
development of CPUs and graphic cards were/and still are independent.
When you claim the ES register was added to enable direct video-ram writes
from user space they where not /that/ independantly developped. :-p

Mind you, I do not say the "ES exists because of direct video writes" story
cannot be true, just that I think its much more likely that the designers of
the processor wanted to enable big data moves, causing the possibility of
direct video read/writes as a freebie.
Post by wolfgang kern
we have now a standard with VESA, all these SVGA,XVGA.. became obsolete.
A standard which is pretty-much unusable *unless* you write support for
every possible configuration (no lineair support, no bank-switch support, no
BIOS support or any combination thereof) yourself.

IOW, from my POV that VESA standard is a bad one - due to lack of a "minimum
requirements".

I don't care that a certain VESA video mode could run much faster with some
nifty code. I *do* care that I cannot put *anything* on my screen when I
choose an available VESA video mode.
Post by wolfgang kern
who writes graphic programs for only one resolution ...?
I guess you never met a webdesigner. :-)
Post by wolfgang kern
just look what all the games offer: available resolution options.
Which ones ? Those of the last decade (supported by Windows) or those of
the VESA era ?

But no, its not about resolotiuons or even color depths, but about that
there are three methods to put pixels on the screen, and none of them need
to be supported by the video-card you currently have.

And that ofcourse means yadayadayada (I mentioned it once or twice before)
Post by wolfgang kern
old age game developers had this problem too.
so they offered just 320*240 4 colors or mono.
And so do you, if I may take you on your word that, using VESA, you only
support a shortlist - and only the lineair memory method.
Post by wolfgang kern
Post by R.Wieser
RBIL: 6 bank-switched mode *not* supported
Yeah, you /could/ get a mode with bit 6 set and bit 7 clear. Fun times. :-(
haven't seen any.
Lucky you I guess.
Post by wolfgang kern
Post by R.Wieser
Post by wolfgang kern
bit 4 GRAPHIC/text
No indication if a certain graphics mode supports text output ...
(I do not consider that to be a given).
yes, but you can use the (ugly) ROM font for your text draw.
Thats the solution to the problem, not the problem itself

Pray tell, how do you know when to apply that solution ? Or are you just
ignoring BIOS text-output support for all the VESA video modi and always
draw your own text ? Thats quite a waste of time, energy and code. :-|
Post by wolfgang kern
Post by R.Wieser
Post by wolfgang kern
bit 0 HW supported
I have *no* idea why this bit even exists. Why does int10_4F_01 return
succes if the mode unusable for the video card ? It doesn't make any sense.
all of INT10 routines are part of the Video-Bios which is Hardware(ROM).
Huh ? INT10 routines are at best firmware, otherwise software. In no way
or shape will it ever be hardware.

And I'm not talking about "BIOS output supported" (which has its own bit at
2), but simply if I can switch to a certain video mode and expect it to
work. If a set bit 0 indicates that "mode supported by present hardware
configuration" than I think I may conclude that when that bit is cleared
that that video mode *isn't* supported by present hardware configuration,
and as such enabeling it will fail to result in anything usable. Hence, why
return such a video mode to begin with ?

Or, if you want the question differently (less laden), what is a video mode
which does *not* have support by present hardware configuration used for ?
Post by wolfgang kern
Post by R.Wieser
I don't *want* it, but I need(?) something to be able to read-write in that
lineair memory. Or can I just load EDI with whatever is the "physical
address of linear video buffer" field and start writing ?
no, you need to either enter PM or run UNREAL-mode.
....
Post by wolfgang kern
If you lucky and run your DOS in an emulated environment it may already be
in UNREAL mode.
That's the information/confirmation I was looking for. Now all I have to
do is to figure out how to find/write some GDT changing code that will work
in both environments. :-)

Regards,
Rudy Wieser
wolfgang kern
2024-03-05 08:14:22 UTC
Permalink
On 04/03/2024 22:34, R.Wieser wrote:

[snipped argue about ES] we an assume it's there :)
Post by R.Wieser
IOW, from my POV that VESA standard is a bad one - due to lack of a "minimum
requirements".
the OS should/could minimize user programmers requirements.
mine create a list of "OS-supported graphic modes" (max.32 modes)
filtered by monitor capabilities and my personal preferences.
Post by R.Wieser
I don't care that a certain VESA video mode could run much faster with some
nifty code. I *do* care that I cannot put *anything* on my screen when I
choose an available VESA video mode.
Post by wolfgang kern
who writes graphic programs for only one resolution ...?
I guess you never met a webdesigner. :-)
web folks use Java rely on OS given capabilities and don't talk direct
to the graphic cards controller nor to the memory.
Post by R.Wieser
Post by wolfgang kern
just look what all the games offer: available resolution options.
Which ones ?
Those of the last decade (supported by Windows) or those of
the VESA era ?
all mainstream PC-games from last four decades.
pre-VESA games used SVGA/VGA options.

...
Post by R.Wieser
And so do you, if I may take you on your word that, using VESA, you only
support a shortlist - and only the linear memory method.
yes, I support only this modes:
text 0003 80x25,16+16 also set with INT10 during RM16 boot-up
direct write to 0xb8000..
if available, graphic 8 and 32 bit color depth
used by OS: 512x384, 1024x768, 1280x960, 1152x768, 1920x1080
can be set: 320x240*, 400x300*, 640x480, 800x600, 1400x1050, 1600x1200
* these use 0x0A0000..
Post by R.Wieser
Post by wolfgang kern
Post by R.Wieser
Post by wolfgang kern
bit 4 GRAPHIC/text
No indication if a certain graphics mode supports text output ...
(I do not consider that to be a given).
yes, but you can use the (ugly) ROM font for your text draw.
Thats the solution to the problem, not the problem itself
Pray tell, how do you know when to apply that solution ?
Or are you just ignoring BIOS text-output support for all the VESA
video modi and always draw your own text ?
user can optional use the ROM font (one of 16 options)
yes, I ignore it because INT_10 isn't available in PM32.
yes, except text mode use int10_0E during boot-up.
Post by R.Wieser
Thats quite a waste of time, energy and code. :-|
took me lesser than you may think.
Post by R.Wieser
Post by wolfgang kern
Post by R.Wieser
Post by wolfgang kern
bit 0 HW supported
I have *no* idea why this bit even exists. Why does int10_4F_01 return
succes if the mode unusable for the video card ? It doesn't make any sense.
all of INT10 routines are part of the Video-Bios which is Hardware(ROM).
Huh ? INT10 routines are at best firmware, otherwise software. In no way
or shape will it ever be hardware.
you can believe that ROM belong to Hardware!
Post by R.Wieser
... Hence, why return unusable?
Or, if you want the question differently (less laden), what is a video mode
which does *not* have support by present hardware configuration used for ?
vendors may save time/money by only having one list for a whole family.

...
[UNREAL mode...]
Post by R.Wieser
That's the information/confirmation I was looking for. Now all I have to
do is to figure out how to find/write some GDT changing code that will work
in both environments. :-)
you want me to post such a trivial task ?
SGDT [16byte buffer] ... ;resulting in address and limit of GDT
... scan GDT entries for FLAT DATA until found
put the found descriptor into DX
if none found then stop here and ask me again :)

CLI ;vital
MOV eax, CR0 ;0F 20 C0
OR AL,1
MOV CR0,eax ;set, but don't enter PM ;0F 22 C0
MOV ES,DX
AND AL,0xFE
MOV CR0,EAX ;leave PM
STI
__
wolfgang
R.Wieser
2024-03-05 11:05:57 UTC
Permalink
wolfgang,
Post by wolfgang kern
the OS should/could minimize user programmers requirements.
No, not the OS. The makers of VESA video card. They know their product the
best. And that thing doesn't have a BIOS ROM for nothing.
Post by wolfgang kern
web folks use Java rely on OS given capabilities and don't talk direct to
the graphic cards controller nor to the memory.
....
Post by wolfgang kern
all mainstream PC-games from last four decades.
pre-VESA games used SVGA/VGA options.
I think you answered your own question there. Where VESA demands the
programmer to write all the support for the diferent video-modi, the PC-game
makers do not need to do any such thing, as everything is already there
(D3D, OpenGL).

... And they could not touch the video-card directly even if they wanted to.
Post by wolfgang kern
user can optional use the ROM font (one of 16 options)
You're not acknowledging the problem here : How does the programmer know
when that option /needs/ to be used ? Other than by eyeballing the screen
and noticing that no text appears I mean.
Post by wolfgang kern
yes, I ignore it because INT_10 isn't available in PM32.
yes, except text mode use int10_0E during boot-up.
I'm still trying to figure out if its worth my time to try to use VESA video
modi in general. Having to switch to protected/unreal mode changes the
playfield quite a bit. IIRC for starters you than can't run normal DOS
programs (read: TSR's) anymore.
Post by wolfgang kern
Post by R.Wieser
Thats quite a waste of time, energy and code. :-|
took me lesser than you may think.
You only did 33% of the full work. No wonder it didn't take you that long.
:-p
Post by wolfgang kern
you can believe that ROM belong to Hardware!
The ROM itself ? Yes. Its contents ? No.
Post by wolfgang kern
Post by R.Wieser
... Hence, why return unusable?
Or, if you want the question differently (less laden), what is a video mode
which does *not* have support by present hardware configuration used for ?
vendors may save time/money by only having one list for a whole family.
Please do tell me where that "HW support" bit comes from. If its static in
the list than any entry with that bit being zero should not be there to
begin with. If its dynamically checked (against the actual member of that
family) and its zero than the call itself could/should return a "failed"
status (even if the result buffer is changed).
Post by wolfgang kern
Post by R.Wieser
That's the information/confirmation I was looking for. Now all I have to
do is to figure out how to find/write some GDT changing code that will
work in both environments. :-)
you want me to post such a trivial task ?
The triviality of a task is always only discovered when looking from the
solution back to the problem/question (referred to as 20-20 vision). When
starting from the problem/question and not even having an idea in which way
to look however ....

And by the way, the next time I'm going to modify a GDT will be the first
one. :-)

But to make sure : such a GDT change works for both the DOS as well as a
Windows command console environments ?

Regards,
Rudy Wieser
wolfgang kern
2024-03-05 12:06:01 UTC
Permalink
On 05/03/2024 12:05, R.Wieser wrote:
...
Post by R.Wieser
Post by wolfgang kern
user can optional use the ROM font (one of 16 options)
You're not acknowledging the problem here : How does the programmer know
when that option /needs/ to be used ? Other than by eyeballing the screen
and noticing that no text appears I mean.
when ?
whenever a programmer want to use it instead of creating his own.
Post by R.Wieser
I'm still trying to figure out if its worth my time to try to use VESA video
modi in general. Having to switch to protected/unreal mode changes the
playfield quite a bit. IIRC for starters you than can't run normal DOS
programs (read: TSR's) anymore.
there isn't any issue with UNREAL mode other than some BIOS function may
crash on a FLAT ES.
But no problem if you use FS or GS for UNREAL access and leave ES alone.
and you can turn UNREAL ON/OFF any time.
Post by R.Wieser
You only did 33% of the full work. No wonder it didn't take you that long.
:-p
there were no need to support all and everything.
I did at least 100% of well working code with all features you can think
or dream of.
I'm sure my set of graphic options is far beyond your imagination.
only limited to usable features
[FN50_... "what's on screen" 256 main- plus 65535 sub-functions]
Post by R.Wieser
Post by wolfgang kern
you can believe that ROM belong to Hardware!
The ROM itself ? Yes. Its contents ? No.
you just like to argue..
FYI: the contents of a ROM are not "burned in" they are wired.
Post by R.Wieser
Post by wolfgang kern
Post by R.Wieser
... Hence, why return unusable?
vendors may save time/money by only having one list for a whole family.
Please do tell me where that "HW support" bit comes from. If its static in
the list than any entry with that bit being zero should not be there to
begin with. If its dynamically checked (against the actual member of that
family) and its zero than the call itself could/should return a "failed"
status (even if the result buffer is changed).
static.
a fail would stop the search loop and there are more after this.
Post by R.Wieser
Post by wolfgang kern
Post by R.Wieser
That's the information/confirmation I was looking for.
Now all I have to do is to figure out how to find/write
some GDT changing code that will work in both environments. :-)
two environments?
Post by R.Wieser
Post by wolfgang kern
you want me to post such a trivial task ?
The triviality of a task is always only discovered when looking from the
solution back to the problem/question (referred to as 20-20 vision). When
starting from the problem/question and not even having an idea in which way
to look however ....
so what I posted doesn't make any sense to you ?
then feel free to ask.
Post by R.Wieser
And by the way, the next time I'm going to modify a GDT will be the first
one. :-)
you will not need to modify the GDT nor any entry.
just scan for a FLAT DATA descriptor.
Post by R.Wieser
But to make sure : such a GDT change works for both the DOS as well as a
Windows command console environments ?
RM16 DOS doesn't use a GDT at all.
HIMEM needs A20 ON, EMM386 plays with mem-maps
BUT VideoBIOS need/uses a GDT. it otherwise couldn't access its own RAM.
And VM86 virtual mode uses its own GDT/LDT anyway.
__
wolfgang
R.Wieser
2024-03-05 08:48:10 UTC
Permalink
Post by R.Wieser
Post by wolfgang kern
Post by R.Wieser
RBIL: 6 bank-switched mode *not* supported
Yeah, you /could/ get a mode with bit 6 set and bit 7 clear. Fun times. :-(
haven't seen any.
Lucky you I guess.
Just as a bit of a "quick test" I got, from three computers, the list of (HW
supported) VESA video modi, to see what combinations of bit 7,6 and 2
(Lineair, bank-switch and BIOS support) I would get.

On one computer all video modes are graphics, supporting lineair adressing
and bank-switching. No BIOS support.
It doesn't support any mode below 0x30 (no BIOS video modi shadowing), and
doesn't support any 320x200 resolution.

The other two showed BIOS support and bank-switching for all text and
graphics modi, but only supported linear adressing for modi that need more
than 64KByte. Strange that those modi do still support the than also
un-needed bank-switching.

IOW :

I could write a program for a 320x200 video mode which would work on two of
them but not on the third.

I could write a program using a textmode which would work on two of them but
not on the third.

I could write a program supporting (read: depending on) lineair adressing,
but that would not work for every video mode.

And I just noticed that each 'puter has several modi supporting the same
resolution and color depth. No idea what that is good for.

Did I already mention that I think that VESA video modi are a nightmare ?
If not, than hereby. :-)

Regards,
Rudy Wieser
wolfgang kern
2024-03-05 10:55:53 UTC
Permalink
On 05/03/2024 09:48, R.Wieser wrote:
...
Post by R.Wieser
I could write a program for a 320x200 video mode which would work on two of
them but not on the third.
then add at least one option to select what's there to your program.
all my graphic draw code is flexible with SMC "variables" code parts.
and a mode change adjusts all of them in the tail of set mode code.
Post by R.Wieser
I could write a program using a textmode which would work on two of them but
not on the third.
that's why I chose mode 3, it works on all PCs (it was/is BIOS standard)
Post by R.Wieser
I could write a program supporting (read: depending on) linear addressing,
but that would not work for every video mode.
I even use text mode 3 like it were LFB with 0xB8000 as start.
Post by R.Wieser
And I just noticed that each 'puter has several modi supporting the same
resolution and color depth. No idea what that is good for.
different memory models/timing.
Post by R.Wieser
Did I already mention that I think that VESA video modi are a nightmare ?
If not, than hereby. :-)
eat it or die :) there are no other options available anymore.
you could extend your rant to INT_10 as well: not ALL modes everywhere.

you may change your mind after you became familiar with VESA.
using LFB is fast and needs much lesser instructions than INT or else.
__
wolfgang
R.Wieser
2024-03-05 13:06:49 UTC
Permalink
wolfgang,
Post by wolfgang kern
that's why I chose mode 3, it works on all PCs (it was/is BIOS standard)
You do not even have to /chose/, as BIOS video mode 3 is what you
automatically get.

... But thats not what I ment. I was talking about *VESA* video modes.
Like an 80x25x16 with an 8x8 character cell. Redefine characters, and its
as if you draw with (square!) tiles.
Post by wolfgang kern
I even use text mode 3 like it were LFB with 0xB8000 as start.
Thereby re-using what you already wrote. I would likely do the same.
Post by wolfgang kern
Post by R.Wieser
And I just noticed that each 'puter has several modi supporting the same
resolution and color depth. No idea what that is good for.
different memory models/timing.
So, even more differences that need to be supported. :-\
Post by wolfgang kern
Post by R.Wieser
Did I already mention that I think that VESA video modi are a nightmare ?
If not, than hereby. :-)
eat it or die :) there are no other options available anymore.
:-p
Post by wolfgang kern
you could extend your rant to INT_10 as well: not ALL modes everywhere.
I've never seen a 'puter which did not support BIOS video mode 3 and 13.

Also, although VESA shows (large!) differences between just the three
'puters, the BIOS video mode support is exactly the same for them - and none
of the 'puters are of the last century.
Post by wolfgang kern
you may change your mind after you became familiar with VESA.
I'm currently /trying/ to become familiar with them, but it doesn't quite
want to work. Even just three 'puters show *way* to many differences for me
to be comfortable with. And even if I would follow your lead and only
support a (lineair address only) subset I could /still/ get into trouble.
Post by wolfgang kern
using LFB is fast and needs much lesser instructions than INT or else.
Compatibility (as in "it works everywhere" - even just between the 'puters
I've got here) is currently much more important to me than speed.

Doesn't mean I do not appreciate knowing quite a bit more about VESA than I
did before this thread though. :-)

Regards,
Rudy Wieser
wolfgang kern
2024-03-05 16:47:52 UTC
Permalink
Post by R.Wieser
Post by wolfgang kern
that's why I chose mode 3, it works on all PCs (it was/is BIOS standard)
You do not even have to /chose/, as BIOS video mode 3 is what you
automatically get.
my OS itself uses 1024x768 graphic by default.
but users can decide to temporary use text mode 3 for their task.
therefore I show it in the options menu together with other modes.
Post by R.Wieser
... But thats not what I ment. I was talking about *VESA* video modes.
Like an 80x25x16 with an 8x8 character cell.
Redefine characters, and its as if you draw with (square!) tiles.
this text mode is sure there on some machines.
but you can use mode 3 and modify it with INT_0x10 ax=0x1110.
I can and do, fake such a mode with graphic (on client demand).
Post by R.Wieser
Post by wolfgang kern
I even use text mode 3 like it were LFB with 0xB8000 as start.
Thereby re-using what you already wrote. I would likely do the same.
Post by wolfgang kern
Post by R.Wieser
And I just noticed that each 'puter has several modi supporting the same
resolution and color depth. No idea what that is good for.
different memory models/timing.
So, even more differences that need to be supported. :-\
NO! just adopt what fits your desire.
Post by R.Wieser
Post by wolfgang kern
you could extend your rant to INT_10 as well: not ALL modes everywhere.
I've never seen a 'puter which did not support BIOS video mode 3 and 13.
Also, although VESA shows (large!) differences between just the three
'puters, the BIOS video mode support is exactly the same for them - and none
of the 'puters are of the last century.
some BIOS support odd Hercules modes while others don't.
Post by R.Wieser
Post by wolfgang kern
you may change your mind after you became familiar with VESA.
I'm currently /trying/ to become familiar with them, but it doesn't quite
want to work. Even just three 'puters show *way* to many differences for me
to be comfortable with. And even if I would follow your lead and only
support a (lineair address only) subset I could /still/ get into trouble.
Post by wolfgang kern
using LFB is fast and needs much lesser instructions than INT or else.
Compatibility (as in "it works everywhere" - even just between the 'puters
I've got here) is currently much more important to me than speed.
I don't get your issue at all. perhaps some misunderstanding...
different brands may have different numbers for a certain mode.
so what are these modes you can't get on all three PCs ?
Post by R.Wieser
Doesn't mean I do not appreciate knowing quite a bit more about VESA than I
did before this thread though. :-)
you're welcome. I had to remove several layers of dust from my docs.
__
wolfgang

Loading...