Nice job, so far.
Eventually we'll have to make it so that someone can call C000:3 without
that restoring the old INT 10 vector. It's assumed that you can (e.g.
DOSEMU does in some cases) but for now let's not worry about it.
Jeroen: I'm assuming you have Ralph Brown's Interrupt List, right? It
includes info on VBE.
I think the first step is to make a 16-bit RGB 640x480 video mode, that
is _NOT_ linear (at first). There needs to be one banked video mode
anyways since any real card supports it, and since any program will
assume a VESA 2.0 card can support VESA < 2.0 functions, which allow for
banked video modes.
Eventually, we'll need to add BIOS support for some of the (banked)
modes, so before you add graphics support for anything else, figure out
how you can make it generic enough so that it'll work in the banked VESA
modes and the regular BIOS modes.
Make a bank size of 64KB since that's standard. To be 100% compatible,
you'll need to _translate_ INT 10 VESA requests to a fake chipset and
output those to a port the VGA card uses anyways. That way someone can
(like they can on a real system) track all the I/O operations the BIOS
does to set a given mode and then repeat the operations, thus setting
the mode without the BIOS. I used to do that to change banks (before
VESA 2.0 was standard).
Just make it an overly simple "chipset", like output some code to
'unlock' the "chipset", and another code to "lock" it. These codes are
called "keys".
Study VGA.CC because you'll be extending it. First off, use the
A0000..AFFFF range: make each write to that range go to FAKECHIPSET.CC
or whatever and return right away if the FAKECHIPSET function returns an
int >0. Then have it return an int >0 if the "chipset" is handling the
write instead of the VGA.CC thing. DO the same thing for all I/O writes,
reads, and memory writes, reads, that are registered by VGA.CC.
At first, make FAKECHIPSET _only_ recognize the "lock" command when it
is unlocked. Thus your fakechipset I/O port read and write 'callbacks'
would return 0 if the chipset is locked, UNLESS the the command is to
unlock it.
Then make the BIOS unlock the chipset, write to the I/O ports whatever
you want (e.g. write 0001 to set video mode 1 which could be (if you
want) 640x480x16), then lock the chipset.
Then make the chipset handler translate I/O operations to a more generic
function set. Thus it might call, upon receiving 0001h),
GenericThingy(THINGY_SetVideoMode_REQUEST, VESA_BANKED_RGB_MODE, 640,
480, 16).
Then
Jeroen Janssen wrote:
>
> Hello (again),
>
> I put my current vbe extension plugin source code at
>http://www.darius.demon.nl/plex86/
> for those interested (it's a 5K gzip'ed patch).
>
> it contains:
> * vbebios.nasm - an expansion rom bios (that hooks up int 10h and outputs to
>a specific
> port when a vbe function is called)
> * vbe.c/vesa.h - a plex86 plugin (that hooks to a specific output port and
>implements
> (the start of) a vbe implementation).
>
> (functionality is at the moment "equal" to my previous expansion rom, but now the
>actual
> code is part of a plex plugin)
>
> The "big" question(s) I have at the moment are:
> * how can I implement a linear frame buffer? (can I use plugin_register_mem_map_IO
>for
> this?)
> * how should I display things? (prototype could use a seperate window to output in,
>but
> that doesn't look nice to me on the long run).
> * does anyone have suggestion on how to proceed further?
>
> --
> Best regards,
>
> Jeroen Janssen
> ---
> I must confess the the activities of the UK governments for the past couple
> of years have been watched with frank admiration and amazement by Lord
> Vetinari. Outright theft as a policy had never occured to him.
> -- (Terry Pratchett, alt.fan.pratchett)
