OSDev.org

btw, devices usually have internal state, timing dependencies and things alike that will make reverse engineering hard enough. The NVIDIA "open source" license do not even allow you to disclose *what you have discovered looking at the open source part", so you can easily imagine what you'll face if you attempt to distribute information about reverse-engineered knowledge.

still, that'd certainly be exciting to do (even if useless and timeconsuming)

AR wrote: # It must be indispensable to reverse engineer to obtain the necessary information.

Well... we didn't have any driver info already and we can't find it out any other way obviously.

# The reverse engineering has to be by a licensee or authorised user.

We have a license for using it in windows, so in a way we're licensed. At least, you're licensed for your own video cards and you probably won't develop for one you don't have.

# The necessary information must not already have been readily available to those people.

Obviously, duplicate of first.

# Only the parts of the program necessary for interoperability (i.e. the interfaces) can be reproduced.

That in this case means the binary interface to connect with the hardware. And yes, we didn't have that yet. No, we're not going to care about how they access polygon lists or anything.

# The information generated by the reverse engineering cannot be used for anything other than achieving interoperability of an independently created program.

So, you can't show off the information to get a date. Lucky for us most girls don't really care about it. Otherwise, we were actually trying to get it to work with the hardware in the way it was supposed to.

# The information cannot be passed on to others except where necessary for this purpose.

Well... it's necessary for all of us to have this information to do any decent interoperability,

# The information obtained cannot be used to make a competing program (rather than just an interoperable one).

Strictly speaking we're not trying to compete with the product we want to interoperate with. We are not trying to compete with the driver either, we're trying to live alongside it in a space where it does not go, and leave its space alone.

# The "legitimate interests" of the copyright owner or "normal exploitation" of the program must not be prejudice.

This isn't even a valid sentence.


We don't interfere with either legitimate interests (if they'd even respond to emails we might even be tempted to start thinking they might be interested) nor normal exploitation of the other program (you can still run the driver in all windows-oses even though we looked at it).


So, we can share information freely, reverse engineer all we want as long as we can't just get the books for it. Probably the justice system in the US counts on "at any price", whereas I expect the dutch to consider significantly more than 500 euros too much. Which places us in the same ballpark as Windows.

What programs are there to dump port signals that a device sends?

It would be interesting to be able to make "scripts" that boot up cards.

Hi,

SANiK wrote: What programs are there to dump port signals that a device sends?

It would be interesting to be able to make "scripts" that boot up cards.

AFAIK there are no such programs. You could make your own by running a Linux and/or Windows driver in a special environment (where CPL=3 and IOPL=0 for e.g.). Unfortunately this would be harder than supporting the other OS's drivers.

One alternative would be to use real mode drivers (ie. DOS/BIOS) instead and modify a V86 monitor to capture the IO port accesses (this would be a lot easier).

Once you do have a list of all IO port accesses (including the data written for writes, and information on IRQs) it still won't actually work for most things. If the device driver checks a status bit and behaves differently according to the state of that status bit then there's no way for your script to handle it.

For example, consider this code (from initialization code in a PS/2 controller driver):
The first thing that's going to happen is that the tight loop is going to make your recorded script huge in a hurry. Secondly, there's no way for the script to handle "if/then" or respond when the status port does change. You also won't be able to deal with the timeout properly either, so any form of hardware error (including "device not present") is going to be a problem. This is just a small/simple part of a small/simple driver - you can imagine how many problems you'd have with a 3D accelerated video, a SCSI controller or USB?

Despite this there is one area where this may be useful - setting video modes for some (but not all) video cards.


Cheers,

Brendan

Speaking of drivers:




I finally finished enough of my x86 EMU for it to enter a VESA mode >:P

How it works:
1) Program sets registers using variables
2) vm_int(0x10) is called
3) This hands over the functioning to the emu
4) When an IRET is hit, control is passed back to the program

How many DOS drivers are there for 3D cards?

Under DOS, there was Glide for the 3dfx Voodoo cards!

How did Duke Nukem 3D do it drawing

B.E wrote: How did Duke Nukem 3D do it drawing

That was done using a software 3D engine. What we are looking for here is a hardware 3D engine.

Yup, it would be an interesting project, and looks fully legal from what I can see. I bought the hardware and I want it to work, I don't see anything wrong with that. I'll see what I can add to the NVidia entry in the wiki

It would be quite easy to trap the io port and memory accesses using Qemu, I remember there was a patch on the source for such things, and a copy of a good disassembler (IDAPro I've heard is good). There's quite a few files for the NVidia driver tho in Windows XP.

It might not work if Qemu uses it's own virtual video card however.