Index
> OS Construction > real mode video driver |
| Author |
|
|
Mac2004 06 Jun 2009, 04:36
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 |
|||
06 Jun 2009, 04:36 |
|
|
narada 06 Jun 2009, 05:55
it'd impossible, becouse you can't use LFB in real mode... without LFB video driver wouldn't work fast&nice)
|
|||
|
06 Jun 2009, 05:55 |
|
|
GhostXoPCorp 06 Jun 2009, 06:09
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. |
|||
|
06 Jun 2009, 06:09 |
|
|
Mac2004 06 Jun 2009, 08:19
GhostXoPCorp: Have you tried looking 'print character' examples. Maybe they could help you locate your bug?
Narada: good point 
regards, Mac2004 |
|||
|
06 Jun 2009, 08:19 |
|
|
DOS386 06 Jun 2009, 10:20
> 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++  ???
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
Also, you "can" use the LFB with help of PM or INT $15 (uses PM) or you can do bankruptcy switching 
> 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 Do something useful: fine |
|||
|
06 Jun 2009, 10:20 |
|
|
bitshifter 06 Jun 2009, 11:26
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. |
|||
|
06 Jun 2009, 11:26 |
|
|
neville 06 Jun 2009, 21:20
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  _________________ FAMOS - the first memory operating system |
|||
|
06 Jun 2009, 21:20 |
|
|
GhostXoPCorp 06 Jun 2009, 22:21
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. |
|||
|
06 Jun 2009, 22:21 |
|
|
neville 07 Jun 2009, 01:04
Mac2004 wrote: There's at least three points of avoiding real mode int's: 1) performance, 2) performance and 3) performance..... 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 |
|||
|
07 Jun 2009, 01:04 |
|
|
Mac2004 07 Jun 2009, 03:35
neville 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. GhostXoPCorp: You could use search engines as well.
Regards, Mac2004 |
|||
|
07 Jun 2009, 03:35 |
|
|
revolution 07 Jun 2009, 04:13
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'. |
|||
|
07 Jun 2009, 04:13 |
|
|
GhostXoPCorp 07 Jun 2009, 04:47
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 , this is very interesting |
|||
|
07 Jun 2009, 04:47 |
|
|
neville 07 Jun 2009, 05:10
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'. 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 |
|||
|
07 Jun 2009, 05:10 |
|
< Last Thread | Next Thread > |
Forum Rules:
|