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

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

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

> 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

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*200√ 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

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

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

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

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

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

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

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

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

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

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