qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/3] switch to seavgabios


From: malc
Subject: Re: [Qemu-devel] [PATCH 0/3] switch to seavgabios
Date: Thu, 19 Apr 2012 14:50:20 +0400 (MSK)
User-agent: Alpine 2.00 (LNX 1167 2008-08-23)

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&r2=1.48
> > > > 
> > > > 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.

-- 
mailto:address@hidden



reply via email to

[Prev in Thread] Current Thread [Next in Thread]