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