delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1992/12/13/17:57:38

Date: Sun, 13 Dec 92 16:27:50 CST
From: csaba AT vuse DOT vanderbilt DOT edu (Csaba A. Biegl)
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Re: SUIT problems, again

This is in response to some more problems with SUIT.

>> (References to older messages deleted)
> I'm sorry, but no dice.
> 
> I am running on a '486/33, 8MB, Diamond SpeedStar SVGA (TSENG4K), DJGPP 1.08,
> QEMM 6.02 (I cannot find a version on my GRX library, but I got it at about
> the same time that I downloaded DJGPP 1.08), and I have 5MB available on
> my hard drive.
> 
> Here is my environment (these variables are *always* in my environment):
> 
> rem DJGPP 1.08 variables
> set COMPILER_PATH=/develop/djgpp/bin
> set C_INCLUDE_PATH=/develop/djgpp/include
> set CPLUS_INCLUDE_PATH=/develop/djgpp/cplusinc;/develop/djgpp/include
> set OBJC_INCLUDE_PATH=/develop/djgpp/include
> set OBJCPLUS_INCLUDE_PATH=/develop/djgpp/include
> set LIBRARY_PATH=/develop/djgpp/lib
> set TMPDIR=/windows/temp
> set GO32TMP=/windows/teep
> set GO32=ansi driver /develop/djgpp/drivers/tseng4k.grd gw 800 gh 600
>          ^^^^                                              ^^^    ^^^
> 	tw 80 th 50 nc 256
> set BISON_SIMPLE=/develop/djgpp/lib/bison.simple
> set BISON_HAIRY=/develop/djgpp/lib/bison.hairy
> set FLEX_SKELETON=/develop/djgpp/lib/flex.skeleton
> set GRXFONT=/develop/djgpp/contrib/libgrx/fonts
> 
> (note that the above "GO32" line was re-formatted in the editor for clarity, 
> but is one entire line in the environment)
> 
> I experience the *exact* same symptoms.  I have tried changing my driver
> (VGA.GRD), running with and without QEMM, recompiling GRX and then SUIT.
> 
> I can run the GRX "test" applications with no difficulties with the above 
> settings.  With SUIT, I get the same "orange" glow as the other individuals, 
> but I never get into graphics mode and nothing appears on my screen. I have 
> tried redirecting stderr and stdout with 4DOS (">& demo.err" and ">&> 
> demo.err"), but because the computer stops and I cannot end the program, the 
> output is never flushed and I end up with a 0-length file after a reboot.
> 
> It's probably some kind of configuration setting, I'm sure (since somebody
> else with a similar setup is running it).  I have spent more than a full day
> trying to figure this thing out, and it is really becoming frustrating.
> 
> Bob
> 
> P.S. Sorry for the size of this message, but I am really looking forward to
> seeing SUIT, and I'd like to find a solution to this problem.
> ----------------------------------------------------------------
>------------------------------------------------------------------
> --
> Just an idea: Do you use et4000.grn ? You should with libgrx and nc 256.
> Only the 'new' drivers accept this parameter and I don't know what the old
> driver does with this line?
> 
> --Chris


First of all, assuming that the "orange glow" is indeed some fatal error
message from the extender or the program, using ANSI.SYS will almost
certainly prevent you from seeing it in a high-res graphics mode even if
your SVGA BIOS is competent enough (the Tseng 4K's IS) to display it.

The only real problem I have seen with SUIT is that it is not real bright
when you restart a program with an existing .SUI file in a graphics mode
whose resolution does not match the one for which the .SUI file was 
created. From the above message it seems that the card is used in
800x600x256 resolution (do you have a 512K card?). The enclosed
.SUI files are for 1024x768x256. A SUIT program does a competent
job of adjusting to the screen size if it is started from scratch (no
.SUI file), but things can go horribly wrong when there is a mismatch.

You can do either of the following two to correct this:

  1) delete the .SUI file. SUIT will start up with randomly placed widgets,
	 but this is easy to correct with the interactive tools once the
	 program runs.

  2) at least edit the .SUI file to match the resolution you use (your
	 card can provide). The three '#define'-s at the head of the file have 
	 to be changed.


(A good test is to change the three defines to 640, 480 and 4 (4planes = 16colors)
in, say, DEMO.SUI and use the STDVGA.GRN driver in the GO32 env var. 
This way you can be sure that it is not a driver / card compatibitlity
problem.)

As for the drivers: whenever there is a .GRN driver for a card, it should be
used. (I included only those .GRN-s I can test ) A .GRN driver does everything
a .GRD does and some more. If there is no .GRN, the .GRD driver can still 
be used, go32 and libgrx will use only the common subset of driver sevices.
(I.e. the "nc" field and the color argument to 'GrSetMode' will be ignored)   
However, if an "old" driver confuses go32 and the library into thinking that
it is a "new" driver (it is encoded on some bits in the third word of
the driver file) then, again, things WILL go horribly wrong.

There is very little (except for the above) in the SUIT demos what
can go wrong
if all the GRX tests execute successfully on the system USING THE SAME
RESOLUTION SUIT IS TRYING TO USE. Critical tests are:

	FONTTEST
	MOUSETST

That's all I can can think of. Suggestions are, of course, welcome from
everyone who had initial problems with SUIT, but solved them. 


Csaba Biegl
csaba AT vuse DOT vanderbilt DOT edu



- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019