What if I only sent an interlaced frame one out of every four or eight frames? It would fill in the unused scan lines and have much less noticeable flicker.
This doesn’t make any sense? What would this accomplish?
A progressive (“240P”) NTSC signal like CGA has a vertical sync period that’s an integer number of horizontal syncs long. This results in each line of the new frame retracing over the sweep of the last frame. (This means any particular pixel gets “re-lit” 60 times per second, which with typical TV tube phosphors is often enough to avoid visible flicker.) Strictly speaking there are no "unused" scanlines other than the vertical margins; you're getting 60 fully used frames per second that just happen to be composed of scanlines that, on typically sized CRT screens, are thin enough that there's black space between them. I mean, sure, I get that this is a nitpicky distinction, but it also seems kind of important.
An interlaced signal, by contrast, has a non-integer vertical refresh period; there is a half-length HSYNC pulse that “changes sides” with each half-frame. (technically an interlaced frame is two TV frames woven on top of each other; unless you want gross artifacts you should only modify the contents of the frame every 1/30th of a second instead of every 1/60th.) Remember, on a real CRT the horizontal scan lines are not actually horizontal: the sweep is always “slanting down”; the beam is moving *continuously* from top to bottom in 1/60th of a second in a sloped path, the Hsync just cuts that slope into 250-something little slices when it kicks the beam from right to left. On the periods in an interlaced picture where the half-length sync is at the top of the frame that “early kick” in the middle of the line resets the beam to the left margin when it’s halfway the vertical distance of a full line down; this causes the rest of that frame to be offset into what would have been the empty black scanlines of a progressive frame with the same number of lines, resulting in the tradeoff of offering twice the (potential) vertical resolution but at a frame rate likely to cause flicker for any feature that’s small enough to only exist on one of the half frames.
(… and that is kind of the point here as to why interlacing works fine for TV but is problematic for computer displays. A TV is usually displaying continuous toned photographs where there aren’t really distinct pixels, and those contents are always moving and changing. You don’t have the problem of someone sitting there staring at a fixed grid of letters where individual features vital for telling one glyph from another are strobing in place.)
Anyway, so with that said… what are you talking about with having an “interlace for some percentage of frames”? What does that even mean? First off, there’s a technical issue here; modern televisions (and by “modern” I mean even CRT sets from the 1980’s) use ICs that use timing information to determine if you want interlacing; randomly chucking a short Hsync into a stream of progressive frames will probably just glitch the display instead of giving you a proper interlace. (You might have more luck doing it on an old dumb CRT, but those are their own bag of hurt; sometimes you can’t get interlacing to work without implementing proper equalizing pulses and other obscure bits.) Getting a clean properly interlaced signal that works on all displays is a PITA, which is why most 70's and 80's vintage computers and video games didn't bother with it. (There were also the advantages of higher effective refresh rate, etc, but the increased complexity of interlace was definitely a factor.) Secondly, even if you can get it it work… what does it accomplish, exactly? Why are you enabling interlace in the first place?
If the intention here is to keep displaying 240 lines (IE, 200 active for CGA) then A: why bother, or B: if you really want it you can just turn on interlace all the time and it probably *wont* induce much noticeable flicker; it’ll just make the display look a little different. IE, if each interlaced frame has the same contents (IE, you’re basically “double-scanning” at 30 hz) no elements will be “going away” every other 60 hz, you’ll just get them redrawn offset into what was the black scanlines between rows. Effectively any given lit pixel will be “dimmer” because the lit area will be twice as large but completely refreshed twice as often, which across the whole screen averages out. Visually this version of CGA will look like CGA modes displayed on VGA, but, sure, more flickery-er-y. (Mostly because of tearing effects when framebuffer contents are updated.) If the display in question is an LCD (or something else with an upscaler) then actually it *will* be basically indistinguishable from CGA modes on VGA other than having wider margins, because an upscaler will get rid of any flicker from the interlace.
Lets say you *do* have a monitor that's willing to take a weird sync rhythm that makes it offset an update into the interlaced "gutters" between the normal scanlines every four or eight frames: what exactly does this accomplish? Instead of being black the scanlines will all turn into strobe lights that have 1/4 or 1/8th of the frequency of the normal updates... and the normally updated space will be black when the scanlines are flashing. Why would you want this? Unless you were displaying on a very long-persistence phospher monitor the offset updates might not be perceptable as anything other than an annoying glitch in your peripheral vision; worse case it might make the whole display appear to shimmer slightly. This doesn't seem like an improvement over normal progressive display.
On the flip side: If you want interlace *because* you want to actually do some kind of enhanced CGA that supports 400 lines instead of 200 then your idea of only inserting random interlaced frames is obviously a complete dealbreaker; the additional resolution you add will be completely unusable if it's only updating a couple times per second as a ghostly flicker in the otherwise black scanlines. If you want higher resolution then you need to just implement interlace properly and accept it's going to be flickery on a color CRT unless it has a line doubler. IE, it'll look just like an Amiga in 400 line mode. Which apparently some people were fine with; it makes me mildly homicidal, personally, but some people can tolerate it. And on a long-persistence green monitor 400 line interlaced can look perfectly fine; I've posted some screenshots of the homebrew video dingus I built a few years ago that can do interlaced monochrome displays of 512x384 or greater resolution and it looks basically like a slightly lo-fi Macintosh on a green monitor or through a composite-to-HDMI scaler. If you want to support Interlaced because you want to try to implement, say, compatibility with the AT&T 6300/Olivetti's 640x400 mode on an NTSC frequency monitor instead of the 25Khz monitor they used then by all means go to town.(*)
(*Weird note: The Tandy 1000 EX/HX/SX/TX's "Big Blue" ASIC has an embedded 6845 implementation that supports a mostly undocumented/nobody ever used it interlace flag. There's a couple demos out there that give me a headache, but it does kind of make me wish someone had actually written A GEM/PC Paintbrush/something driver that used it. Again, on a mono monitor it *would* actually be useable.)
... So, am I missing something here? Because I really can't wrap my head around this idea of just randomly shifting gears between interlaced and non-interlaced.
EDIT: FWIW, there is *one* good argument for implementing the "double-scanned interlaced" thing, at least as an option: the composite input ports on some modern LCD scalers hate the "progressive mode" and don't render it correctly. You mostly see this on those cheap little monitors that they sell on Amazon/AliExpress/etc that use a scaler more suitable for car infotainment and backup cameras than computer input. On these displays a "progressive" NTSC displays wobbles and flickers and otherwise looks like trash. I discovered with my homebrew experiements that double-scanned Interlace is a legit fix for this.
