Real Interlaced graphics on the A8 - getting closer

[ZylonBane]

Interlace is a trick too.

No, it isn't. It's an official component of both the NTSC and PAL broadcast specifications.

[ijor]

I think this horizontal counter is the key to it all... my routine works by changing Antic's DMACTL width settings (0,1,2, or 3) in the leadup to VSync.

Could it be that somehow, by engaging the 240-scanline bug that Antic itself can become confused in that screen region outside the normal 240 lines we can control.

 

Possibly. ANTIC has all sort of wierd behaviours when changing DMACTL "on the fly". We might be much wiser in a month or so, when Curt hopefully would publish ANTIC schematics.

 

Is composite sync a simple logic level switch, or an variable voltage?

 

CSYNC is just HSYNC xor VSYNC. It is digital as it comes from GTIA. Later it is of course encoded, modulated for the S-Video/Composite,RF.

 

Also - how does GTIA know to display "Black" (ie not background, but Black) outside the normal 240 scanlines we have control over? Is Antic outputting the VSync code on AN0-AN2 for the duration?

 

I'm pretty sure it is done by ANTIC sending "HBLANK" code. VSYNC code should be sent only during the actual Vsync lines.

 

The OS VBlank is sort of misnamed - it occurs well before VSync on PAL, and several lines beforehand on NTSC.

 

I think the name is correct. Vertical Blank is one thing, Vertical Sync is another. PAL has more lines per frame, so the "earlier" section of VBLANK is bigger. See the "famous" video screen timing chart on the hardware manual.

Edited January 29, 2009 by ijor

[UNIXcoffee928]

This is just a guess, but if you doubled the ANTIC/GTIA display hardware, I would presume that you could use a variation of this technique to drive two LCD panels displaying two separate images or two separate text screens (ex. to create a virtual 80 columns, with half of it on one LCD panel & half on the other LCD panel). So, instead of an interlace, you would have dual controllable video signals.

[+Stephen]

I have a feeling that some scan-doublers might produce a hi-res picture anyway without tricks, as per some LCD monitors and capture cards.

 

Can you try the same settings you have there, and turn the Interlace option Off and see what you get?

If I keep the settings the same but turn interlace off, I do not get the 16 steps in the line. However, if I reverse the field order it looks the same.

 

Stephen Anderson

[ijor]

I made a few tests. I tested more the ANTIC behaviour than anything else. It is difficult to be sure, but according to the tests, and also according to other quirks we already know about ANTIC, this is more or less what seems to be happening:

 

ANTIC sets some latches when displaying an active line. Some latches are set on every displayed line, others seem to be set only when displaying a hirez line.

 

Some of these latches are cleared somewhere at the end of the line. And possibly there is at least one hirez latch that is cleared only on the start of the next line. Next line meaning any active line with DMA enabled, including blank lines, but excluding VBL lines.

 

If the last line before VBL is hirez, then this latch would never clear. This is the 240 bug. If DMA is disabled on DMACTL during a hirez line, then you get the same behavior. This is the "bug variation" that Rybags seems to be using.

 

One of the consequences of the bug is that AN2 seems to become "semi-sticky". Probably because hirez logic forces AN2 on during the whole active porition of the line. Remember that all non-hirez modes can display background, which is the only "active" AN code that needs AN2 to be cleared. It is not completely sticky, but only (more or less) outside the Horizontal blank range.

 

ANTIC still keeps its "standard" horizontal and vertical timing and syncing. Except that the sticky AN2 messes the codes sent to GTIA. And this would somewhat alter GTIA video syncing generation.

 

Without a PAL machine, can't say for sure what exactly Rybags program is achieving. I run the program under emulation, just to see the timing when DMA is enabled/disabled. Rybags, seems you are starting to "play" with DMACTL long before Vsync. If so, it won't ever work with NTSC like this. Not because of the OS VBL routine, but because simply the NTSC Vertical Blank is much closer to Vsync. You would need to start the procedure even before VBL starts. This is turn might mean that the behavior would be different, because ANTIC doesn't behave the same during VBL.

 

Either way, it is very unlikely that a "standard" interlaced signal is being generated, where each full interlaced frame (two "normal" fields) has an odd number of scan lines. But instead, seems one frame is generated shorter than the other.

 

Once again, all the above is not much more than speculation, or an educated guess in the best case.

Edited January 30, 2009 by ijor

[Rybags]

Thanks for that - some of that is as I expected. I found that setting DMACTL off during the last hires line is a "cheaper" way to invoke the 240-line bug than having to build a screen with a hires line at the end of the display.

 

Re the effect itself - I was a bit surprised too, but it seems that tweaking DMACTL well before VSync by far generates the best results. I find on PAL that doing so starting somewhere between/including a VCount value of 133 to 135 is most effective.

 

I was puzzled somewhat, so I found the early version of the C= Plus/4 code that does Interlace on that machine and played around with it.

I found there that you could bring it forward by as much as 10 scanlines or so and still get interlace.

 

On NTSC, I expect the same behaviour should be possible, but of course I have no NTSC A8 gear here that I can test with. As I've said before, NTSC only presents a problem for others ATM since the OS VBlank code is getting in the way.

 

Re - ANx output after line 240:

- it's clear that we get "n11" output in the lines leading up to VSync if the screen is enabled, ie bits 1-0 of DMACTL are non-zero. It's easily proven since you get PF1's colour displayed in that area (remembering that it inherits PF2's hue value as per a hires mode).

 

- I've even found on my capture card (by getting the screen to roll) that in the 3 VSync scanlines some colour/luma information is output, and not just blank data.

[carmel_andrews]

is there a possibility by adding an addititional antic/gtia and running this interlace program you can increase the vertical rez beyond 240...or is there more to it then just the anitc/gtia

 

if interlace is possible does'nt that also increase the vertical rez

[Rybags]

Doubt it - having extra GTIAs makes no real difference in the context of doing interlace.

 

The way I see it, the main benefit of adding GTIAs is (I think Bob's) modification where three GTIAs receive the exact same AN0-2 data from a single Antic, each addressable individually within the $D0xx page, and each one outputing R, G, or B.

Edited January 30, 2009 by Rybags

[Rybags]

Some (hopefully) good news:

 

I've just tried an enormously simplified routine and it's working great on 2 of 3 TVs I've tested it on.

With luck it should adapt to NTSC easily too.

 

Just got to now create a cycle-exact tweakable version so I can get the timings absolutely precise, and hopefully I'll have something that works universally very soon.

[Heaven/TQA]

Rybags...again my noob question... What is the advantage of your version against a standard 2 DL & VBL interlace?

[Fröhn]

Rybags...again my noob question... What is the advantage of your version against a standard 2 DL & VBL interlace?

The advantage is that every 2nd frame is moved 0.5 rasterlines down so the rasterlines of two frames are interleaved.

[Heaven/TQA]

ah. ok.

[atariksi]

Check the pictures... this is doubling the vertical resolution.

 

And not by some "trick" where 2 images are overlayed and it tries on eyesight tricks.

Interlace is a trick too. To really have 525 rasterlines @ 60 Hz you'd need... 525 rasterlines @ 60 Hz and not 525 rasterlines @ 30 Hz

 

You can get or build a de-interlacer to use the 525 lines of resolution @60Hz once the interlace is working consistently...

[ZylonBane]

Rybags...again my noob question... What is the advantage of your version against a standard 2 DL & VBL interlace?

The advantage is that every 2nd frame is moved 0.5 rasterlines down so the rasterlines of two frames are interleaved.

No, it's moved down ONE rasterline. The Atari's normal non-interlaced display only uses half the available rasterlines.

[Rybags]

 

First multicolour picture in interlace (screendump from my capture card). Just a doubled vertical resolution Gr. 15 job, no extra fancy stuff other than another DLI to give the text another colour.

 

Note how nicely it removes the jaggies on the acute diagonal at the front of the ship (above the word "Graphics")

 

Hoping to have something releasable real soon... working on a bundle that has the configuration menu built into it... and with luck it'll reduce the amount of fiddling needed from the hundreds of possibilities of the previous one, down to maybe a few dozen or less.

 

 

Might do a TIP picture next - it'll be very interesting to see how that goes, with the Gr. 9 and 10 offset from each other by the half scanline.

Edited February 2, 2009 by Rybags

[roland p]

The picture looks great!

I hope to hook up my atari to an old-fashion crt monitor soon, to see what it looks like.

[UNIXcoffee928]

Beautiful work!

[Ready _]

First multicolour picture in interlace (screendump from my capture card).

 

Can you post the non-interlaced source, just for comparism, please?

[Rybags]

 

 

I don't actually have a 160x192 version. Top picture in this post is a mockup of how it might look in 160x192. The original was found via Google Image Search (bottom pic).

 

I resized it from 1024x768 down to 160x384, discarded the colour info. Edited some of the starfield, generated the text in MS Paint, then used the Perspective tool in PS to stretch it as seen, then pasted it in.

Also, I rotated the orginal somewhat, for better screen fit, and I also wanted that acute diagonal to show the smoothing that the extra resolution provides.

 

Correction - the version you see from the Atari is actually 2x192 high pics. As individual pics, they don't really look right since you're losing half the information, which makes it significantly different from the mockup in the first pic here, which uses Bicubic blending.

 

[Ready _]

Thank you!

[flashjazzcat]

Fantastic work! Can't wait to see an interlaced 80 by 50 text display using this technique.

[potatohead]

For text, it might be possible to use this technique in combination with another one to get 640 x 384 monochrome graphics.

 

The 640 can happen in GR 8 or GR 0 modes, where you select two dark background colors and alternate them to shift high-res pixels on the screen. I remember red and blue being good combination. Might be red and green though. This worked on NTSC. I don't know if it's possible on PAL.

 

Alternating them every screen is the easiest and least CPU intensive. Could be done every scan line too, but that consumes a lot of CPU. Might be necessary for PAL. Don't know.

 

It works by taking advantage of the small sub-pixels seen when colors are chosen in the high res modes. Also handy to just do a luma input to an s-video source. Ordinary composite doesn't work so well for this. Way back when, I used a sharp black and white television to do this with a simple bitmap display.

 

There are basically 16 sub pixel positions, per ordinary gr 15 sized pixel. Plotting a high-res pixel alone in either the even or odd addressable position demonstrates how it works. Do this on a screen where the background color has been changed mid-screen to see the sub-color clock shifting that occurs. For text, who knows? It might work out well.

 

 

Nice work Rybags!! How good has it gotten for your various test TVs? You mentioned a lot simpler routine. What's the CPU cost right now?

[MEtalGuy66]

For text, it might be possible to use this technique in combination with another one to get 640 x 384 monochrome graphics.

 

The technique you describe would require 4 alternating "scans" of the screen to show all possible pixel positions... Talk about a flickering nightmare.. The only way that would be tolerable is if you were using some form of digital capture device that averaged all 4 "phases" and treated them as a single frame, every 15th of a second..

 

Interlace by itself is bad enough... and "flickering" gr.8 is even worse... add them both together.. Heh. That would probably trigger epileptic siezures in a good percentage of people..

Edited February 2, 2009 by MEtalGuy66

[Rybags]

That H-shift trick relies on "Bloom", ie - shifting of the screen, shrinking/expansion of the image dependant on brightness.

 

Problem is, each TV has it's own characteristics. Newer TVs do it somewhat less than older ones. LCDs don't do it at all.

 

Re- bigger text modes. Using bitmap mode would be necessary - doing it via the method of 2 chsets with left or right side having the character definition would mean they're still only 4x8 and each second one would sit slightly lower than the one next to it.

 

So, a bit costly... you'd be looking at 16K or so for the bitmap, plus the 2K or whatever character map you'd need to maintain to keep track of what's where.

 

Benefit though might be slightly easier reading... 4x16 rather than 4x8. Then again, you could sacrifice some V-height of the characters and go for 4x12 or something.

[Rybags]

CPU cost...

 

The latest variant only has to do the time-critical stuff twice during each second frame. Total cost, maybe 3-4 scanlines.

 

Problem is, the VSync (on PAL at least) happens long after the OS VBlank has finished. DLIs aren't an option because we're way offscreen.

Audio Timer IRQs would be a definate option, but I've not bothered at this stage.

 

So, at this stage it has a wait loop after the VBI. With the in-progress new version, I'm doing all the required stuff that the OS normally does because I want to ensure it works OK on NTSC machines too (it's VBI occurs uncomfortably close to VSync).

 

But, so far as during the normal display goes, nothing really changes, so all those tricks like APAC, TIP, repositioning PMGs, doing midline colour changes etc. can be done normally if you want them.