640 x 200 x 2 color mode discussion

[potatohead]

I looked these over more closely. They are all kind of funky. The screenies you captured look like they were used for color, not resolution. The OR I did should have shown more detail. Didn't...

 

Thanks for the captures. I appreciate it!

 

There is another subtle thing in play here too. On the capture card, it rounds to the nearest pixel, but will shift one way or the other, based on the chroma. On a real TV, the actual size of that sub-pixel varies somewhat, depending on, if it's either or odd, and the base hue value for the scan line.

 

Probably some color combinations will look different on an analog display device. Not sure if it's better or not. Also I don't think this is what is occurring in the images I ORed together though, but it could be. The capture card got the pixel shift dead on. The author must have been going for both color and detail.

Edited February 6, 2009 by potatohead

[Cybernoid]

Yeah, I noticed that too. I think I captured the screens in 640x480 mode (looks better than 720x480 mode because of the sampling). I'll capture in 640x240 to try to capture just the fields instead of having the software deinterlace them.

[atariksi]

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

 

...

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.

So it's consistently 1/2 hi-res pixel shift given certain color settings by just feeding composite into luma input on composite monitor? I suppose it's possible to do both interlaces (vertical and horizontal) and get 640*480 on NTSC. I just arbibtrarily picked colors 142 vs. 30 with foreground to 0; which ones cause the shift?

 

Yeah, you probably want to keep your A400 as well though-- some seem to sell higher than XL/XE: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewI...em=200304764273

[potatohead]

Yeah, I'm not gonna let go of the 400. It just looks very cool.

 

Picked up a 6 switcher today for $5. Needs the little power adapter socket soldered back in, but looks to be in fine shape otherwise. That's one replaced machine down! Same model too. Says, "Video Computer System" on it, has the speaker holes, and the inspector date tag inside says 1980! Perfect replacement.

 

An 800xl, or 130xe later and I'll be set!

 

I used values like the ones I posted up thread. Try 96 for one background color, 192 for the other, and a luma of 8 or so. The very darkest hues may not show up as the stripes. If so, and you want to see them, just bump them up one luma level. Plot a line, and you should get a picture a lot like the one I linked up thread also.

 

The lumas work like this:

 

oooooooooooooooo <-16 or maybe 15 positions per one single 4 color pixel, or 8 of these per single high-res pixel.

 

The chroma pixel appears in one of those sub-pixel positions, depending on the hue value.

 

oo-ooooooooooooo <-- hue 16*3

 

Once you set a hue, for the background, then the vertical bars should appear. Plot one even line and one odd line, and just work through the other background color, one hue at a time, until you see a shift similar to the one I posted up-thread.

[potatohead]

Yeah, I noticed that too. I think I captured the screens in 640x480 mode (looks better than 720x480 mode because of the sampling). I'll capture in 640x240 to try to capture just the fields instead of having the software deinterlace them.

 

That would be really cool actually. It then should be possible to 'OR' them together to get a nice approximation of what the bitmap would look like.

[atariksi]

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

 

By the way, that link points to a non-English website.

 

>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.

 

They both work well as long as luminance changes are not too big.

 

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

 

Just remembered that I wrote a font editor for PC for fixed non-scalable fonts but it only works in DOS. It would allow you to convert for Atari's use easily, but not many people have access to REAL mode DOS.

[potatohead]

Yes it is non-english. The babelfish got through the first screen or two. Seemed to me they did the whole frame deal, not every other scan, but I wasn't sure.

 

They appeared to be more into color effects. If you want, you can get 12-16 nice colors on the screen this way. It's touchy with the backgrounds though. Red / blue - red / green do well for that, when combined with artifacting. If you move your eyes though, it's kind of ugly. The effect reminds me of what DLP TV's will show when you move your eyes quickly. Gotta keep saturation down as well. I didn't like it.

 

PM graphics on the screen present some interesting options though! If I understood that page correctly, they used them to simulate color cells.

 

So that makes me think about the OR effect we saw on another thread. I believe black is one option. So then, the interlace could be limited to parts of the screen, for one. Another would be to permit different luma values, either with the interlace or not happening!

 

If it's all monochrome, there are lots of options! Could have some very nice looking bitmap, char, graphics, texture stuff going on. And of course, it's a gauntlet thrown down for the C64 guys!! (And that's what got me to thinking this through --it was on the list of Atari happy fun graphics hack things.)

 

And then there are GTIA changes as well. I've not read enough to understand what those mean, in the context of a GR.8 mode line. Probably not much.

 

In any case, the 16 shades of grey, higher resolution graphics space opens up some room to do new stuff! Just ignore color, and go for the high resolution bitmaps, overlays and GTIA stuff. Would look kind of NEXT like.

 

 

Agreed on the second point. Helps to have a high persistence screen too. Those Apple ones were great for this. The advantage there is really not having to impact the display overall. Leaves room for lots of graphics tricks. I fear the every other scan line deal would just consume too many resources, without adding a lot of value. ANTIC could be used to sort out addressing for Rybags interlace too. Not sure how important that is though, because it still would be even pixels in one 40 byte line, and odd ones in another.

 

 

As for the real mode DOS, yeah it's rare these days. There are virtual environments now. Kind of sucks for programming to the metal, as there is none, but if people are just running rather ordinary programs, they are easy.

[potatohead]

Sorry, another post! (can't always edit)

 

Wonder if emulation support for this would be too much trouble! Would open the door for a lot more people. When viewed on an ordinary CRT, the background ends up being just grey. So then, emulation could just do that, and plot the pixels as 640 resolution ones, at the other luma value.

[atariksi]

Yes it is non-english. The babelfish got through the first screen or two. Seemed to me they did the whole frame deal, not every other scan, but I wasn't sure.

...

I was trying to find out if it works consistently. I tested on an 800XL with Amiga 1084 monitor and there's no shift even when I turn down the color. Perhaps, I need to try on another computer (like Atari 400) or different CRT.

[potatohead]

Are you running PAL?

 

Are you sending your baseband composite into the luma of your monitor?

 

Have you tried a higher bandwidth monochrome monitor, with the baseband signal?

 

If you are on NTSC, it's gonna be consistent. This effect happens with every computing device that generates non-interlaced color. I've seen it on the Propeller, Color Computer I, II and III, All 8 bit Atari machines, including the VCS, Apple, etc... Not all of those machines can handle shifting them for the higher resolution though. The VCS is limited in that it only addresses a full color pixel. (160 pixels, safe area resolution) The Apple does it's color graphics this way, but doesn't have a VSYNC, otherwise it would be capable, as it has a small shift in the high bit of the high-res mode.

 

Not sure about the CoCO I, and II. The III is great! It does have the sync exposed to the CPU, lots of RAM, and actually will produce 640 resolution graphics anyway. On that bugger, it's easy to get a 256 color palette running composite video. (used to plot fractals on it and most of the colors were unique). Always wanted to see a game done that way. The trick on that one is to run the 4 color 640 pixel mode on composite. This gives 8 bits of addressable color per ordinary 160 pixel horizontal resolution. When done with the color timing fixed, that is. I've always wondered if that isn't the 256 color mode those guys often wonder about...

 

Anyway, the key is whether or not the chroma signal timing stays fixed, or varies. On the C64, it varies. That is what gives the C64 full 320 pixel color resolution. You can see the differernce by watching for dot crawl on contrasting colors, on a display running baseband video.

 

I don't know much about PAL, other than it does shift the chroma every other line.

 

If you take the basic program you wrote for me, set 710 to say 48, set the color change DLI on 710 to 192, or maybe 128, then set the foreground (709?) to 10, and your border color to 0, then the stripes can be clearly seen. Plot your single line, and vary either 710, or the DLI changed 710, through the hues to see the shift occur.

 

Should see a picture just like the one I posted up thread, where it's zoomed in large size.

 

This does not happen with s-video. The RF is marginal at best. (RF on a black and white TV will show it off though. I did try that with a little portable, and it worked!)

 

One other thing that might impact it is your video mod. I've not seen those up close. The signals that come out of an 800, 800xl (which was the machine I used way back when, as it had a good baseband composite signal), etc... should do just fine.

 

The video mods might not, depending on how they deal with color.

[atariksi]

...

>If you take the basic program you wrote for me, set 710 to say 48, set the color change DLI on 710 to 192, or maybe 128, then set the foreground (709?) to 10, and your border color to 0, then the stripes can be clearly seen. Plot your single line, and vary either 710, or the DLI changed 710, through the hues to see the shift occur.

 

>Should see a picture just like the one I posted up thread, where it's zoomed in large size.

 

>This does not happen with s-video. The RF is marginal at best. (RF on a black and white TV will show it off though. I did try that with a little portable, and it worked!)

 

Okay, so I have to use the TV out signal not the DIN cable... My monitor has no RF connection so probably need to hook up a VCR.

[potatohead]

Isn't one of the DIN signals just composite?

 

If so, you can use that one.

 

[goes to look that up]

 

Monitor Port (all but 400, NTSC 600XL, XE game system, SECAM):

3 o o 1

o o

5 o 4

2

1. Composite Luminance (Composite Video on PAL 600XL)

2. Ground

3. Audio Output

4. Composite Video

5. Composite Chroma (not on 800XL(except "800XLF"),1200XL;Ground on PAL 600XL

 

So, pin 4 is your friend. Send this one into either the luma of an s-video monitor, or into a monochrome NTSC monitor. Those will work for sure. Past that, only the better quality composite displays will show the color stripes.

Edited February 8, 2009 by potatohead

[potatohead]

http://www.longhornengineer.com/Projects/AtariAVmods

 

Seems some mods will eliminate this effect. Also suggests composite monitors do have the bandwidth to resolve it.

[atariksi]

http://www.longhornengineer.com/Projects/AtariAVmods

 

Seems some mods will eliminate this effect. Also suggests composite monitors do have the bandwidth to resolve it.

 

So Amiga 1084 monitor may not show the shift...

[atariksi]

Isn't one of the DIN signals just composite?

 

If so, you can use that one.

 

[goes to look that up]

 

Monitor Port (all but 400, NTSC 600XL, XE game system, SECAM):

3 o o 1

o o

5 o 4

2

1. Composite Luminance (Composite Video on PAL 600XL)

2. Ground

3. Audio Output

4. Composite Video

5. Composite Chroma (not on 800XL(except "800XLF"),1200XL;Ground on PAL 600XL

 

So, pin 4 is your friend. Send this one into either the luma of an s-video monitor, or into a monochrome NTSC monitor. Those will work for sure. Past that, only the better quality composite displays will show the color stripes.

 

I did hook up using pin 1 and then tried pin 4 using 800XL. May need to switch monitors. Also have Atari 800-- perhaps that does not support pin 1.

 

All the machines I tried are unmodded.

[potatohead]

Did you connect pin 4 to the yellow luma input on the back of the Amiga Monitor?

 

Those things have 640 pixel resolution --at least in RGB mode.

 

I think I read you did, but am not sure.

[flashjazzcat]

How practical/consistent is the 640x200 hires interlace? I've downloaded the Simar HiRes editor mentioned elsewhere in this thread but I haven't had a chance to hook up the real hardware yet to give it a try. There's source code bundled with the software which presumably creates a 640x200 screen. I'm interested in this because I've been doing a feasability study of writing a WYSIWYG word processor (LW 4.0) for the Atari8 in the future. Trouble is, the screen's 320 pixel horizontal resolution is going to make it really difficult to represent a bitmapped page (the printer will be driven in graphics mode) of maybe 640 or 1280 pixels across without lots of horizontal scrolling. Even using scaled down equivalent fonts for the screen display (say 1/2 or 1/4 of the size of the printer fonts), we're going to be limited as to how we can show bold, italic, etc, on the screen. Ideally a program like this needs a doubly interlaced 640x400 display. Clearly it's pushing the frontiers a bit, and coding something like this without emulator support would be near impossible.

[Rybags]

I don't even think we should call this a 640 mode.

 

In the event you achieve pixel shifting due to hue phase delay (or whatever it's called), you still have only 320 pixel resolution as it all gets moved across.

[flashjazzcat]

I don't even think we should call this a 640 mode.

 

In the event you achieve pixel shifting due to hue phase delay (or whatever it's called), you still have only 320 pixel resolution as it all gets moved across.

Thanks. Back to the drawing board, then.

[Rybags]

We're all going to have to turn our monitors on their sides...

 

Interlaced graphics lets you do 480 vertical ... best we can do horizontally is 352, or on a normal 4:3 TV more like 316.

[potatohead]

That isn't true.

 

How it works is you display all even pixels with one color setting, then on the other frame, you display all the even pixels. You do get 640 unique, addressable pixel positions.

 

"It all gets shifted over" is how it works! For each scanline and each luma, where the color sub-pixels end up gets shifted by some small amount. 1/4 pixel shift is what is needed. In the capture card screen shot above, the pixel widths are somewhat larger than what is seen with an analog display.

 

To do a bitmap, all you need is 2 320 mode pages. A simple display is one color, one page, one frame, the other color, the other page, the other frame. Can be done with a simple VBI.

 

I've tried a few displays since the last conversation on this thread. The RF, on average, doesn't get it done. It lacks the bandwidth to see it consistently. To see this with enough resolution to be useful, a composite signal is required, and a display with high bandwidth is required.

 

One good combination is an 800XL and Apple ][ type green screen. Composite 80 column displays will do it nicely.

 

Because of the composite + high resolution display requirement, I totally agree that it's not as usable as other software display options, but it does yield 640 addressable pixels.

 

Gonna have to video mod the 400 here soon, or get an XL machine...

Edited March 29, 2009 by potatohead

[atariksi]

We're all going to have to turn our monitors on their sides...

 

Interlaced graphics lets you do 480 vertical ... best we can do horizontally is 352, or on a normal 4:3 TV more like 316.

 

316? Must be a typo. Memory usage in widescreen mode is for 384 hires pixels of which 30-40 are not visible on normal TVs and only 8 not visible on my LCD monitor.

[atariksi]

That isn't true.

 

How it works is you display all even pixels with one color setting, then on the other frame, you display all the even pixels. You do get 640 unique, addressable pixel positions.

 

"It all gets shifted over" is how it works! For each scanline and each luma, where the color sub-pixels end up gets shifted by some small amount. 1/4 pixel shift is what is needed. In the capture card screen shot above, the pixel widths are somewhat larger than what is seen with an analog display.

 

To do a bitmap, all you need is 2 320 mode pages. A simple display is one color, one page, one frame, the other color, the other page, the other frame. Can be done with a simple VBI.

 

I've tried a few displays since the last conversation on this thread. The RF, on average, doesn't get it done. It lacks the bandwidth to see it consistently. To see this with enough resolution to be useful, a composite signal is required, and a display with high bandwidth is required.

 

One good combination is an 800XL and Apple ][ type green screen. Composite 80 column displays will do it nicely.

 

Because of the composite + high resolution display requirement, I totally agree that it's not as usable as other software display options, but it does yield 640 addressable pixels.

 

Gonna have to video mod the 400 here soon, or get an XL machine...

 

So can you list some combinations that work without having to find an Apple II monitor which may be extinct? The Luma signal is present on Atari 800 moinitor jack so that should be good enough for showing shift, but currently not showing in my tests.

[potatohead]

The ones up-thread, where the screen capture zoom work well.

 

An alternative is to send the composite signal into the luma of an S-video display. That's not extinct, and is the method I use on my capture card to see this kind of thing.

 

Been on the hunt for an 800 XL. That is the machine I used way back when.

 

There are two projects like this that I am chipping away on. One is ~256 colors on a CoCo 3, using artifacting on composite. I've got that machine coming soon. The other is a quick and dirty demo of this technique. Both are kind of waiting on hardware. If an XL takes too long, I might mod the 400. It's just iffy and will freeze from time to time. I don't do much with it, because of that. It will play Star Raiders all day long. Will freeze on something like Ms PacMan though.

 

Given your results from before, I'm wondering if some displays either compensate for this, or the masking on the CRT renders it difficult to see.

 

My larger SONY WEGA will display it nicely enough. Had the Propeller and modded VCS hooked up to it's S-video. Both displayed the long vertical lines clearly enough. Color cycling on the VCS, showed the shifting that occurs too. I've not tried the Propeller, but the VCS also displays the lines on the newer HDTV plasma. I found that varying the chroma level (I did the Ben Heck mod with three pots) significantly impacted this. Best results for me was a dark background luma, and a brighter foreground one.

 

Was looking at the video mod thread Longhorn Engineer has going. It may be that some machines filter this out too. His mods do not display the color pixels, and that's intended, of course. Some machines then, might vary in how well they will display this stuff.

 

Given the state of hardware, I'm going to work through the CoCo project first. That machine is going to be here this week, and it's fairly straightforward to knock up a demo showing 160xsomethingx256 colors. On that machine, the 160x96 works best, but it will do 192 and 200 vertically also.

 

On the 800 XL are both composite video and separate luma available? Are you using the luma only?

 

If so, that's the trouble as the luma doesn't exhibit the shift.

 

If composite video is available, that should work just fine, if connected to the luma only input of an S-video capable display. If they are broken out, just send both of them in there, using a Y connector or something.

 

On the ordinary GR. 0 text display that you get when the Atari boots, the right display is one where it's not one shade of grey. It's a series of vertical stripes. Poke 710, sequential luma values to see the stripes move. If all you see is a nice, smooth grey, that's not the right signal combination out of the Atari.

 

[i'll do a coupla screen captures from the Propeller to show that off with a driver that does video in a way very similar to how GTIA does it

 

The Propeller one is going to have to wait, but here is one from the Flashback II title screen. That's baseband composite running into the luma input of an S-video capable display. In this case, it's my capture card. The stripes are associated with each color displayed. If you don't see those stripes, there won't be any shift.

Edited March 30, 2009 by potatohead

[Rybags]

I should have said "336" before. My TVs tend to show about 1 character of border horizontally on a standard screen.