Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA29697 (5.65c/IDA-1.4.4 for ); Fri, 18 Oct 1991 16:05:22 -0500 Received: by watserv1.uwaterloo.ca id ; Fri, 18 Oct 91 17:01:17 -0400 Date: Fri, 18 Oct 91 17:01:17 -0400 From: Dave Stampe-Psy+Eng Message-Id: <9110182101.AA08021@watserv1.uwaterloo.ca> To: glove-list@karazm.math.uh.edu Hey, thanks for the 320x400x256 code fragment! I had already figured out how get that resolution, and how to get 2 pictures, but I couln't figure out how to write the pictures without leaving the mode. (A bit misleading, calling SC#4 bit 3 "odd/even"!) A bit expensive in time, constantly changing the plane write register, though. Guess I'll have to figure out another damn 4-pass write algorithm. (B-{) I think that VR applications would be better served by using 4 pages of 200 lines, as that cuts down the rendering time and allows double buffering. Any comments on using 16-color modes for even faster rendering? Is there ANY way that so few colors is sufficient for filled-poly VR work? Which brings up the topic of reprogramming VGA cards to achieve new resolutions and timings. Cheap LCD displays are going to need this to work properly. I did some work last summer on getting NTSC timings to run Sharp LCD panels, but I had to add a new clock source via the VGA feature connector. Any idea how cards from different manufacturers handle radical reprogramming of the registers? Is the timing (i.e. blanking period) and "screwy" video modes reliable across all cards? About the Sega driver: looks a lot like the push-pull driver I developed a while ago. I didn't consider using the RS232 port as a power source then as I wasn't sure of the current capacity. Using a CMOS part as an oscillator makes it draw a LOT more current than the spec sheet suggests. It DOES get the needed 20-24V signal output that the glasses need for full shuttering, though. -Dave Stampe