>* the ROMBIOS should be changed in such a way it will scan D000-F000 for
>0xaa55 on 2k boundaries, so it will be easy to add optional bios'es (I
>would like to use the VESA BIOS in combination with the VGA BIOS instead
>of completely replacing the VGA Bios).
Is BIOS code relocatable like that ? I'm not sure...
>* the video host <-> guest "protocol" could be split in several items:
> - display framebuffer; continuus video memory access (the "simplest"
>form); the VESA VBE can use this to provide an linear frame buffer. note
>that in this case it's probably "not possible" to let the guest code
>notify the host about areas to update (so probably only fullscreen
>updates as far as the guest is concerned). maybe we can solve this
>later.
The page dirty bit should give some indication, look into this.
> - display framebuffer with area update functions; let the guest notify
>the host about dirty areas (this requires that the guest os is able to
>tell the guest display driver about those dirty areas)
> - HW Accelleration (ie OpenGL), no idea yet
Well, my idea on these (not VESA, just our own accellerated drivers) was this:
(1) Get an overview of the complete SDL API
(2) Assign each SDL call a number
(3) Make a packet interface through a port, which simply forwards the calls
(using the call number assigned above) to SDL.
(4) Make a few "special" plex86 calls for initialisation (like mapping the
framebuffer into the guest, this still needs to be implemented).
Now, the guest can "directly" invoke SDL in the host, including all the HW
accelleration stuff. You can the proceed to implement directx drivers and the
like on top of SDL.
>looking at the display framebuffer again, do we have a "nice" way to
>provide "video memory" to the guest? (it would be nice if I could
>allocate an SDL surface in a specific display format, get a pointer to
>the video memory and map this memory directly into the guests memory
>space - this would probably be done at the instance an user program
>switches to a gfx mode with that specific display format).
Not yet, I'm still looking into this (it's more complicated than I thought,
and I have very little spare time at the moment. Should improve in a few
weeks...).
>I don't like the idea to use "actual available" physical memory of the
>guest to provide video memory, because you need to make sure the guest
>os doesn't see it as "normal" physical memory and you will allways need
>to do an additional memory copy before you can display something.
Agreed.
>It seems also "obvious" to me that we would like to have a generic video
>interface in such a way that it is independend of the actual host
>display interface (X11, DGA, SDL, etc).
SDL is platform-independant, so there's no problem with using that as the
guest API.
-- Ramon
