OSDev.org

erm **** head, this is OSDEV... we don't have too many nuby tutorials round here.

and do you really think there is a "write your own nvidia driver" tutorial? nuhuh. theres open source code out there, its complex as ****, and i wouldn't be able to port it. but good luck trying... or, like the rest of us, you could make do with VGA until something easier comes along, or until you have time to attempt such an immensity of a task.

and if you can find a friendlier (and more informed) osdev forum, ill lick your balls. cos there isnt one. so shutup and leave if its so bad.

lukem_95 wrote:heres open source code out there, its complex as ****, and i wouldn't be able to port it. but good luck trying...

Well, I think the basics for 2D isn't that hard to figure out from the FOSS drivers. Setting video modes, hardware cursor, that stuff. Although I believe that for setting video modes the BIOS is called.

and if you can find a friendlier (and more informed) osdev forum, ill lick your balls. cos there isnt one. so shutup and leave if its so bad.

Hah, for all we know you are a SM slave and you like licking balls! :)))


JAL

01000101 wrote:yes. as long as you stay away from trying to mimic the reverse-engineered programms lower-level calls, you should be safe. If you went out and tried to disassemble and remake the windows bootloader or something, then the grey area of reverse-engineering can turn black fast.

Yes, although most of that applies only in the US. In Europe you are safe even if you copy large parts of code.


JAL

zaleschiemilgabriel wrote:If I write my driver by disassembling a Windows or Linux driver without using any proprietary specs, by only applying my own interface to the driver mod, is this perfectly legal?

Well, if you are both the reverse engineer and the programmer, things can get messy. True clean-room engineering means one team disassembles the code to get the specs, and writes an interface design document, and another team uses those interface specs to write the code. That's the way how early IBM PC clone makers made the BIOS (I think it was Phoenix).


JAL

Wow, 2 pages of crap about reverse eng. and the thread became popular.

While the thread should be about generic way of determining graph modes from prot. mode. Which is IMHO "protected mode interface" (but I don't think its available from LongMode without switch so I never used it )

haha, ok so i'l rephrase about the licking balls bit. plus i realise now that there was a page in between my rant at that poster, and his actual post.

so forgive me for that

plus its nice to know about the 2D stuff in that driver, i might give it a look sometime

So far i know that the nvidia windows driver is made up of two parts: nv4_mini.sys - the miniport driver (this one receives IOCTL commands from the system and sends data to the video ports), and nv4_disp.dll (this implements stuff like BitBlt and AlphaBlt).

Right then!... I'll settle for BIOS VESA for now and get down 'n dirty with reverse-engineering later.

EDIT: Here's another thing my noodle just thought of:
I remember that in DOS I could set a breakpoint at the int 10h entry point using Turbo Debugger. Couldn't I just copy and modify the code there to work in protected mode? It was a bit of a mess the way I remember it, but if I could trace the code to find the exact sequence of IN and OUT instructions and reproduce the conditional jumps exactly, it would work, right?

zaleschiemilgabriel wrote:Couldn't I just copy and modify the code there to work in protected mode? It was a bit of a mess the way I remember it, but if I could trace the code to find the exact sequence of IN and OUT instructions and reproduce the conditional jumps exactly, it would work, right?

No. Because there may be many conditional jumps in there, and certain INs and OUTs only done when certain conditions are true, based on the current hardware state.


JAL

jal wrote:

zaleschiemilgabriel wrote:Couldn't I just copy and modify the code there to work in protected mode? It was a bit of a mess the way I remember it, but if I could trace the code to find the exact sequence of IN and OUT instructions and reproduce the conditional jumps exactly, it would work, right?

No. Because there may be many conditional jumps in there, and certain INs and OUTs only done when certain conditions are true, based on the current hardware state.


JAL

Have you already tried?

zaleschiemilgabriel wrote:

jal wrote:

zaleschiemilgabriel wrote:Couldn't I just copy and modify the code there to work in protected mode? It was a bit of a mess the way I remember it, but if I could trace the code to find the exact sequence of IN and OUT instructions and reproduce the conditional jumps exactly, it would work, right?

No. Because there may be many conditional jumps in there, and certain INs and OUTs only done when certain conditions are true, based on the current hardware state.


JAL

Have you already tried?

Have YOU tried?

zaleschiemilgabriel wrote:Have you already tried?

I don't need to, do I? It doesn't work, see. I tend not to endavour in fruitless missions.


JAL