Supporting extension ROMs and beyond...

[Eric W. Biederman]

Stefan Reinauer <stepan at suse.de> writes:

> * ron minnich <rminnich at lanl.gov> [030812 15:33]:
> > On Tue, 12 Aug 2003, Stefan Reinauer wrote:
> > 
> > I'm not so sure. The emulation code supports the INT functions needed for 
> > vga setup. I would actually be inclined to dump ADLO rombios.c completely 
> > and replace it with real C code. 
>  
> which is what the freebios1 bioscall code and util/vgabios/testbios do
> already, just in a non-complete way.
> 
> > ADLO is a great proof-of-concept but after walking the code I find too 
> > much assembly in there, most of it not needed.
> 
> > It's the bochs heritage. 
> 
> definitely. they put a lot of focus on having all the fixed address bios
> entries at the right place, but we hopefully dont need that to
> initialize vga (at least the milo x86 emulation code never did that)

Looking at the various specifications there is an additional route
we can take.  We can have the 16bit trampoline detect if it is running
in v86 mode, and if so use the appropriate DPMI/VCPI/XMS functions to
switch to protected mode instead of our hand crafted code.

That should allow us to run under Win9x, freedos, and djgpp.  For
Freebsd we will probably need a couple of the very most common calls
implemented in the 16bit trampoline as well.  And of course we can
still implement the legacy entry points.

- It is not clear what an Option ROM will care about so being as
  backward compatible as possible is a real plus.

- Going with a solution that can (at least in theory) handle
  all of the legacy backwards compatibility cases will allow us
  to concentrate on a single implementation.

- Going with a solution that is primarily 32bit C code will allow us
  to reuse the code in appropriate ways.

- Not using v86 mode by default will allow a high degree of
  compatibility anyway.

Does a version of ADLO that runs as 32bit C code sound reasonable?

Eric