Index
> OS Construction > Accessing Video Card RAM?Goto page Previous 1, 2, 3 |
| Author |
|
I meant that the logical structure of the drivers were similar, I know 64-bit OS needs 64-bit drivers and 32-bit OS needs 32-bit drivers 
|
Madis731 08 Jan 2008, 08:52
rhyno_dagreat wrote:
Whoops 
DOS386 wrote:
I don't understand this ^o) If you have a set mode (I mean ANY mode) then shouldn't writing to the LFB emit some light from the screen from some point? If you don't know, its hard to know where the screen line ends, but if a default resolution is known (somehow?!) you will code keeping this in mind and thus no need to set a new mode. Maybe I didn't get it clearly. |
|||
08 Jan 2008, 08:52 |
|
Writing into the LFB won't have any (useful) effect without setting the mode before ... and there is no universal method to do except VESA 
|
DOS386 09 Jan 2008, 01:07
Quote: If you have a set mode (I mean ANY mode) then shouldn't writing to the LFB emit some light from the screen from some point? YES 
Quote: but if a default resolution is known (somehow?!) you will code keeping this in mind and thus no need to set a new mode. IIRC the "default" mode is 80x25 text 
Quote: Maybe I didn't get it clearly. Not at all  _________________ Bug Nr.: 12345 Title: Hello World program compiles to 100 KB !!! Status: Closed: NOT a Bug |
|||
|
09 Jan 2008, 01:07 |
|
|
Madis731 09 Jan 2008, 07:11
Right - I'm thinking too OS-level, where a default mode is graphical
I will shut up - and read more about VESA  |
|||
|
09 Jan 2008, 07:11 |
|
|
vid 09 Jan 2008, 07:15
Madis: Setting mode is pretty much a problem, using direct video RAM access. So yes, you need some card-specific code or VESA anyway.
|
|||
|
09 Jan 2008, 07:15 |
|
|
Feryno 09 Jan 2008, 08:42
the sample for win64 has a lot of necessary bullshits, so try to read src/sys/a08.asm try to search string 80000000h somewhere in the middle of a08.asm
if you have win64 you can directly test it using 08_test.bat. Under Vista x64 do steps described in *.txt file. If you are developping hobby OS, use int 10h VESA call to set video mode and another VESA call to obtain LFB (this int10h call is also required for knowing whether video mode uses 24 bits for 1 pixel or 32-bit for pixel etc). If your OS doesn't use paging, you can do it in the way described by DOS386. I hope you will developp your OS further so after enabling paging you need to map LFB somewhere. When graphic cards with 2 GB memory come to common market I suppose the int 10h method will be insuffient to obtain LFB (the top of of LFB address can't fit into 4 GB limit) but PCI scan method will work fine. P.S. sorry I left 32 bit world years ago, the sample is pure 64 bit. For 32-bit fans it is really easier to use int 10h VESA calls. P.S.2 the code is optimized for the smallest possible size, to minimum of instructions used and to avoid conditional branches, so you need to "decode" some parts a lot (e.g. lea eax,[rcx+rdx*4+10h] instead of mov eax,ecx shl edx,2 add eax,edx add eax,10h etc.)
|
|||||||||||
|
09 Jan 2008, 08:42 |
|
|
Madis731 09 Jan 2008, 09:46
What does "native" do in "format PE64 native 5.02"? Haven't heard about it.
|
|||
|
09 Jan 2008, 09:46 |
|
|
vid 09 Jan 2008, 10:28
it's "native subsystem", google
I think all drivers must be flagged as native |
|||
|
09 Jan 2008, 10:28 |
|
|
Madis731 09 Jan 2008, 10:45
Hmm, okay - I wonder why it isn't silent then (i.e. on by default)...
Anyways, the driver worked fine after changing the hard-coded C:\Windows to something more like %WINDIR%. It answered to the eternal question with a number: 00000000D0000000h
The question being - LFB? |
|||
|
09 Jan 2008, 10:45 |
|
|
rhyno_dagreat 09 Jan 2008, 17:58
Okay... So I want to reverse engineer my graphics drivers... where do I begin?
|
|||
|
09 Jan 2008, 17:58 |
|
|
rhyno_dagreat 09 Jan 2008, 20:42
With all this talk about VESA, it just struck me: Couldn't we access the IVT, particularly interrupt 10h, then figure out the address of that, then from there figure out the address of the VESA functions?
|
|||
|
09 Jan 2008, 20:42 |
|
|
DOS386 09 Jan 2008, 22:35
Quote: Couldn't we access the IVT, particularly interrupt 10h, then figure out the address of that, then from there figure out the address of the VESA functions? YES  This way you will get the VESA functionality via ports, __maybe__ fix 1 or 2 minor bugs, but not the "advanced" stuff beyond VESA (more modes, bigger LFB (sometimes VESA reports less RAM than in fact exists), 2D, 3D, 4D, 5D, ... "acceleration", ...) |
|||
|
09 Jan 2008, 22:35 |
|
|
Feryno 10 Jan 2008, 07:34
rhyno_dagreat, you'll spend a lot of time...
look, it is really easy to use 2-3 int 10h calls in real mode and then load your OS which won't depend on any int 10h call anymore this is about 1/2 year old crap from me, I developped it further, but this sample does everything necessary, you can freely extract what do you need and copy->paste into your project it switches into 64-bit, so download qemu-64 or write into floppy and boot under 64-bit CPU (there is really lack of such configs todays - 64-bit CPU and floppy drive... you can also make bootable CD with emulation of floppy etc.) Madis731, thank you for the report, I'll improve the *.bat file. Nice to read that it worked. 'native' means you want to compile driver (*.sys) or native application (special exe, I posted some samples about year ago in the fasm board, really funny) http://board.flatassembler.net/topic.php?t=4941
|
|||||||||||
|
10 Jan 2008, 07:34 |
|
| Goto page Previous 1, 2, 3 < Last Thread | Next Thread > |
Forum Rules:
|