From Newsgroup: alt.lang.asm

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


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

On 15/02/24 19:04, R.Wieser wrote:

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.

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

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.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

On 15/02/2024 12:04, R.Wieser wrote:

hello Rudy,

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

...

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

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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

Paul,

Do you mean XT?

Nope. Do those motherboards still exist ? :-)

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

Yep.

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


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

wolfgang,

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.

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.

VESA support is found within:

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

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>


I see you used a few "magic numbers" :

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



--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

On 15/02/2024 20:39, R.Wieser wrote:
...

VESA support is found within:

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

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>
I see you used a few "magic numbers" :

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

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

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.

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

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

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

welcome
__
wolfgang
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

wolfgang,

I see you used a few "magic numbers" :

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.

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

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


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

On 16/02/2024 09:11, R.Wieser wrote:

wolfgang,

I see you used a few "magic numbers" :

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.

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.

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

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]

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.

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.

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.

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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

wolfgang,

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.

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.

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


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

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

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


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

On 17/02/2024 13:40, R.Wieser wrote:

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)

So, success !

supported only if INT10_1B (ax=0x1B00) returns 0x1B in AL

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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

wolfgang,

So, success !

supported only if INT10_1B (ax=0x1B00) returns 0x1B in AL

:-) Yes, I checked that.

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.

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



--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

On 17/02/2024 19:10, R.Wieser wrote:

wolfgang,

So, success !

supported only if INT10_1B (ax=0x1B00) returns 0x1B in AL

:-) Yes, I checked that.

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.

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 ?

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

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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

Wolfgang,

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:

I've got the same info here. The thing is that I can see the names of the fields, but stil have no idea what goes into them / where to get it from.

02h WORD horizontal sync start (in pixels)
04h WORD horizontal sync end (in pixels)

No idea.

06h WORD total number of scan lines

I /think/ I saw something about that somewhere, but am not quite sure.

Than again, total vs displayed. Which one do they even mean here.

08h WORD vertical sync start (in scan lines)
0Ah WORD vertical sync end (in scan lines)

Same problem as the first two

0Ch BYTE flags (see #04084)

...

0 enable double scanning
1 enable interlacing
2 horizontal sync polarity (0 positive, 1 negative)
3 vertical sync polarity (0 positive, 1 negative)

No idea either, with 16 combinations to choose from.

0Dh DWORD pixel clock, in Hz
11h WORD refresh rate, in 0.01 Hz units

Same again here.

mode 0100 is graphic 640*400,8bit (256 colors)
my OS rare alters CRTC values, so I have ES:DI as 0:0

My first machine doesn't seem to use the above data at all (ES:DI can be anything). But, as mentioned, my second machine freezes hard when I try to "ignore" that record (zeroing it out) (might have nothing to do with its contents ...). And, although your OS accepts ES:DI when its zero, RBIL
makes no mention of being allowed to supply that value.

... Just tried it (with ES:DI being zero) on my second machine, and got the same hard freeze (with a black screen) as with a zeroed-out record.

Shucks. That second machine doesn't allow BIOS video modi, and now it
doesn't accept VESA modi either (but does tell me its VESA 3.0 capable). :-\

Regards,
Rudy Wieser

P.s.
The second machines videocard is a gforce GT 730.



--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

On 17/02/2024 21:09, R.Wieser wrote:

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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

wolfgang,

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


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

On 18/02/2024 09:13, R.Wieser wrote:

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.

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 ?

yes.
and there are additional issues with monitors (I hate this EDID story)

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.

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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

Wolfgang,

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.

And graphic driver software may be just there to support windoze&loonix.

Hence my before-and-after checking. :-)

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.

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 ? :-)

and there are additional issues with monitors (I hate this EDID story)

Oh goody. :-\

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! :-)

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.

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.

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.

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

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

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


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

On 18/02/2024 11:50, R.Wieser wrote:
...

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

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

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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

wolfgang,

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.


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

On 25/02/2024 10:55, R.Wieser wrote:

wolfgang,

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.

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

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.

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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

wolfgang,

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!!! :-)

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


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

On 25/02/2024 19:43, R.Wieser wrote:

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!!! :-)

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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

wolfgang,

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.

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

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

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

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


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

On 26/02/2024 08:30, R.Wieser wrote:

wolfgang,

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

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

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

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

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.

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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

wolfgang,

? have you tried an iterated sequence of:
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.

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.

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


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

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

Ah, I didn't think of that one. Alas, I'm getting a light-blue line.

light blue coz last write was 80.

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.

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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

wolfgang,

how about:

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

Ah, I didn't think of that one. Alas, I'm getting a light-blue line.

light blue coz last write was 80.

Yep.

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.

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)

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

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

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

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


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

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


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

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]

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

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.

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

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)

:)

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.

... and as I'm in the "discovery phase" ...

adventuring hardware can be funny :) I like that
.

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.

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

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

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)

And funny, the "physical address of linear video buffer" value (at offset 0x28) doesn't mention an "if (not) supported" clause (in RBIL).

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*200reU but not 512*384].
no, you need GDT if you want UNREAL mode.

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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

wolfgang,

My apologies for the late reply, my attention was pulled elsewhere ...

are you sure to set a 32 bit mode ?

I've been using vesa mode 0x20, which is reported as being 320x200x32.

when I draw a pixel to screen in 32 bit mode I can be:
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).

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.

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

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

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.

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.

from my KESYS docs (my OS ignore all that's not mentioned here):
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. :-(

bit 4 GRAPHIC/text

No indication if a certain graphics mode supports text output ... (I do not consider that to be a given).

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.

dword[es:di+0x28] FLAT pointer start address of LFB

Here (on one 'puter) it returns a 0xF8000000 address for all VESA modi.

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.

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


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

On 04/03/2024 15:39, R.Wieser wrote:
...

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.

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

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.

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.

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

from my KESYS docs (my OS ignore all that's not mentioned here):
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.

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.

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

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]

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.

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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

wolfgang,

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

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.

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.

who writes graphic programs for only one resolution ...?

I guess you never met a webdesigner. :-)

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)

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.

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.

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

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 ?

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


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

On 04/03/2024 22:34, R.Wieser wrote:

[snipped argue about ES] we an assume it's there :)

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.

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.

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.

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.

...

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

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.

Thats quite a waste of time, energy and code. :-|

took me lesser than you may think.

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!

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

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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

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


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

On 05/03/2024 09:48, R.Wieser wrote:
...

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

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)

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.

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.

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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

wolfgang,

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.

web folks use Java rely on OS given capabilities and don't talk direct to the graphic cards controller nor to the memory.

....

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.

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.

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.

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

you can believe that ROM belong to Hardware!

The ROM itself ? Yes. Its contents ? No.

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

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


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

On 05/03/2024 12:05, R.Wieser wrote:
...

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.

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.

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]

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.

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

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?

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.

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.

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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

wolfgang,

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.

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.

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

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

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.

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.

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


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.lang.asm

On 05/03/2024 14:06, R.Wieser wrote:

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.

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

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.

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.

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.

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.

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 ?

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
--- Synchronet 3.21d-Linux NewsLink 1.2