Hi,
[ adding seabios list to Cc:, topic is the missing vesa 2.0 protected mode interface in seavgabios ]
Pointer? I'd like to have a test case which breaks with the new vgabios.
We talked with malc briefly on irc yesterday, and this is what he gave me:
http://cvs.savannah.gnu.org/viewvc/vgabios/vbe.c?root=vgabios&r1=1.47&am...
this is not the test case but the missing support he's referring to.
It appears the patch implements just 2 functions which both just does int10,
It isn't that simple. Just invoking int10 from protected mode isn't guaranteed to have the desired effect. It certainly wouldn't work for linux vesafb panning. It might work for dos extenders, they might have the idt entry for int10 and other bios interrupts setup accordingly to do a real-mode -> bios call -> protected mode transition to simplify porting dos code to the 32bit extender. But even for that use case it is IMHO pointless as the reason to have a 32bit interface is to avoid the expensive real mode switch in the first place ...
The code has been changed later on, for good reasons, see http://git.qemu.org/?p=vgabios.git;a=commitdiff;h=72c270d8091fb0f09e8291cc0e...
so should be easy to implement in seabios,
seavgabios has no 32bit code at all at the moment. vesa pmi didn't seem to be important enougth to change it.
seabios is a 16/32bit hybrid with some code being compiled twice for both modes; dunno how reusable the seabios infrastructure is. Unlike seabios seavgabios has no fixed load address, which makes things a bit more complicated when it comes to global variables I think.
At least for the bochs interface this wouldn't be a showstopper though. Instead of using global variables to figure stuff like the active video mode we can just read the bits we need from the bochs device registers. Costs some extra vmexits of course, and we wouldn't have code sharing for 16+32bit paths.
cheers, Gerd
On Wed, 18 Apr 2012, Gerd Hoffmann wrote:
Hi,
[ adding seabios list to Cc:, topic is the missing vesa 2.0 protected mode interface in seavgabios ]
Pointer? I'd like to have a test case which breaks with the new vgabios.
We talked with malc briefly on irc yesterday, and this is what he gave me:
http://cvs.savannah.gnu.org/viewvc/vgabios/vbe.c?root=vgabios&r1=1.47&am...
this is not the test case but the missing support he's referring to.
It appears the patch implements just 2 functions which both just does int10,
It isn't that simple. Just invoking int10 from protected mode isn't guaranteed to have the desired effect. It certainly wouldn't work for linux vesafb panning. It might work for dos extenders, they might have the idt entry for int10 and other bios interrupts setup accordingly to do a real-mode -> bios call -> protected mode transition to simplify porting dos code to the 32bit extender. But even for that use case it is IMHO pointless as the reason to have a 32bit interface is to avoid the expensive real mode switch in the first place ...
I needed DOS to work and it did, for me, in turn, linux vesafb is pointless.
The code has been changed later on, for good reasons, see http://git.qemu.org/?p=vgabios.git;a=commitdiff;h=72c270d8091fb0f09e8291cc0e...
so should be easy to implement in seabios,
seavgabios has no 32bit code at all at the moment. vesa pmi didn't seem to be important enougth to change it.
seabios is a 16/32bit hybrid with some code being compiled twice for both modes; dunno how reusable the seabios infrastructure is. Unlike seabios seavgabios has no fixed load address, which makes things a bit more complicated when it comes to global variables I think.
At least for the bochs interface this wouldn't be a showstopper though. Instead of using global variables to figure stuff like the active video mode we can just read the bits we need from the bochs device registers. Costs some extra vmexits of course, and we wouldn't have code sharing for 16+32bit paths.
cheers, Gerd
On Wed, Apr 18, 2012 at 10:45:06PM +0400, malc wrote:
On Wed, 18 Apr 2012, Gerd Hoffmann wrote:
We talked with malc briefly on irc yesterday, and this is what he gave me:
http://cvs.savannah.gnu.org/viewvc/vgabios/vbe.c?root=vgabios&r1=1.47&am...
this is not the test case but the missing support he's referring to.
It appears the patch implements just 2 functions which both just does int10,
It isn't that simple. Just invoking int10 from protected mode isn't guaranteed to have the desired effect. It certainly wouldn't work for linux vesafb panning. It might work for dos extenders, they might have the idt entry for int10 and other bios interrupts setup accordingly to do a real-mode -> bios call -> protected mode transition to simplify porting dos code to the 32bit extender. But even for that use case it is IMHO pointless as the reason to have a 32bit interface is to avoid the expensive real mode switch in the first place ...
I needed DOS to work and it did, for me, in turn, linux vesafb is pointless.
One can't issue "int 0x10" in 32bit mode under DOS and expect it to do anything reasonable. It may have worked for your particular application, but it is just as likely to crash the machine with the next application.
-Kevin
On Wed, 18 Apr 2012, Kevin O'Connor wrote:
On Wed, Apr 18, 2012 at 10:45:06PM +0400, malc wrote:
On Wed, 18 Apr 2012, Gerd Hoffmann wrote:
We talked with malc briefly on irc yesterday, and this is what he gave me:
http://cvs.savannah.gnu.org/viewvc/vgabios/vbe.c?root=vgabios&r1=1.47&am...
this is not the test case but the missing support he's referring to.
It appears the patch implements just 2 functions which both just does int10,
It isn't that simple. Just invoking int10 from protected mode isn't guaranteed to have the desired effect. It certainly wouldn't work for linux vesafb panning. It might work for dos extenders, they might have the idt entry for int10 and other bios interrupts setup accordingly to do a real-mode -> bios call -> protected mode transition to simplify porting dos code to the 32bit extender. But even for that use case it is IMHO pointless as the reason to have a 32bit interface is to avoid the expensive real mode switch in the first place ...
I needed DOS to work and it did, for me, in turn, linux vesafb is pointless.
One can't issue "int 0x10" in 32bit mode under DOS and expect it to do anything reasonable. It may have worked for your particular application, but it is just as likely to crash the machine with the next application.
In theory - yes, in practice most DOS extenders do bounce those (DOS4G, DOS16M, Wext, pmode/w, whatever), the use case was old DOS demos and it's sufficient for it.
On Wed, Apr 18, 2012 at 03:07:35PM +0200, Gerd Hoffmann wrote:
seavgabios has no 32bit code at all at the moment. vesa pmi didn't seem to be important enougth to change it.
seabios is a 16/32bit hybrid with some code being compiled twice for both modes; dunno how reusable the seabios infrastructure is.
If 32bit calls are needed, then I expect the same would be done for the VGA BIOS.
Unlike seabios seavgabios has no fixed load address, which makes things a bit more complicated when it comes to global variables I think.
That's not an issue as the "32 bit segmented" wrappers in SeaBIOS already handle code relocation.
The complexity is in updating the build scripts to work for both SeaBIOS and SeaVGABIOS. It's not difficult, but it is a chore.
As others have mentioned in this thread, I would like to get a hold of one of the applications that require the 32bit vga bios support.
-Kevin
-
Gerd Hoffmann -
Kevin O'Connor -
malc