Mail Archives: djgpp/1996/12/30/18:35:28
WiredBox writes:
>Over the last couple weeks i've been designing a very optimized vesa
>graphic driver to handle 8bit modes, and I have a real slow down in
>my code thats caused by the fact that I have to call int86 to gain
>acces to vesa bios function 05 - set window offset. What I want
>to do is have my set mode function call function 01 - vesa mode info,
>which returns a pointer to the cards build in set window offset
>function, and then use the pointer returned to execute that function
>directly. I was wondering if there is a way to execute that video
>board function without having to resort to inline asm....
The problem here is that VESA is a 16 bit real mode API, and djgpp
produces 32 bit protected mode programs. To call those VESA functions
you will have to switch to real mode, which can be done with the
__dpmi_simulate_real_mode_procedure_retf() function. I very much doubt
whether this is worthwhile, though, because it still involves the
protected mode -> real mode switch which is the reason int86 is so slow.
The solution is to use VBE 2.0, which provides a 32 bit protected mode
API. On some cards it will give you access to a linear framebuffer,
which totally removes the need to bank switching. On _all_ cards, it
gives you access to protected mode bank switch functions, which you can
copy into your address space and then execute directly. Using these will
probably require some asm, but they are extremely fast (as efficient as
writing customised hardware-specfic bank switch code, in fact).
You can get a copy of the VBE 2.0 spec from SciTech's web site
(www.scitechsoft.com, if I remember right). For an example of using
linear framebuffers and the protected mode bank switching interface,
take a look at vesa.c from my Allegro library.
/*
* Shawn Hargreaves - shawn AT talula DOT demon DOT co DOT uk - http://www.talula.demon.co.uk/
* Ghoti: 'gh' as in 'enough', 'o' as in 'women', and 'ti' as in 'nation'.
*/
- Raw text -