Real Interlaced graphics on the A8 - getting closer

[potatohead]

Actually, it's not bloom. That's a different thing, and not reliable as you say.

 

What I'm talking about is the chroma signal manifests as a small sub pixel. If you take an ordinary full color, one color clock pixel and imagine 16 little pixels all packed in there, that's exactly what happens when you ask for a specific hue. Each hue shifts that little pixel to a specific position.

 

Using two hues then, it's possible to interlace the pixels together to take advantage of that. Only works on the Atari in the high res text or graphics mode. I've done this in the past, and it's absolutely not bloom. On most displays these days, it would have to be luma on the s-video in to work well. I don't think most color TV's are capable. Maybe they are. My larger CRT WEGA has the resolution to do it, with the color turned off.

 

It's not TV dependent, as much as the TV has to have the bandwidth to resolve it clearly. Most newer TV's do.

 

@MEtalGuy66 Yep. That's a full on NTSC interlace. When you do it on a color TV, you get lots of colors. If you do it on a B&W TV, it's actually not all that bad, if every other scan method is used for the 4 unique frames. This is what your TV broadcasts do all the time on NTSC. The best bitmaps are moderate contrast, of course.

 

You have a good point though. No disagreement about that.

 

Interestingly, newer LCD / Plasma displays might filter that out, just leaving the bitmap. If so, that might be fun to try one of these days. I've got a newer plasma. Been wanting to hook a 2600 to it, to see if the de-interlace filters out the 30 HZ flicker in games too. It does some video processing.

 

Anyway, on the topic of text, perhaps just the 640 pixel deal, non interlaced would yield 80 nice chars. Or, a 64 char display for this technique with more rows?

 

Again, good stuff rybags! Just thought I would mention the other technique in the context of text. Didn't want to derail your excellent thread!

[MEtalGuy66]

Interestingly, newer LCD / Plasma displays might filter that out, just leaving the bitmap. If so, that might be fun to try one of these days.

 

YEah the LCD (Sony SDM-V72W) I have doesnt "average" as much as it does "drop frames" in both composite and s-video input modes.. However, my cheap little "game-screen" style LCD (7"x5" screen) does appear to either average, or actually produce a 1:1 NTSC scanrate... Because I can run programs like COLRVIEW or FlickerTerm, and it looks the same as on my C= 1084S..

[Rybags]

Interesting about the hue value shifting pixels... no idea if it works on PAL.

 

I guess you have to maintain whatever hue for the duration of the line to keep the same shift?

Can't do something tricky like just put a Player on the far LHS of the screen to initiate the shift and have it maintained?

[potatohead]

The little game screens appear to rock! My son has one, and it's a great little display.

 

I'm not entirely pleased with a lot of the HDTV displays for this kind of thing. There is a lot of video processing going on. If you've a fast TV, it's cool. Slower ones take short cuts and have latency.

 

Gonna be a whole new world with those things.

[potatohead]

I don't know if that can work or not.

 

Given how the players work, it might be possible. It's been a long time since I did that. I basically was a kid at the time. Spent a month, just getting the core 640x200 bitmap up and going.

 

For PAL, the color phase shifts every line anyway. Seems to me, just shifting it back by changing the display color in time with the PAL color would nullify that. I just don't know that much about PAL.

 

I do know it's an artifact of how GTIA produces color. You can see the sub pixels easily enough by just running a 4 color mode, and plotting a few pixels in one color, say red, then another one, say blue. Turn the color down on your TV, then crank the sharpness up and go look at the sub-pixels. That's actually chroma data that shows up as luma data.

 

On a PAL TV, I'm not sure they are stable. They might be interlaced because of the alternating color shift going on. On an NTSC TV, you can see the pixels, and they are stable.

[thorfdbg]

Interesting about the hue value shifting pixels... no idea if it works on PAL.

 

I guess you have to maintain whatever hue for the duration of the line to keep the same shift?

Can't do something tricky like just put a Player on the far LHS of the screen to initiate the shift and have it maintained?

It should, but it requires more care. As for NTSC, the color signal in PAL is interleaved with the luminance signal, thus the color signal impacts the luminance signal. However, first of all, the relative frequency of the color carrier in respect to the luma carrier is different, which means that the sub-pixel shift is different, and the color signal modulation is alternated every scan-line, which means that the sub-pixel shifts will depend on whether you are in an even or in an odd scan-line. The advantage might be that PAL also averages the color signal from an even and odd scanline, thus if you alter the color between the two lines, you will still have a neutral grey background when choosing the right colors. I suspect, however, that modern TVs are prepared for the interaction of the color carrier with the luma signal and by that also average the sub-pixel shift out.

 

So long,

Thomas

[Velcro_SP]

That's an amazing picture to be displayed on an Atari 8bit! Am I correct it can be displayed on an (unexpanded) Atari 8bit? Fantastic!

 

 

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.

[Rybags]

40K RAM will be needed (to run the program) when I get the pic ready.

 

I could get it working on a 32K system, but I think they'd be a small minority these days anyway.

 

16K systems - not really feasible... a 160x384 bitmap takes nearly that amount for the DList + pixel data alone.

Edited February 3, 2009 by Rybags

[Fröhn]

It should, but it requires more care. As for NTSC, the color signal in PAL is interleaved with the luminance signal, thus the color signal impacts the luminance signal.

Only if you use composite. Y/C (s-video) doesn't show any artifacts.

 

However, first of all, the relative frequency of the color carrier in respect to the luma carrier is different, which means that the sub-pixel shift is different,

There is no such thing like a luma carrier. Perhaps you think about A8 pixel clock when you say "luma carrier"? Anyway, on PAL A8 the ratio between color carrier frequency and pixel clock is a non-integer, so artifacting and that sub pixel movement stuff is not possible. It would have been possible if the PAL A8 had a system clock of 2,217 MHz which results in a pixel clock of 8,867 MHz (twice the color carrier frequency).

[atariksi]

I don't know if that can work or not.

 

Given how the players work, it might be possible. It's been a long time since I did that. I basically was a kid at the time. Spent a month, just getting the core 640x200 bitmap up and going.

 

For PAL, the color phase shifts every line anyway. Seems to me, just shifting it back by changing the display color in time with the PAL color would nullify that. I just don't know that much about PAL.

 

I do know it's an artifact of how GTIA produces color. You can see the sub pixels easily enough by just running a 4 color mode, and plotting a few pixels in one color, say red, then another one, say blue. Turn the color down on your TV, then crank the sharpness up and go look at the sub-pixels. That's actually chroma data that shows up as luma data.

 

On a PAL TV, I'm not sure they are stable. They might be interlaced because of the alternating color shift going on. On an NTSC TV, you can see the pixels, and they are stable.

 

What about those trinitron RGBs vs. the linear RGBs-- I suppose they affect your algorithm.

[atariksi]

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.

 

I just tried your software Thinkpad 770ED (NTSC) with the live video window and it worked with V=124, Offset = 0, Field = 0. On Commodore 2002 (NTSC), it works with V=124, Offset = 2, Field = 0. You should detect PAL/NTSC with register 53268 and default to V=124 (instead of 125), offset =0, and Field =0 for NTSC.

[atariksi]

40K RAM will be needed (to run the program) when I get the pic ready.

 

I could get it working on a 32K system, but I think they'd be a small minority these days anyway.

 

16K systems - not really feasible... a 160x384 bitmap takes nearly that amount for the DList + pixel data alone.

 

Weren't you hacking PolePosition recently? You could just add the interlace into the software easily. At least, it'll work with old Thinkpad laptops then; currently, the live video window does not pick up the Atari non-interlaced signal correctly.

 

Then make "i" versions of all the games-- iPacman, iPolePosition, iDonkeyKong, iMrRobot, etc. like Apple making i<fill-in a word> and trying to bias the dictionary towards the letter I.

[Rybags]

PolPos kinda got relegated to the backburner. If anything, it's weakness is in the horizontal res department.

 

Might be interesting to hack a game or two, just to see the result.

 

Re - the settings. With the latest version, all that stuff from before goes out the window.

 

With luck, VCount will be absolutely constant, so the only parameters needed will be a variable delay and duration setting (cycle-based). From there, we might be able to narrow it way down to several, or just one that works for all.

 

Will try and get that Falcon pic available soon... the heatwave that's been happening here just isn't conducive to sitting down and programming stuff.

Edited February 3, 2009 by Rybags

[potatohead]

I don't know if that can work or not.

 

Given how the players work, it might be possible. It's been a long time since I did that. I basically was a kid at the time. Spent a month, just getting the core 640x200 bitmap up and going.

 

For PAL, the color phase shifts every line anyway. Seems to me, just shifting it back by changing the display color in time with the PAL color would nullify that. I just don't know that much about PAL.

 

I do know it's an artifact of how GTIA produces color. You can see the sub pixels easily enough by just running a 4 color mode, and plotting a few pixels in one color, say red, then another one, say blue. Turn the color down on your TV, then crank the sharpness up and go look at the sub-pixels. That's actually chroma data that shows up as luma data.

 

On a PAL TV, I'm not sure they are stable. They might be interlaced because of the alternating color shift going on. On an NTSC TV, you can see the pixels, and they are stable.

 

What about those trinitron RGBs vs. the linear RGBs-- I suppose they affect your algorithm.

 

Comes down to the analog bandwidth of the TV more than anything else. Some TV's clamp the bandwidth of the visible pixels to a fairly low value, which doesn't work well at all. Every TV displays something however. Might be a blended, smoother shape, instead of a little, sharp pixel.

 

All I've got is a 48K 400 right now, and no SIO toys. Gotta fix that this year. When that happens, perhaps I'll try this on newer HD displays, which I know little about where these kinds of things are concerned.

 

I do have my Propeller micro to tinker with at the moment. On that thing, I've written an Atari style video driver. The effect works on it also, though I can just drive it faster, or interlaced, or anything else, If I want to. Anyway, it could be used to size up a few newer displays, if anyone is interested in that data.

[atariksi]

PolPos kinda got relegated to the backburner. If anything, it's weakness is in the horizontal res department.

 

Might be interesting to hack a game or two, just to see the result.

 

Re - the settings. With the latest version, all that stuff from before goes out the window.

 

With luck, VCount will be absolutely constant, so the only parameters needed will be a variable delay and duration setting (cycle-based). From there, we might be able to narrow it way down to several, or just one that works for all.

 

Will try and get that Falcon pic available soon... the heatwave that's been happening here just isn't conducive to sitting down and programming stuff.

 

Just looking for something that boots up in interlaced. One thing that does look better with interlace even if you repeat the same character data, is characters like '<' and '>' look smoother. And this does not use up memory so it would work on Atari 400 as well.

 

You need to turn off the PolePos backburner-- may help with the heatwave.

[atariksi]

I don't know if that can work or not.

 

Given how the players work, it might be possible. It's been a long time since I did that. I basically was a kid at the time. Spent a month, just getting the core 640x200 bitmap up and going.

 

For PAL, the color phase shifts every line anyway. Seems to me, just shifting it back by changing the display color in time with the PAL color would nullify that. I just don't know that much about PAL.

 

I do know it's an artifact of how GTIA produces color. You can see the sub pixels easily enough by just running a 4 color mode, and plotting a few pixels in one color, say red, then another one, say blue. Turn the color down on your TV, then crank the sharpness up and go look at the sub-pixels. That's actually chroma data that shows up as luma data.

 

On a PAL TV, I'm not sure they are stable. They might be interlaced because of the alternating color shift going on. On an NTSC TV, you can see the pixels, and they are stable.

 

What about those trinitron RGBs vs. the linear RGBs-- I suppose they affect your algorithm.

 

Comes down to the analog bandwidth of the TV more than anything else. Some TV's clamp the bandwidth of the visible pixels to a fairly low value, which doesn't work well at all. Every TV displays something however. Might be a blended, smoother shape, instead of a little, sharp pixel.

 

All I've got is a 48K 400 right now, and no SIO toys. Gotta fix that this year. When that happens, perhaps I'll try this on newer HD displays, which I know little about where these kinds of things are concerned.

 

I do have my Propeller micro to tinker with at the moment. On that thing, I've written an Atari style video driver. The effect works on it also, though I can just drive it faster, or interlaced, or anything else, If I want to. Anyway, it could be used to size up a few newer displays, if anyone is interested in that data.

 

Yeah, I would like to see what a snapshot of 640*200 software mode looks like.

[Rybags]

One of the early tests I did a "<" in 16 pixels, and it was smoother. Also did an "A". Interlace really shines when you deal with angles 45 degrees or lower.

 

It comes down to choices with text displays. Improve the look of what's already there, or open up new possibilities, like:

 

- Use VScrol trick for 4 pixel high chars, 2 character sets. End result: you can get 40x48 in the space where 40x24 normally takes.

Still in character mode. Since only 4 lines of the chset data are used, you can just use the top half of the character definition for frame 1, bottom half for frame 2. Just store the bottom half of the character set "upside down", and use character flipping to use it on the second pass.

 

- VScrol tricks again. Fullscreen 40x80 characters, 6 pixel high characters. 2 character sets required here.

 

Hey presto. We have 80 columns with no add-ons... only downside is you have to turn the monitor on it's side.

[Rybags]

Yeah, I would like to see what a snapshot of 640*200 software mode looks like.

 

If you've got the thing working for you (earlier BASIC program), you can easily modify it for other modes, whatever.

 

Just include a hires mode with the DLI bit set as the final displayed line... doesn't need to be scanline 240, can be anywhere.

 

Then just modify the main loop of the program so it only plugs in the working VCount, Index etc. values you want, and it should work fine.

[dwhyte]

I am in awe... Excellent work Rybags!!!!

[potatohead]

I'll have to fire off a thread.

 

Don't want to get in the way of what Rybags is getting done!

[supercat]

Yeah, I would like to see what a snapshot of 640*200 software mode looks like.

 

To get 640x200 one would need to have 320-dot resolution on the chroma. The Atari 8-bit machines don't. Certain hues will cause the left half of the even pixels and the right half of odd pixels to be brighter than the right half of even pixels and the left half of odd pixels, but without the ability to split pixels I'm not quite sure how that would be useful.

 

It might be possible for the Atari 2600 to create a kinda-sorta 320-dot high resolution effect when used on a black and white television set, but I'm not sure how useful that would be. A somewhat more interesting possibility would be to use color cycling to create a visible motion effect on black and white televisions. In a game like "Adventure", for example, one castle and its key could have increasing cycling hues while another had decreasing hues. On a black and white television, one would have stripes that would move rightward, while the other would have stripes that move left.

[Rybags]

I think if the pixel-shift works, it would be more of a "finer scrolling" effect than a 640 "horizontal resolution".

 

But of course, with creative use of pixel placement, it might look nearly identical to something done in actual 640 resolution.

[potatohead]

I went ahead and posted what I remember on another thread, so as to not hammer this one.

 

About the moving bars --that is exactly what is seen when color cycling, BTW.

Edited February 4, 2009 by potatohead