🚀 go-pugleaf

Hi gang,

I have a program that wants to turn interlace on under certain
circumstances, so what I do, is attempt to determine what state the
machine is in when I start up so I can put it back that way upon
exit.  

Now I realize there are basic problems with this in a multi-tasking
environment, if another program were to set interlace on while my 
program is running, then my programs exit would knock it out again.
Ok, I'm willing to live with that.  It's rare, and I've heard too many 
people complain about programs that leave interlace on and don't clean 
up after themselves.

I used the old PD SetLace command as a model, and basically do this:

	oldlace = GfxBase->system_bplcon0 & INTERLACE;
	RemakeDisplay();

	.....(do stuff....

and on exit:

	GfxBase->system_bplcon0 |= oldlace;
	RemakeDisplay();

Ok.  Seems to work fine.  That is, until some (but perhaps not all)
Genlocks are introduced into the equation.  What we get is a situation
where on exit, the display suddenly loses sync with the Genlock.  It seems
the genlocks are setting the screen into interlace mode via a hardware
technique (or something) which neglects to let the software know, my
program thinks the system is not in interlace, and sets it back to that
state upon exit causing the lost sync.  Workaround seems to be to run
the old SetLace command first which turns on interlace in a fashion that
my program correctly recognizes.  There's some question that the DoLace
command supplied with SuperGen *doesn't* fix the problem while SetLace does.
(I have no idea what DoLace actually does, it has been percieved as a
possible fix).

Questions:

	1. How are these genlocks putting the system into interlace mode,
	   and how can you tell from software?

	2. Is this a bogus approach and instead should I be continuing to 
	   irritate everyone (including me) by simply leaving the screen 
	   in interlace when I exit?

Keith Doyle
#  {ucbvax,decvax}!trwrb!cadovax!keithd  Contel Business Systems 213-323-8170