Hi Bogdan. If one doesn't need hw acceleration then VESA 2.0 protected mode interface is fine. Tell me if you need some help on it.. I still remember something from my Dos days, I've also some WatcomC code backupped somewhere.

Greets,
Mav
Posted on 2002-03-09 19:37:02 by Maverick
Hi Mav,

Yes, I know what you mean by using the TSR to load updated VESA support

But there are some cards that have no ROM VESA support, not even ver 1. I can't name the cards off the top of my head, but I have several Gateway and Dell machines at work, Pentium-IIIs, that don't support it at all without the TSR.

I know this because I'm a big fan of the old Links386 golf game. The pres of my company is a golf-a-holic, and several other employees play Links "on lunch" :)

Links requires VESA 1 and won't run on these machines without the TSR. The old DOS Manifest utility that came with QEMM reports VESA information, and says "none" on these cards, before the TRS is loaded.

If I remember this thread, I'll try to report some specifics when I get to work on Monday.

:)
Posted on 2002-03-09 21:27:03 by S/390
Bogdan,

=================
I whould like to know your oppinion about releasing sourcecode ...
=================

It depends on what you want to do with it. It is already an advanced piece of code to do what it already does so it depends on if you want to keep developing it or share the development with other people who are interested in OS development or not.

I have no doubt that some would be interested in the code used as it seems to handle some advanced techniques already. It really depends on how you wish to proceed.

Regards,

hutch@movsd.com
Posted on 2002-03-10 03:08:44 by hutch--
Thx Hutch, i will think about it

code is not very advanced IMHO (but could be by others oppinion) however it took me many versions to get here, only the conceptual part took me some time until i realized the best ways to do such windows managers ...

strange enough there is close to none info about such things on the net :(

Maverick, yes i guess i will need to change VESA video modes from protected ring0 code to support different resolution/color deephs, so if you have some info on that, please send it to me,

but i will like to have some hardware acceleration pretty soon also at least for 3D it is required

Opps Dell's w/o VESA... i have to check my Dell workstation :)

Well it looks i will need all the hardware info i can get :) but i will take it one thing at a time


What di you guys think the next steep should be as a OS or GUI developement?

Thx
Bogdan
Posted on 2002-03-10 07:11:04 by BogdanOntanu
>What di you guys think the next steep should be as a OS or GUI developement?

A new keyboard :) Posted on 2002-03-10 07:45:41 by bazik
Personally I would rather have a working Kernel/OS with a CUI/TUI (Console User Interface/Text User Interface... whichever you prefer to call it) before jumping right into the GUI muck which might stray you off the course since it will be so "comfortable" having it work the way it is instead of continuing on with the hardcore bs.
Posted on 2002-03-10 07:47:37 by SpooK
What kind of new keyboard Bazik
this kind?
Posted on 2002-03-10 08:07:42 by BogdanOntanu
Spook, yeah maybee, but i find it very productive to keep my mind at peace and not frustrated by a text based interface :), as you have noted from Bazik's screensshots there was a text interface in this OS long time ago :tongue:

today i see no difference in painting gfx or text characters but doing it on gfx screen is better for me, do not forget that i am a game programmer :)

and if needed i will make a "terminal emulation app"
Posted on 2002-03-10 08:16:48 by BogdanOntanu
Bogdan, VESA2 doesn't necessarily mean LFB support. But, if I remember
correctly, it *should* always have the protected mode bank switching
interface... with this and paging enabled, it's not too hard to
emulate a LFB.
Posted on 2002-03-10 12:52:50 by f0dder
On most cards, even enabling UCWC, $A0000 is slow, slow slow.. so true LFB support (and enabling UCWC) is really "a must".
Posted on 2002-03-10 17:21:35 by Maverick
current video cards offer sometimes "native" DirectX support - is it possible to access the LFB in another way than VESA? Maybe some new interrupt functions.

(I guess, MS uses VESA itself for directX)
Posted on 2002-03-11 03:48:51 by beaster
I'm afraid, the answer is "no" for both questions.
Posted on 2002-03-11 04:45:39 by Maverick
As for the assembler... im using NASM for the initial tests... but soon after I will be using DynASM :P
Posted on 2002-03-11 06:57:05 by SpooK

I guess, MS uses VESA itself for directX
directX uses a dedicated driver, to talk to the hardware. The video controller manufacturer supplies a driver designed specificaly for their hardware, so that Windows has access to the dX hardware acceleration.
Posted on 2002-03-11 08:48:09 by The Worrier King
Sorry for the late reply:


Maverick, yes i guess i will need to change VESA video modes from protected ring0 code to support different resolution/color deephs, so if you have some info on that, please send it to me,
I think that's what you need (I attached the whole document below):

4.13. Function 0Ah - Return VBE Protected Mode Interface

This required function call returns a pointer to a table that contains
code for a 32-bit protected mode interface that can either be copied
into local 32 bit memory space or can be executed from ROM providing
the calling application sets all required selectors and I/O access
correctly. This function returns a pointer (in real mode space) with
offsets to the code fragments, and additionally returns an offset to a
table which contains Non-VGA Port and Memory locations which an
Application may have to have I/O access to.


Input: AX = 4F0Ah VBE 2.0 Protected Mode Interface
BL = 00h Return protected mode table


Output: AX = Status
ES = Real Mode Segment of Table
DI = Offset of Table
CX = Length of Table including protected mode code
(for copying purposes)


The format of the table is as follows:

ES:DI + 00h Word Offset in table of Protected mode code for
Function 5 for Set Window Call
ES:DI + 02h Word Offset in table of Protected mode code for
Function 7 for set Display Start
ES:DI + 04h Word Offset in table of Protected mode code for
Function 9 for set Primary Palette data
ES:DI + 06h Word Offset in table of Ports and Memory Locations
that the application may need I/O privilege for.
(Optional: if unsupported this must be 0000h)
(See Sub-table for format)
ES:DI + ? Variable remainder of Table including Code


The format of the Sub-Table (Ports and Memory locations)

Port, Port, ... , Port, Terminate Port List with FF FF, Memory
locations (4 bytes), Length (2 bytes), Terminate Memory List with
FF FF.

Example 1. For Port/Index combination 3DE/Fh and Memory locations
DE800-DEA00h (length = 200h) the table would look like this:
DE 03 DF 03 FF FF 00 E8 0D 00 00 02 FF FF

Example 2. For only the ports it would look like:
DE 03 DF 03 FF FF FF FF

Example 3. For only the memory locations it would look like
FF FF 00 E8 0D 00 00 02 FF FF

Note:. All protected mode functions should end with a near RET (as
opposed to FAR RET) to allow the application software to CALL the code
from within the ROM.

Note: The Port and Memory location Sub-table does not include the
Frame Buffer Memory location. The Frame Buffer Memory location is
contained within the ModeInfoBlock returned by VBE Function 01h.

Note: The protected mode code is assembled for a 32-bit code segment,
when copying it, the application must copy the code to a 32-bit code
segment.

Note: It is the application's responsibility to ensure that the
selectors and segments are set up correctly.

Note: Currently undefined registers may be destroyed with the
exception of ESI, EBP, DS and SS.


Note: Refer to Section 4.2 for information on protected mode
considerations.
Posted on 2002-03-11 17:09:52 by Maverick
The official VESA 2.0 document should be the one I attach here.. it seems less readable, but more complete.
Posted on 2002-03-11 17:13:55 by Maverick