Mail Archives: djgpp/1993/03/16/04:32:00
I hopefully assume that my "vesa" version of go32 DOES WORK with all the
programs and video drivers. Please correct me if I am wrong (nobody did so far).
Certainly official VESA support is crucial. Hope DJ will acknowledge it.
I am still working on VESA support, and possible new video driver architecture.
DJ has announced his concept of go32-2.0, which is quite similar to what I
wanted to do. Current graphics driver architecture seriously limits the capabi-
lities of graphics interface. The architecture I am planning to develop allows
for using all the VESA functions (incl. bigger logical screens with panning and
page flipping). I would like to treat it as a standard base platform for graphics
interface, not requiring any external drivers. BUT, special features of some
VGAS (blitters and hardware cursor support) could be used by means of dynamic
linking of card-specific extension libraries instead of software-only standard
functions.
I vote AGAINST physical mapping of whole video RAM into system's address space,
because by the end of this year most of PCs will already have 16MB memory
installed, and this continuous mapping is non-standard feature (although it
appears in most of modern chipsets).
BTW: There is no space in projected go32-2.0 memory map for graphics memory.
Does it mean that there will be no graphics support? :-).
DJ, please allow for transparent calling of all the real mode ints from
any other mode (application and exception handlers), without telling us
that we should change something in exphndlr.c. I would like to see this
improvement in 1.10. I would also like the int86x function to work properly
(the problem lies also in exc. handling) - I mean: PASS THE CONTENTS OF
SEGMENT REGISTERS from SEGS structure to real mode int handlers.
Thanks in advance...
Gregory
- Raw text -