info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Testing all video mode - but which ones are graphics ?
6 views
Skip to first unread message
R.Wieser
Feb 15, 2024, 6:05:02 AMFeb 15
to
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
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
Feb 15, 2024, 8:32:48 AMFeb 15
to
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.
>
> 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?
> 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).
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.
wolfgang kern
Feb 15, 2024, 9:32:28 AMFeb 15
to
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.
...
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
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:
> 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).
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
Feb 15, 2024, 9:39:37 AMFeb 15
to
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
> Do you mean XT?
Nope. Do those motherboards still exist ? :-)
> Or are you talking about running MSDOS apps under Windows XP?
> but someone who does know the answer may not answer
> because they are confused about the environment.
full-screen mode.
Regards,
Rudy Wieser
R.Wieser
Feb 15, 2024, 2:39:57 PMFeb 15
to
wolfgang,
>> I've got a small program going thru all video-modi by looping AL from 80
>> upto FF, calling INT 10, AH=00.
> 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
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
>> 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.
> so some may just lock up
> while others could damage (old) monitors.
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:
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
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
wolfgang kern
Feb 16, 2024, 1:36:56 AMFeb 16
to
On 15/02/2024 20:39, R.Wieser wrote:
...
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
...
>> 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
>
> :-) 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
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
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
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 ?
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.
> 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.
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.
__
wolfgang
R.Wieser
Feb 16, 2024, 3:11:49 AMFeb 16
to
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
>> 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].
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
> 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.
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
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
Feb 16, 2024, 4:16:38 AMFeb 16
to
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.
> 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.
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.
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.
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.
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.
> :-)
__
wolfgang
R.Wieser
Feb 16, 2024, 4:35:52 AMFeb 16
to
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
>> 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.
> then you could be on the safer side but I'd store the info somewhere
> for later use.
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,
Thanks for the help and explanations.
Regards,
Rudy Wieser
R.Wieser
Feb 17, 2024, 7:41:00 AMFeb 17
to
> 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
> 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).
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
Feb 17, 2024, 11:36:37 AMFeb 17
to
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)
> 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 !
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.
have you tried cx==0x0013 ax==0x4f01 INT_0x10 ?
didn't work on my old PC
__
wolfgang
R.Wieser
Feb 17, 2024, 1:10:46 PMFeb 17
to
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
>> So, success !
>
> supported only if INT10_1B (ax=0x1B00) returns 0x1B in AL
>> 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
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
Feb 17, 2024, 1:35:38 PMFeb 17
to
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:
> 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 ?
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 ... :-)
__
wolfgang
R.Wieser
Feb 17, 2024, 3:09:36 PMFeb 17
to
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)
...
> 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.
>> 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:
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)
> 06h WORD total number of scan lines
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)
> 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.
> 1 enable interlacing
> 2 horizontal sync polarity (0 positive, 1 negative)
> 3 vertical sync polarity (0 positive, 1 negative)
> 0Dh DWORD pixel clock, in Hz
> 11h WORD refresh rate, in 0.01 Hz units
> mode 0100 is graphic 640*400,8bit (256 colors)
> my OS rare alters CRTC values, so I have ES:DI as 0:0
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.
wolfgang kern
Feb 17, 2024, 3:38:15 PMFeb 17
to
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
>>> 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
Feb 18, 2024, 3:13:56 AMFeb 18
to
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
>>>> 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.
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
Feb 18, 2024, 3:58:31 AMFeb 18
to
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 :)
>>>>> 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.
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 ?
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?
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 ?
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
Feb 18, 2024, 5:50:51 AMFeb 18
to
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
>> 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 :)
are bare-metal ones.
> 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.
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.
another meaning ? :-)
> 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.
I guess you've met some "special" people.
> and INT_10_0C is usually pretty slow, I use direct screen write instead.
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.
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
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.
needs its own Windows drivers.
Regards,
Rudy Wieser
wolfgang kern
Feb 18, 2024, 6:31:26 AMFeb 18
to
On 18/02/2024 11:50, R.Wieser wrote:
...
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
...
>>> 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! :)
>>> 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 ? :-)
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.
>> INT 10 - VIDEO - Realtek RTVGA - SET USER GRAPHICS CHARACTERS
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
0 new messages