From:	sandmann AT clio DOT rice DOT edu (Charles W. Sandmann)
Subject:	Re: Putting together a "fixed" GO32 1.10
To:	karna AT pobox DOT upenn DOT edu (Animesh Karna)
Date:	Wed, 30 Jun 1993 13:50:12 -0600 (CDT)
Cc:	djgpp AT sun DOT soe DOT clarkson DOT edu (DJGPP Mailing List)

> If I understand correctly, putting together a "fixed" go32 1.10 requires the
> following:
> 
> -- the patch posted to this mailing list, which adds the "nodpmi" option
> 
> -- replace the graphics.c (is that correct?) file in the go32 source with
> an older version.

The go32 1.10a I put in csdpmit1.zip has the new graphics.c routine, but
by *LUCK* my tcc version does not destroy AX on the assignment to prev_es.
I don't know any way except with the -S option and looking at the assembler
to know if your bcc/tcc compiler will work.  There is another problem with
the 1.10a - that some register (I believe ESI?) is returned to the 32 bit
code with bytes per scanline.  This can cause problems in some routines 
that expect ESI to be saved.

Using the old graphics.c from 1.09 fixes both these problems, but you must
also edit out the "VESA" sections from GRPROT.ASM (since they reference a
variable in the new graphics.c that will not be defined).

V1.11 rearranges the inline assembler in GRAPHICS.C and returns bytes per
scanline in EAX instead to provide VESA support, working graphics, and 
backward compatiblity.  The GMVESA libraries would need to be changed to
use EAX instead of ESI.

> The reason I'm wondering about this is that I believe the csdpmit1.zip
> file on omnigate doesn't have source or patches for how to fix the go32
> source.

Sorry, my mistake.  I had sent a cspat10a.zip file to some people with the
source, but I must have forgotten to upload it to omnigate.  Since it is
currently max user limited, I can't do it now (and I will be unavailable
for week or so).

- Raw text -