Date: Tue, 16 Mar 93 09:19:41 EST
From: DJ Delorie <dj AT ctron DOT com>
To: gbm AT ii DOT pw DOT edu DOT pl
Cc: JMILLER AT chess DOT eisc DOT utoledo DOT edu, djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Re: Multiple go32's

>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.

It is.  Supporting ANYTHING that increases use of djgpp/go32 is
important.  Post diffs!  As long as they don't break other things,
I'll include them.  Also, coordinate grx drivers with Csaba.

>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).

Hopefully, the GRX library will become good enough to warrant hiding
the graphics driver completely, and then all those problems will go
away.

>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? :-).

The space reserved for "user shared libraries and mappings" is the
correct space.  The architecture assumes that the driver can handle
vmem being mapped *anywhere* instead of at a fixed location.

>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.

The ability to service interrupts with drivers in protected mode was
mentioned in the notes.  In go32v2 I expect the extender to handle
NONE of the int86 functions.  Instead, it will have a generic hook
such that the application can build some code in the transfer buffer
and have go32 execute it.  That way, the application can add new int86
handlers without having to modify go32.  The int86...() functions
would be emulated in libc.a through a dispatcher that called the
appropriate routines, with hooks to add new routines.