flat assembler
Message board for the users of flat assembler.

Index > OS Construction > real mode video driver

Author
Thread Post new topic Reply to topic
GhostXoPCorp



Joined: 13 Dec 2008
Posts: 199
Location: 01F0:0100
GhostXoPCorp
i know since there is ints in real mode, whats the point of a video driver, i want to do more things with my video, so i would like to know, is it possible to translate a protected mode video driver, to a real mode video driver, to have more control of the video and get more information, to do better things.

if not, i was wondering why no one did it (that i have seen so far)

_________________
Oh that divide overflow. Just jumps out of the bushes every time to scare the day lights out of me.
Post 06 Jun 2009, 00:38
View user's profile Send private message Reply with quote
Mac2004



Joined: 15 Dec 2003
Posts: 313
Mac2004
There's at least three points of avoiding real mode int's: 1) performance, 2) performance and 3) performance.....

Translating PM drivers is not that easy task to accomplish due to those drivers having OS dependent code as well as having non-dependent code.
And I'am not sure how legal this translating would be. Perhaps it varies from country to country?

Regards
Mac2004
Post 06 Jun 2009, 04:36
View user's profile Send private message Reply with quote
narada



Joined: 15 Feb 2008
Posts: 77
Location: Ukraine, Dnepropetrovsk
narada
it'd impossible, becouse you can't use LFB in real mode... without LFB video driver wouldn't work fast&nice)
Post 06 Jun 2009, 05:55
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
GhostXoPCorp



Joined: 13 Dec 2008
Posts: 199
Location: 01F0:0100
GhostXoPCorp
yeah, another problem is the one i was trying (my very mini write to 0xb8000 print char) test, which went bad it wrote the text at the midddle of the screen, oh well, i kno there is a way of fixig it but since you say the perfomance will not be very well, i will just stick with the int 10h write char with attrib at cursor, and make it a useful function out of it, thanks for the responses.

_________________
Oh that divide overflow. Just jumps out of the bushes every time to scare the day lights out of me.
Post 06 Jun 2009, 06:09
View user's profile Send private message Reply with quote
Mac2004



Joined: 15 Dec 2003
Posts: 313
Mac2004
GhostXoPCorp: Have you tried looking 'print character' examples. Maybe they could help you locate your bug?

Narada: good point Smile

regards,
Mac2004
Post 06 Jun 2009, 08:19
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
> is it possible to translate a protected mode video driver, to a real mode video driver

A damn buggy ATI >>10 MiB driver written in C++ Laughing ???

NO, and you don't need it, you can write text at $0B'8000 (color VGA only ?), and you can write VGA pixels at $0A'0000 in 320x200x8bpp more or planed 640x480x4bpp mode Smile

Also, you "can" use the LFB with help of PM Smile or INT $15 (uses PM) or you can do bankruptcy switching Sad

> There's at least three points of avoiding real mode int's: 1) performance, 2) performance and 3) performance.....

Depends from what job. Plot one pixel or transfer 1 Byte: EVIL Sad Do something useful: fine Smile
Post 06 Jun 2009, 10:20
View user's profile Send private message Reply with quote
bitshifter



Joined: 04 Dec 2007
Posts: 764
Location: Massachusetts, USA
bitshifter
LOL
Why you need performance when printing characters?
I thought that they print too fast so i stall it with timer.
This way it looks like someone is actually typing it out.
Post 06 Jun 2009, 11:26
View user's profile Send private message Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
narada wrote:
it'd impossible, becouse you can't use LFB in real mode... without LFB video driver wouldn't work fast&nice)

Not true. All you have to do is set up 32-bit segment limits, aka flat real mode. LFB is then directly addressable in real mode Very Happy

_________________
FAMOS - the first memory operating system
Post 06 Jun 2009, 21:20
View user's profile Send private message Visit poster's website Reply with quote
GhostXoPCorp



Joined: 13 Dec 2008
Posts: 199
Location: 01F0:0100
GhostXoPCorp
Mac2004: yeah i will take a look at those, forum or in examples? no matter i will look in both, thanks guys.

_________________
Oh that divide overflow. Just jumps out of the bushes every time to scare the day lights out of me.
Post 06 Jun 2009, 22:21
View user's profile Send private message Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
Mac2004 wrote:
There's at least three points of avoiding real mode int's: 1) performance, 2) performance and 3) performance.....

Translating PM drivers is not that easy task to accomplish due to those drivers having OS dependent code as well as having non-dependent code.
And I'am not sure how legal this translating would be. Perhaps it varies from country to country?

Regards
Mac2004
\
Certainly many os-specific interrupts are slow, such as most of the DOS INT 21h services. However the BIOS and extended BIOS interrupt services are generally fast, such as the INT 10h video services. Yes, driving the hardware directly with your own custom driver may be faster still, but you need the programming information from the hardware manufacturers. This is much more difficult if you are writing a (hardware-independent) OS, so the BIOS interrupts on the mobo can be relied on to provide the required hardware links.

_________________
FAMOS - the first memory operating system
Post 07 Jun 2009, 01:04
View user's profile Send private message Visit poster's website Reply with quote
Mac2004



Joined: 15 Dec 2003
Posts: 313
Mac2004
neville wrote:

Not true. All you have to do is set up 32-bit segment limits, aka flat real mode. LFB is then directly addressable in real mode Very Happy


Based on my own tests LFB doesn't work properly on all video cards while in flat real mode. I was able to access 128kb chunks instead of whole 'thing'.
The LFB code seemed to work properly only though PM. So success may vary depending on video card.


GhostXoPCorp: You could use search engines as well. Smile

Regards,
Mac2004
Post 07 Jun 2009, 03:35
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
Mac2004 wrote:
Based on my own tests LFB doesn't work properly on all video cards while in flat real mode. I was able to access 128kb chunks instead of whole 'thing'.
The LFB code seemed to work properly only though PM. So success may vary depending on video card.
But a video card only see the address bus, it won't know what mode the CPU is in. FRM, PM, Real, whatever mode, the video card doesn't know and doesn't care.
Post 07 Jun 2009, 04:13
View user's profile Send private message Visit poster's website Reply with quote
GhostXoPCorp



Joined: 13 Dec 2008
Posts: 199
Location: 01F0:0100
GhostXoPCorp
i just wanted to know if in real mode instead of using inturrupts i could use a pmode driver to print so i can do more things and get more information from the screen that my os might need. thats all


mac2004: i have searched, but more searching wont hurt Smile, this is very interesting
Post 07 Jun 2009, 04:47
View user's profile Send private message Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
Mac2004 wrote:
Based on my own tests LFB doesn't work properly on all video cards while in flat real mode. I was able to access 128kb chunks instead of whole 'thing'.
The LFB code seemed to work properly only though PM. So success may vary depending on video card.

My experience is different. My LFB code in flat real mode has been tested on hundreds of computers now and I'm not aware of any failures. Of course the video card itself must support linear buffering, indicated by bit7=1 in the ModeAttributes word returned in word0 of the ModeInfoBlock for VESA BIOS Extensions (VBE) Function 01.

Your problem could be caused by a video card which fails the above test, or maybe by the failure of the LFB code to take account of the specific granularity of the video RAM on a particular card. In any case, the fault is with the LFB code, not the video card hardware.

_________________
FAMOS - the first memory operating system
Post 07 Jun 2009, 05:10
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.