It seems that Windows XP NTVDM doesn't let me map any physical address to linear (with int 31h, ax=800h)...
I haven't tested it with any other values, than the VESA LFB and some random ones, but I assume it doesn't even check, but just returns with carry flag.
Sure, it would be dangerous if it would just let you map any address, but not allowing the mapping of VESA LFB is not good for compatibility.
So, does anyone know if there is a patch or a workaround for NTVDM, that would allow dos programs to map (atleast) the VESA LFB?
I don't think there is any, but I'm just asking, before I go and take a look at it myself.
Strange that there haven't been more fuss about this on the forum...
maybe not too many people program for dos, anymore...
The int 31h handler in DOSX.EXE seems to call back NTVDM, so the actual processing must happen there...
The board rules forbid talking of reversing, even if the intention is good, so I think I'll have to STFU, now...
I haven't tested it with any other values, than the VESA LFB and some random ones, but I assume it doesn't even check, but just returns with carry flag.
Sure, it would be dangerous if it would just let you map any address, but not allowing the mapping of VESA LFB is not good for compatibility.
So, does anyone know if there is a patch or a workaround for NTVDM, that would allow dos programs to map (atleast) the VESA LFB?
I don't think there is any, but I'm just asking, before I go and take a look at it myself.
Strange that there haven't been more fuss about this on the forum...
maybe not too many people program for dos, anymore...
The int 31h handler in DOSX.EXE seems to call back NTVDM, so the actual processing must happen there...
The board rules forbid talking of reversing, even if the intention is good, so I think I'll have to STFU, now...
Maybe this help: http://ntvdm.cjb.net/
Strange that there haven't been more fuss about this on the forum...
maybe not too many people program for dos, anymore...
maybe not too many people program for dos, anymore...
We have been using DirectDraw for years. It's easier to use, faster and more compatible than DOS + VESA. So really, who cares?
Maybe this help: http://ntvdm.cjb.net/
Nope, but they say they're thinking about implementing VESA improvements sometime in the future (I doubt it, though).
We have been using DirectDraw for years. It's easier to use, faster and more compatible than DOS + VESA. So really, who cares?
LOL. No offense, but that wasn't the point.
I have a lot of experience in DX, OpenGL, OS dev field, etc.
I was meaning about old dos games/programs that require LFB support, it would be nice to run them on XP.
Maybe I should have posted this in the heap, even though this is Windows specific.
Anyway, I don't think it would be too difficult to fix this...
Just write a dos program that will hook int 31h function 800h. The handler would then call a VDD, and the VDD would need to verify the address, and if it fits the VESA LFB range, map it (with help of a KMD).
Although I'm not actually sure if it would work this easily. The display drivers might have something to say about this :)
I'll take a better look when I have time.
Hm, what about having a normal win32 app using DirectDraw to provide "VESA services"? If you can communicate between the Dos VM and a win32 app, of course... might not be all that easy anyway :)
LOL. No offense, but that wasn't the point.
Why don't you make the point then, instead of laughing at good advice?
Also I doubt your experience if you cannot figure out the solution yourself, listen to f0dder.
its already been discussed, but... do you guys still think the physical vesa lfb and the physical ddraw pointer arent the same? you wouldnt rely on that?
Physical address returned by (non-emulated) VESA *might* be the same as the physical address windows uses (though for PCI and AGP devices, can't the OS tell the cards to choose another address?) - but DDraw doesn't return a physical pointer, it returns a linear one - and, theoretically, this could change with each call to Lock. Besides, the returned pointer is probably only valid in the context of a single process, at least you should treat it such.
Not all videomodes are supported in VESA, with at least some cards.
For example, Matrox only exposes 640x480 or higher VESA modes, while in DirectDraw, it supports lower resolutions aswell (probably set up by using higher modes with adapted timings (double-pixel modes). By emulating through DirectDraw, you can emulate many of such 'incompatibilities'. On the other hand, direct port access may or may not have the expected results in DirectDraw modes (in Win32, you cannot access these ports, and must use the API), so these should be emulated aswell.
For example, Matrox only exposes 640x480 or higher VESA modes, while in DirectDraw, it supports lower resolutions aswell (probably set up by using higher modes with adapted timings (double-pixel modes). By emulating through DirectDraw, you can emulate many of such 'incompatibilities'. On the other hand, direct port access may or may not have the expected results in DirectDraw modes (in Win32, you cannot access these ports, and must use the API), so these should be emulated aswell.