640 x 200 x 2 color mode discussion

[potatohead]

After seeing the excellent interlacing Rybags has going, I mused about using it in tandem with the other kind of interlace possible. That's horizontal interlace in high-res mode. Probably only works on NTSC, but I don't know that. Just don't know much about PAL. Maybe this doesn't work on PAL at all. I do know a PAL TV that receives an NTSC signal will just show the luma, most of the time. That probably would work.

 

Atariksi wondered what it would look like. There was enough to say about that, it was best on it's own thread.

 

I've got one option for producing an image right now, and that's to just build the mode on my micro, with the Atari style NTSC display timing. I've no programming interface for my 48k 400, besides the Basic cart, and no save option for that. (lost a bunch of stuff in a recent move... bastards!)

 

The other option is to describe what needs to happen and maybe get some help boiling it down to a Basic program I can just type in and test on a coupla displays. Or maybe somebody can just write it for a test and picture from the TV. Given what I see done here regularly, I don't think this is all that hard. Maybe it is though. I've not programmed on the Atari in this way in quite a while.

 

On the micro, it would be a fairly accurate simulation. Good for a picture. I think the actual GTIA video differs a bit on the actual sub-pixels generated, but not enough to matter. But it's not an Atari, so... Maybe that doesn't mean much, other than to just show what to look for. I think just connecting an Atari base band composite signal to a good, sharp display with the color turned down will make it obvious.

 

Basically, this is a graphics mode I coded when I was in High School, computing with friends. Was goofing around with one friend, who had an Apple //e doing double-high res. We happened to have one of the older monochrome Apple monitors around and hooked the Atari up to it. Basically, the blue on white text display appeared as a bunch of very thin vertical lines! Some discussion later and we became aware that these lines were actually the chroma data appearing as pixels, due to the higher bandwidth of the display.

 

This effect is viewable on any decent black and white television, or most color TV's with the color turned down, or on an s-video capable display, if you send the composite baseband signal into the luma input of the S-video display. You might need to bump the sharpness, depending. On older TV's it's usually viewable with a slight mis-tune as well.

 

On NTSC, these sub-pixels are consistent. They do not vary, and they are indirectly addressable through the color registers. Each hue, shifts these sub-pixels 1/16th. Another way to visualize this is a 4 color pixel ends up being 16 little pixels, each representing one of the hues on the Atari.

 

This can be viewed by either color cycling, or by plotting a few 4 color pixels vertically aligned, then cycling or selecting hues to see where the sub-pixels shift to.

 

In high-res mode (GR , there are two ways it works. If the base color is black, the pixels will be 1/2 the size of a 4 color pixel. This is what generates artifacting on NTSC displays. One color for odd, one for even. (a coupla other colors are possible with patterns) It is not possible, that I know of, to generate the higher resolution using black as the background color because of this. I could be wrong, as I've seen a whole lot of tricks done since then.

 

If a base color is chosen, the pixels will be different sizes! I think I used red and blue way back then. Could have been red and green. The key point being the sub-pixels are not as fully sized as they are when black is the base color. This is what opens the door to getting higher than 320 resolution bitmaps.

 

There are two options. I was successful with the easier one back then, and moved on before working all the way through the harder one. (was CPU expensive with what I knew then --maybe still is) Got a job, and ended up not computing so much on the Atari for a long time.

 

Option 1 is to just show one whole frame with it's base color, call it all the even pixels. Then show the other frame with it's base color, call it the odd pixels. Repeat.

 

The best display was with the base color being the lowest luma value for the background, and a higher luma value for the foreground. There isn't a lot of flicker, because the two luma values are the same, and the pixels mesh together to form a dark grey background. Works fine. The very brightest luma values had more flicker than moderate ones. This varies by display type, just like everything else does.

 

On frame 1, you set a graphics 8 page and the colors. Then on frame 2, just set another page, and the other color.

 

That's it. If the colors are chosen correctly, the sub-pixels will interleave, yielding 640 pixels. Addressing is a bit funky as every other pixel is spread across every other bit, between two graphics pages. It's kind of like the Apple double high res mode, in this.

 

The harder method is to alternate the colors and the graphics pages every line.. That's a DLI and two display lists at a minimum. Back then I did a DLI every scan, and it didn't work out so well. From what I've read here, the color changes are possible without doing this. That's beyond me at the moment, without spending some time hacking on the 400. If so, perhaps it's easier to do this one.

 

It all works on the easy path though. There is nothing to be gained but a little bit better overall display quality with the harder method. On vertical lines, where a lot of flicker can be seen, the harder method does not flicker all that much. That's the big gain, where everything else works mostly the same.

 

One advantage of the every other scan line bit is the flicker is less. NTSC broadcasts do this anyway to good effect. Depending on your display and amount of contrast the flicker ranges from being not noticeable to noticeable, but viewable. The old Apple monochrome monitors were just great because they had a high persistence time. Almost no flicker at all, with either method.

 

If showing what this would look like with the Propeller would be useful data, I'll do one and take a photo, or capture card image.

 

Because the color is being used to address sub-pixels, this is a monochrome display technique. You'll get a headache working with it in color --even with the every scan line method. That I do remember.

 

If not, then I'll take a shot at this some time later in the year when I've got an interface for either the 400, or a better 8bitter that I want to pick up to replace my 800 XL that was lost.

 

On that note, are the SIO to USB devices available regularly? Or is there something similar one can use that is available?

[Rybags]

You can build your own APE if your computer has RS-232. My second one took maybe 2.5 hours, and I'm no soldering expert.

 

Just to clarify the mode:

 

Do you have to feed composite into a luma of S-Video port? The only device I have that takes S-Video is my HDD Recorder, and I already established the other day that it doesn't like our old computers with their non-standard signals.

 

If I was to generate a Gr. 0 display with DLIs and have different colours every line, should I be able to observe the shifting if e.g. I put a vertical line of inverse spaces or the vertical bar character?

[potatohead]

Cool on the APE. Got a link to the goods? And will a USB -> RS232 do it, or does it have to be the real deal. I'm on a laptop at the moment. Could get a PCMCIA card maybe... I've picked up some proto boards for Propeller projects. I didn't know an APE was that easy.

 

It's not necessary to use the luma on S-video. Works a lot better though. On your average TV, just turn the color way down, or ideally, off, and crank the sharpness. If you've got a tuner that's analog, or that has the fine-tune option, you can tweak that too.

 

I think that would work. Better if you have a single pixel character defined. Actually, it would be good to do one even pixel, and one odd pixel, with a few unset pixels between them.

 

All I did then was put a color change somewhere on a gr 8 page, with a DLI, then plot pixels to sort things out. Lay out the even and odd pixels, as if they are on the same line, then go and twiddle with the colors until they look like they would mesh, if they were on the same line. Those then are the colors used on each frame.

 

Could happen easily enough on a GR 0 screen too.

 

Not a bad idea to have a lens, depending on your TV size and eyeballs!

Edited February 4, 2009 by potatohead

[Rybags]

Got a cap-card with zoom mode and tweakable settings, so I might give it a try later.

 

Re the APE interface: Seems there's been mixed results here for people using USB-> legacy RS-232 convertors.

Worth a try I guess if you already have one.

 

Building one is pretty easy. I did mine based on the design here http://www.fonck.nl/atari/

 

The 1489 IC should be at practically any electronics shop. I built my second one into my 130XE... just meant drilling holes for the RS-232 port to stick out.

 

I did the interface on a seperate board (actually an old PC mouse board which I just modified a bit). Has a nice header on it so I can still get the motherboard out easily.

I soldered the connections direct to the SIO joins on the back of the motherboard - hint: might be an idea to use thinner wire than I did, it made it a really tight job to get the computer back together.

[Rybags]

 

I don't know if that's what you're after.

 

Background colours with luma=0, foreground at default. I took the photo at low res to keep size down... source is only a small TV too, running with RF input.

 

I zoomed with S-Video output going to my capture card... nothing seems out of the ordinary, lines perfectly straight.

[carmel_andrews]

isn't the idea behind this hi rez mode the premise behind ClausB's graphics extension catridge (only diff. is clausb cart jobbie does more colours in the same hirez mode....from what i can care to remember)

 

Has claus proof tested the cart yet....what paint/art programs does it work with

[Rybags]

No.

 

IIRC, ClausB's idea is to augment graphical capability by having a secondary luma source that can be changed at a much greater rate to produce hires graphics.

[potatohead]

The RF doesn't quite have the bandwidth.

 

Could you do it again, with the color turned completely off, and the foreground luma cut in half?

 

Any chance at getting a GR 0 character with the following definition?

 

0*0*0*0*

0000000*

0000000*

0000000*

0000000*

0000000*

0000000*

*0*0*0**

 

 

I zoomed in on the RF image. The shift is there. Compare the straight line to the one on the screen.

 

If you don't want to tinker with this --thanks for throwing up the screen capture you did.

[potatohead]

The APE doesn't look too hard. And he's got an internal hard disk!!

 

Well, that's cool. I think I'll build the APE with a spare SIO cable, that way I'm not locked into the machine that got the mod. Somehow I still have two of those. When I get an XE or XL machine, the internal hard disk looks like a great project.

 

I'm currently working on a 6502 emulation for the Prop. It's not gonna be as fast as an 8 bit 6502 is, but it might just be as fast as the VCS is. Would be nice to run some code for test cases, with Mac 65. Was kind of holding out for lack of an interface. Gonna have to build this now. Thanks!

 

BTW: How big is your program? Is it type-able in a few minutes or so? Are you willing to send it to me? If it's not too big, I think I would just type it in and do a few things on some different displays here, and the capture card.

Edited February 4, 2009 by potatohead

[atariksi]

The APE doesn't look too hard. And he's got an internal hard disk!!

 

Well, that's cool. I think I'll build the APE with a spare SIO cable, that way I'm not locked into the machine that got the mod. Somehow I still have two of those. When I get an XE or XL machine, the internal hard disk looks like a great project.

 

I'm currently working on a 6502 emulation for the Prop. It's not gonna be as fast as an 8 bit 6502 is, but it might just be as fast as the VCS is. Would be nice to run some code for test cases, with Mac 65. Was kind of holding out for lack of an interface. Gonna have to build this now. Thanks!

 

BTW: How big is your program? Is it type-able in a few minutes or so? Are you willing to send it to me? If it's not too big, I think I would just type it in and do a few things on some different displays here, and the capture card.

 

I can mail you a parallel->SIO cable if your machine has a parallel port. You can upload the BASIC program then using "ENTER C:" after typing in on PC.

 

So the shift of the pixels is visible once you remove the chroma signal. Which color values (0..255) did you use for the approximate 1/2 pixel shift?

[potatohead]

I've not yet done anything on the Atari just yet.

 

Rybags was kind enough to just run a quickie test, with a vertical bar, and colors in GR 0. Examination of his photo reveals the shift is there. It's hard to see with both the color on, and the noisy RF.

 

I did a zoom, and drew a reference line to compare the pixel positions to, just to highlight the shift occurring over the series of color changes. The TV used in the photo appears to have enough sharpness to be useful, but the chroma being turned on and RF are getting in the way, making things difficult to see.

 

Thought maybe if the basic program Rybags knocked up wasn't too bad, I would just type it in and run a few tests with my capture card, and TV's. I've a newer one, and a very nice CRT to use. The capture card has very high bandwidth. Will be easy to see there.

 

The vertical bar is two pixels wide, in the image he posted up. If you look at the zoomed in image I posted, the color sub-pixels can be seen as vertical bars. What we can't see yet, is the impact of those on single pixels, as none are present in the screen shot.

 

Another thing we can see is the shifting from the different hues. That's the reference white line, and the distance to the brighter pixels increasing by almost a full 4 color pixel distance.

 

I just realized this image might have the Rybags interlace turned on also. That would explain the top of the cursor having the rough pixels present like it does. That could just be the TV too. Don't know.

 

-->Anyone mind knocking out a BASIC program that does a mid-screen color change in GR 8? Something that could be typed in without too much trouble? All that is needed is to be able to control that secondary color with a poke.

 

Lines can be drawn across the color boundary, colors adjusted until they would mesh. That would put this to rest.

 

Thanks a bunch for the offer on the cable. I've no parallel port

 

With a bit of help on a tester program though, I think the mode could be shown, and either it would be viable or not, depending on what various displays do. From there, I'll build an APE at some point in the near future and do more.

[Rybags]

No interlace there. I'll give it a go later with that character definition you've supplied.

 

Right about the RF - it's not so great, but tolerable because it's a small TV... shows up much worse when zoomed from the picture.

[potatohead]

If you don't mind sending me the basic program, if you have one, that would be great too. I'll just type the thing in.

 

What I really need is just a GR 8 screen, with a single color change somewhere on the screen. That's enough to prove it all out, and post back some pictures. If there is a dead simple bit of code I can enter into a basic program, I'll do that.

 

Thanks for another run. If you don't mind, just stack the characters up, like you did with the vertical bar, and turn the color almost completely down, or all the way down. Whatever makes sense!

 

Figure I can just enter in the program and leave the 400 on for a while. I've a few displays to try, and can post up some pictures as well.

[atariksi]

If you don't mind sending me the basic program, if you have one, that would be great too. I'll just type the thing in.

 

What I really need is just a GR 8 screen, with a single color change somewhere on the screen. That's enough to prove it all out, and post back some pictures. If there is a dead simple bit of code I can enter into a basic program, I'll do that.

 

Thanks for another run. If you don't mind, just stack the characters up, like you did with the vertical bar, and turn the color almost completely down, or all the way down. Whatever makes sense!

 

Figure I can just enter in the program and leave the 400 on for a while. I've a few displays to try, and can post up some pictures as well.

 

Here's one you can use and easily modify. Increase number of NOPs (234s) in DATA statement to move point of color change horizontally and inc/dec value in line 50 to change scanline of interrupt (vertical position).

 

10 GRAPHICS 8

20 POKE 709,0:POKE 712,142: REM Set colors for foreground and background

30 COLOR 1:PLOT 159,0:DRAWTO 159,159

40 DL = PEEK(560)+PEEK(561)*256:T=1520

50 POKE DL+150,15+128: REM +150 can be modified to change scanline of DLI

60 READ A:IF A<>-1 THEN POKE T,A:T=T+1:GOTO 60

80 POKE 512,240:POKE 513,5:POKE 54286,192

100 REM PHA; LDA #30; STA WSYNC; NOP; NOP; STA 53274;PLA;RTI

180 DATA 72,169,30,141,10,212,234,234,141,26,208,104,64,-1

[potatohead]

Nice! I appreciate it.

 

That was perfect for a start. I was able to set the colors easily enough. The comments were perfect. Easy to understand what was what. Typed it in, ran it. Made a coupla edits to set the necessary color registers (needed 710), and basically added a plot and drawto or two, and ran it over and over to see results.

 

How come I can't run the program, then plot in interactive mode? I distinctly remember being able to do that. Could only do it, if I didn't run a program first. Is that the revision of BASIC I have, or some other minor league thing I've forgotten?

 

I'll try and post up pictures tomorrow. Daughter has the camera.

 

Bottom line for now is the RF really, really sucks! On the HDTV, it was a mess. I think those things are just noisy enough to be a problem. I didn't see anything other than BIG smudged pixels. Not worth another look until I get a baseband composite signal.

 

Tried it on my larger screen CRT SONY WEGA TV and got some results. With the two background colors set to 48, and 192 (or something similar), it was possible to just barely see the stripes. Actually helped turning the color on just a bit. And that TV only would resolve red / blue well enough to see. Perhaps Rybags has a better TV!! (Or my 400 is just really old, or lousy in some way)

 

I didn't get to try the capture card as the basic locked up after about 25 runs. Must be the bad Rev. Only took 10 minutes to type in, so no biggie. It's bed time now, so that's that.

 

I could see enough to sort it out some.

 

Let's call a gr 8 pixel a pixel. Two of those together is a full color clock on the Atari.

 

If the colors are set for 1/2 a pixel shift, then they mesh when interlaced. The values I chose got me at least that half a pixel shift. Didn't remember that until futzing around with it. This was enough to sort that out in my mind.

 

The big problem with the RF, is two pixels together, or too bright, just bloom into a mess. The other big problem is shadows on luma changes. Had to keep things very low contrast to see anything. Some of that is the TV, a lot of it is the RF, as I can see chroma details well, with a base band source. Do it with the Propeller all the time.

 

Maybe the capture card does a better job. I suspect I'll have to get baseband out of the thing to post up good pictures.

 

I think I can get a rough image out of the SONY though. I'll give that a go, to show the 1/2 gr 8 pixel shift. To avoid blooming, probably I'll just have to plot one odd line, one even line.

 

oo <-- So that's a GR 8 pixel.  
oooo <- That's two of them to form a GR 15 pixel.  (160 normal DMA resolution 4 color pixel)

| | | |
.| | | | <---That's the background luma, seen as the stripes offset at the color change point, if your computer and display are not RF.  This can be seen (barely) with the RF.  The shift I've shown is actually visible in any 4 color mode.  That's Supercat's moving stripes idea.  (ignore the dot, It was necessary to offset the pipe symbol some)

0| 0|
| 0| 0  <---That's what can happen, with the color values set to offset 1/2 a graphics 8 pixel.  The actual brighter pixel size varies with it being even or odd, and the luma chosen for the background also.  There would be some overlap between the two center pixels, in a group of 4 pixels.  

This was a smudged mess, in that the TV running RF really can't just resolve every other pixel.  Ends up being smudged together.  About all I could see was similar to the picture Rybags posted.  The start and end of the smudge was offset at the color change boundary.

Edited February 5, 2009 by potatohead

[Kaz atarionline.pl]

When you are talking about 640x200 hi-res it could be good to mention Samar Hi-Res Interlace with Map of Colours (SHIMC format) made by Samar group:

 

 

I remember that Eru started working on his own vision of interlaced hi-res:

[atariksi]

Nice! I appreciate it.

 

That was perfect for a start. I was able to set the colors easily enough. The comments were perfect. Easy to understand what was what. Typed it in, ran it. Made a coupla edits to set the necessary color registers (needed 710), and basically added a plot and drawto or two, and ran it over and over to see results.

 

How come I can't run the program, then plot in interactive mode? I distinctly remember being able to do that. Could only do it, if I didn't run a program first. Is that the revision of BASIC I have, or some other minor league thing I've forgotten?

...

 

Enter STOP at line 90 or afterwards. Then you can use DRAWTO, PLOT, etc. in immediate mode.

 

Yeah, if you want to change PF2 (710 or 53274) then it's:

 

10 GRAPHICS 8

20 POKE 709,0:POKE 710,142: REM Set colors for foreground and background

30 COLOR 1:PLOT 159,0:DRAWTO 159,159

40 DL = PEEK(560)+PEEK(561)*256:T=1520

50 POKE DL+150,15+128: REM +150 can be modified to change scanline of DLI

60 READ A:IF A<>-1 THEN POKE T,A:T=T+1:GOTO 60

80 POKE 512,240:POKE 513,5:POKE 54286,192

90 STOP

100 REM PHA; LDA #30; STA WSYNC; NOP; NOP; STA 53274;PLA;RTI

180 DATA 72,169,30,141,10,212,234,234,141,24,208,104,64,-1

[atariksi]

Nice! I appreciate it.

 

That was perfect for a start. I was able to set the colors easily enough. The comments were perfect. Easy to understand what was what. Typed it in, ran it. Made a coupla edits to set the necessary color registers (needed 710), and basically added a plot and drawto or two, and ran it over and over to see results.

 

How come I can't run the program, then plot in interactive mode? I distinctly remember being able to do that. Could only do it, if I didn't run a program first. Is that the revision of BASIC I have, or some other minor league thing I've forgotten?

...

 

Enter STOP at line 90 or afterwards. Then you can use DRAWTO, PLOT, etc. in immediate mode.

 

Yeah, if you want to change PF2 (710 or 53274) then it's:

 

10 GRAPHICS 8

20 POKE 709,0:POKE 710,142: REM Set colors for foreground and background

30 COLOR 1:PLOT 159,0:DRAWTO 159,159

40 DL = PEEK(560)+PEEK(561)*256:T=1520

50 POKE DL+150,15+128: REM +150 can be modified to change scanline of DLI

60 READ A:IF A<>-1 THEN POKE T,A:T=T+1:GOTO 60

80 POKE 512,240:POKE 513,5:POKE 54286,192

90 STOP

100 REM PHA; LDA #30; STA WSYNC; NOP; NOP; STA 53274;PLA;RTI

180 DATA 72,169,30,141,10,212,234,234,141,24,208,104,64,-1

 

The comments should be 53272 and STA 53272 (24,208 in DATA statements).

[potatohead]

Thanks Atariksi, for the quick proggy. I made the same edits you did. The comments made it very easy to sort out. I had some fun poking around on my old 400 last night. Fun! I'm gonna build up an APE, or seek out SIO to USB. Need an XL / XE machine too. There are just way too many good things I don't want to run in emulation. That will happen this year. (we've had it tough for a while --the health situation in the states isn't pretty, let's just say that.)

 

Kaz, that's it!!

 

This page cites '96 as the time some documentation was written. http://madteam.atari8.info/shimc.php

 

Heh. A good friend Rich and I did this in early '86! At the time, I was doing two things. One was to get 16 colors up on a bitmap, and that was totally doable running the interlace. The other was just to best the Apple with a 640 pixel screen. Was one of those demo coding sessions where you do the "oh yeah? Well my computer can..." deal. Lots of fun!

 

No more hosing around here though. My point was to illustrate it was indeed possible. Well, these guys did the exact same thing, and added color mapping too. nice!

 

So I'm not nuts. It's possible, and there is even an editor. Sweet!

 

I think this ends this thread for now. Thanks Kaz! Much appreciated. I was about to chug through a bunch of work to demonstrate this possibility. Was inspired by the C64 -vs- Atari thread actually. I thought perhaps it was forgotten, or never explored as it was a niche thing, not good for all displays. (RF, in particular, unless you want the colors and there are better tricks for colors)

 

As I am unable to run the tool, and an emulator probably wouldn't do this justice, I've a coupla questions:

 

1. Do they interlace just every frame, or is it full on every other line, every other frame. I had trouble with the every other scan line deal.

 

2. Were there editors for Gr.0 Text mode? Would be possible to get very nice characters.

 

Does somebody have a nice S-video source to take a snapshot of the resulting bitmap display? Connect composite baseband to s-video luma, and snap a picture?

 

Well, now Rybags can finish up his deal. Technically then, 640x384 would be possible. On a monochrome display, it would look pretty sweet. Just have to get one of the high persistence ones, similar to the Apple monochrome monitors.

Edited February 5, 2009 by potatohead

[Cybernoid]

Interesting idea. Most displays these days have a Y/C Separator circuit (http://www.wipo.int/pctdb/en/wo.jsp?IA=WO2000013422&DISPLAY=DESC). This is to minimize the luma being mistaken for chroma and vice versa.

 

However, if you Display has S-video in, I do not think that any Y/C Separator is used. The display manufacturer assumes that it is separated already. So, if you feed the composite signal to the Y you can affect the luma by the chroma interference.

 

Anyway, here are some pics:

 

NTSC composite to composite.

 

NTSC composite to S-video

Zoom in:

 

Since the chroma changes phase by 180deg every line (does it just change 180deg every field? have to investigate that...), you get a nice checker board or hash pattern on screen because of the chroma. I think this may be the affect that potatahead is refering to... You can take advantage of this on a per-line basis and have increased resolution...

[Cybernoid]

Potatohead, I have a nice capture card that allows connecting composite to S-video... Y and composite are actually the same input with some software to change the chip settings... let me know if you want me to make some screen captures...

[potatohead]

Are you running PAL?

 

If so, that's the checkerboard. PAL alternates the color phase every line. NTSC output should be vertical stripes that stay constant every frame. It's up to the programmer then to alternate them. Achieving this same effect on PAL probably just means syncing the display color changes to what the PAL display is doing ---or just sending most PAL displays the NTSC composite signal. The chroma will be ignored, leaving a nice monochrome display, not unlike that seen with the s-video trick.

 

BTW: You can see the same checkerboard on any NTSC commercial broadcast, DVD player, etc... Color is normally interlaced, every other line. This might be what you were referring to also.

 

Yeah, don't those capture cards just rock? I love mine. Makes TV signals worth using at pretty high resolutions. I just don't have anything but RF from the Atari right now.

 

If you don't mind, I would be very interested in seeing two sequential frames from the editor tool linked up thread, and displaying any one of the bitmaps Kaz posted.

 

Maybe a short MPEG, would be good too. Just a few frames.

 

I think it would be useful to people to see a picture, rendered at the full resolution a capture card will deliver. The screenies Kaz posted are only half of what the bitmap would really look like. Couldn't find any others online.

 

The page that describes the tool was hard for me to understand. I didn't know if they were running PAL, or NTSC.

 

That might impact you being able to snap a picture!

[potatohead]

I zoomed in on the capture card image you posted. Inverted and highlighted the text and line transition.

 

 

The 1/2 GR 8 pixel shift can be easily seen. Also, in the text, some of the artifacts that happen can be seen also. When this is viewed over two alternating frames, or with every other scan line alternating, the artifacts largely go away, leaving either black on a light grey or white background, or the reverse, with white or grey on a very dark grey, but not quite black background.

 

On a NTSC display, what I just zoomed in is static. Seen every frame.

Edited February 5, 2009 by potatohead

[Cybernoid]

shimc_comp.zip

 

I am using NTSC.

[potatohead]

Thanks!

 

Here's a combined one, with the two monochrome frames "or"ed together, and saved as a 16 color bitmap.

 

combined_atari_high_res.bmp

Edited February 5, 2009 by potatohead