Using Interlacing For Double Vertical Resolution

[pcrow]

I've seen some references to some video tricks that suggested a clever hack, which is to essentially set up two different copies of screen memory and alternate between them, so that one is the upper half of each line and one is the lower, taking advantage of the interlacing of the display.  I haven't seen details on exactly how this works.

 

If you have, for example, a horizontal line in GR.8, will it be sent to the video exactly twice, using one scan line on the TV signal in both halves of the interlaced image?

 

If that's right, then I would think it would be a simple hack for a text mode to take a 8x16 font, split it into two fonts on the Atari, and alternate between them using a VBI.  (I'm thinking about the 8x16 VGA font from the PC as an example.)  Would that work?

 

What I can't find is anything that will tell me if the graphics is outputting the upper or lower interlaced lines.  Is there a trick to that?

[woj]

It's not quite as simple as that, you can start here and follow where it gets you:

 

 

Generally, @Rybags is your man here. One thing you will not find easily - Sophia 2 has the real interlace mode and the even/odd field can be read from a register.

[pcrow]

So from that thread, it sounds like it works pretty much as I thought.  It will get interlacing reversed half the time, so the user has to have a way to tell it to fix it (unless you have something like Sophia 2 that can tell you).  And some monitors don't display it correctly, likewise emulators don't do real interlacing.

[woj]

Putting aside emulators (Altirra does it as good as it can, with the recent test version doing also deinterlacing), and Sophia 2 that just does it, you only need to turn the option on (by hand, or using sconf), and swap the screens in vblank according to the odd/even field register, you step into unknown - some (most? all?) LCD TVs will do the interlacing without asking, but then you are at the 50% chance of getting the field correct. Then you go into exploiting the ANTIC 240 scanline bug to get some control over this and to make it work on real CRTs, some of which will take it, some won't. And then you have the upscalers and scandoublers, which may or may not work. Here I had some problems with RetroTink, but that was in the VBXE context, which yet another story. With regular graphics it did something, but it was messed up, and the mileage varied depending on PAL / NTSC.

[Rybags]

There's a hardware bug/exploit which allows simulating the interlaced signal.

 

Just alternating the 2 frames isn't sufficient, you also need the code that generates interlace.

Though some modern LCDs will do interlace regardless but you shouldn't rely on that to always be the case.

[pcrow]

9 minutes ago, Rybags said:

There's a hardware bug/exploit which allows simulating the interlaced signal.

 

Just alternating the 2 frames isn't sufficient, you also need the code that generates interlace

I don't get it.  The Atari always puts out an interlaced signal.  You're getting a VBI every 50th or ~60th of a second, which is the timing for putting out an interlaced frame (every-other scan line).  The only trick should be knowing whether it's doing the top or bottom half of the scan lines (something in the video circuitry must know this, but it's not normally exported).  What am I missing?  (Besides coding it and trying it?)

[Rybags]

It doesn't actually - same as most old computers and consoles.

The Amiga by default does progressive but also has an interlaced mode.

 

The video signal isn't broadcast standard but old TVs would handle it just fine.

The interlace is generated because there's a HSync pulse inserted halfway through a scanline which offsets the vertical sawtooth wave by 1/2 a scanline on the following field.

Progressive mode displays don't do that.