New true color mode!?

[Urchlay]

I don't think such schemes look so good. You have to display the Chroma at luminence 0 or 2.

Since the luma would be a seperate frame, the PAL mixing doesn't occur. I think it would be a flicker-fest and not look so good.

 

The PAL mixing doesn't occur for me anyway, I've only got NTSC Ataris and monitors. The flicker would be less annoying (30Hz instead of 25Hz), but I'm the type of person who can see a fluorescent tube flickering, when it's used for room lighting...

 

One idea might be to use the PMGs in CIN mode (Gr.11, 15 interlaced).

 

Maybe I've misunderstood what CIN mode is... does it do alternate GR.11/15 scanlines on the same frame, or does it alternate frames of GR.15 and GR.11?

 

In combination with Gr. 15 and colour blending (GPRIOR = $00), it would allow some extra luminences. Problem is you have to stretch the PMGs to 4x resolution to cover the entire screen.

 

Yeah, I've done some thinking about this, too... haven't thought of anything I like well enough to try to code it yet.

[Rybags]

My understanding is that the CIN mode just mixes Gr.11 and Gr.15 - so 64 perceived colours there.

 

Also, APAC is mixed 11/9, for 256 colours - not 4096.

 

Thinking this over again, I reckon the 6-screen mixed mode 9/10 method I described earlier might work nicely.

Sleepytime now, so I guess I'll have to give it a go tomorrow afternoon.

[MEtalGuy66]

...

APAC does 80x96x4096color by alternating mode lines of gr.9 and gr.11..

...

 

16 (gr.9) x 16 (gr.10) = 4096 ????

 

CU

Irgendwer

 

Typo... I meant 256

 

You may have also seen my post in the other thread "Photo quality GTIA modes"

 

This is what the same RGB "colorview" mode looks like using Gr.8 for 2x2x2=8 colors. I Used some really crazy code to convert the data of the picture which Id really have to dig for, but its amazing how all the combinations of artifacting on all three R,G,B screens came out to so closely resemble the color combinations you get when you just convert the same picture directy to Gr.15 COLRVIEW mode. heh. believe it or not it just "happened" that way by total accident. Blew my mind..

 

Edited April 28, 2008 by MEtalGuy66

[Irgendwer]

...

...

It seems you have found a better process to translate the vivid colors from the original sources. Great!

...

 

Seems so. When processing the quite common image of the clown I get the following image.

(Maybe the very strong 'blue' of 'your' image is caused by NTSC or your test-palette ???)

 

CU

Irgendwer

Clown.g2f.zip

Edited April 28, 2008 by Irgendwer

[Oswald]

wow, I'd love to try a plasma in this rgb mode =) how about doing it in 160x200 mode ? 4x4x4=64 colors. bump mapping with 64 colors and 160x66 anyone? add interalce and you have 320x66x64 how much cpu time is needed to change the hue on each line?

[+CharlieChaplin]

12 years ago I've seen a program which could display this mode with interlace, so that one frame was RGBRGB..., next one GBRGBR... and next one BRGBRG... This program wasn't new at that time (I think it was made in late 80's). It could optionally use GR.15 instead of GR.9 for increased resolution at the cost of lower color depth. It generally looked much worse than APAC because of more flickering and less saturation (even on a TV).

 

Unfortunately I can't remember the name of this program.

 

It was called COLRVIEW.. ANd there was an assembler version of the program, that came on a disk along with a converter program. This disk pre-dated the one above and used 3 separate files for each picture. If noone else has it, Ill dig it up when I get home and upload it.

 

And it had more of a "swimming" effect than a flickering effect. And it did a full 80x192x4096color or 160x192x64color.. APAC does 80x96x256color by alternating mode lines of gr.9 and gr.11..

 

 

Hey Irgendwer !!

you did a false quote on Metalguy !! Above you can read what he wrote exactly...

RGB can be created from GIF (87a) with Apacview by Jeff Potter and Jview by Jeff Potter. Apacview will create three separate R,G, B pictures (3x62 sectors) in Gr. 9 or Gr. 15. Jview will create a) three separate R,G,B pictures in Gr. 8, Gr.9 or Gr.15 or b) one RLE compressed RGB picture in Gr. 8, or Gr.9 or gr.15; as one can guess, Apacview was the earlier program by Jeff Poter, next Clay Halliwell improved it by coding a program in Atari basic called "Colorview Squash", this program compressed the three separate R,G,B pictures into one using RLE. He also wrote a viewer program for these compressed pictures, called "Colorsquash View" (or CSVIEW.BAS). Jeff got both programs and thus created a sort of update of Apacview, named Jview which could also create these compressed RGB pictures. Furthermore Jview allows dithering of the pictures with different dither patterns (2x2, 2x4 or 4x2 and 4x4 patterns)...

 

Here are the resolutions of the three RGB modes:

- Gr.8: 320x192 with 2x2x2 "colors" (since artefacting does not work on PAL Ataris, you mostly end up with 4-8 greyscales)

- Gr.9: 80x192 with 16x16x16 colors (alas, as we all know, on PAL Ataris two brightnesses are almost the same, thus you never get nowhere near 4096 colors; most of my Gr.9 RGB pict. have only 4-5 colors with 16 brightnesses each...)

-Gr.15: 160x192 with 4x4x4 colors (this works very good on PAL, it is easy to get 16, 32 or even up to 64 colors)

As mentioned before, the RGB pictures do not only flicker, they also have quite some swimming and eat up some memory (24kbytes), thus they are usefull only as intros, title-pictures or slideshows or simple programs where CPU speed and memory does not matter very much, afaik there is a tetris game available in Gr. 15 RGB mode (Wall-Tetris)...

 

There is even a RGB painting program available and the polish program "the Projector" (and a few others) are also able to display these pictures. So, most of my RGB diskettes are only slideshows (and of course you know, RLE compression can save quite some space, but when the pictures are dithered, RLE does not save much space)... -Andreas Koch.

[MaPa]

-Gr.15: 160x192 with 4x4x4 colors (this works very good on PAL, it is easy to get 16, 32 or even up to 64 colors)

As mentioned before, the RGB pictures do not only flicker, they also have quite some swimming and eat up some memory (24kbytes), thus they are usefull only as intros, title-pictures or slideshows or simple programs where CPU speed and memory does not matter very much, afaik there is a tetris game available in Gr. 15 RGB mode (Wall-Tetris)...

Probably this one? http://atari.fandal.cz/detail.php?files_id=3273 but this is in antic mode 4. (just examined DLIST)

Edited April 28, 2008 by MaPa

[MEtalGuy66]

Hey Irgendwer !!

you did a false quote on Metalguy !! Above you can read what he wrote exactly...

 

No he didnt. I went back and corrected my post. You can do that in this forum.

 

Here are the resolutions of the three RGB modes:

- Gr.8: 320x192 with 2x2x2 "colors" (since artefacting does not work on PAL Ataris, you mostly end up with 4-8 greyscales)

No. Without artifacting you get 8 colors. With artifacting combinations from all three screens (R,G, and B) you get somewhere in the neighborhood of 40 percieved colors. Or at least thats how many I was able to come up with..

 

 

As mentioned before, the RGB pictures do not only flicker, they also have quite some swimming and eat up some memory (24kbytes), thus they are usefull only as intros, title-pictures or slideshows or simple programs where CPU speed and memory does not matter very much, afaik there is a tetris game available in Gr. 15 RGB mode (Wall-Tetris)...

 

Actually, If you utilize antic extended video mode, you can free up 16k of that by making ANTIC look at BASE-RAM for all of the three 8192byte bitplanes, as well as the Display lists. Then make the CPU execute its code out of an extended 16k bank (or even jump from bank to bank) simultaneously. This one excellent example of why the 130xe is a kewl assed machine, and anyone who reassigns bit 5 to further upgrade the memory is crazy..

 

 

Thanks for the copy of the RGBsquash disk. I found it extremely well done for a BASIC program. I already have the orginal COLRVIEW/APACVIEW disk by Mr. Potter.

 

If there is any good paint software or other converter programs out there for RGB interlacing modes, Id love to have them.

 

Thanks...

Edited April 29, 2008 by MEtalGuy66

[Rybags]

SUNSET.zip

 

Here's an initial try of simply alternating entire screenfulls of R, G, B component.

 

It looks crap - I even adjusted the levels in Photoshop to even them out a bit, but it still flickers very badly.

 

Maybe this technique is only suited to pictures that have fairly even levels of each component?

 

Maybe this pic might look a bit better if I had the interleaved R,G,B per scanline as described earlier?

 

Sunset1.bmp

 

ed: There's a copy of the original image (after I resized it).

 

To get the R,G,B components, I just created 3 copies in PhotoShop, then eliminated the other components in each image.

Edited April 29, 2008 by Rybags

[Rybags]

SUNSET2.zip

 

Well, here's the interleaved version, single screen. Just a DLI changing to R,G,B each scanline, so "effective" resolution 80x64.

 

Looks too monochromatic, probably due to me giving extra bias towards red and blue when trying to even things out for the full-screen version.

 

[Rybags]

SUNSET3.zip

 

OK. This time, 3 screens with interlacing of the R,G,B.

 

ie, first screen is vertically RGBRGB, second GBRGBR, third BRGBRG etc.

 

Still looks rather monochromatic. Rippling effect evident but not near as bad as I'd have thought.

 

Next I think I'll try it with unadjusted RGB components.

 

 

(capture from 130XE)

 

(emulator snapshot)

Edited April 29, 2008 by Rybags

[Allas]

SUNSET3.zip

 

OK. This time, 3 screens with interlacing of the R,G,B.

 

ie, first screen is vertically RGBRGB, second GBRGBR, third BRGBRG etc.

 

Still looks rather monochromatic. Rippling effect evident but not near as bad as I'd have thought.

 

Next I think I'll try it with unadjusted RGB components.

 

 

(capture from 130XE)

 

(emulator snapshot)

 

 

Maybe you need to increase the tint with the photoshop previously before starting to work.

[Rybags]

 

SIMP1.zip

 

Another one. Once again, the blue component is rather weak.

 

With this one, you can hold a console key down to stop the screen cycling.

[Rybags]

 

SIMP5.zip - SIMP5.XEX inside Zip.

 

 

This time with interlaced Gr. 9 and Gr. 10.

Second frame interlaced the other way. Full "perceived" 160x192 resolution.

 

Looking better, although the levels need some adjustment.

 

You can hold Start on that pic file to hold the pic on the first screen.

Edited April 29, 2008 by Rybags

[Allas]

Rybags, could you post here the original image?

 

Nice try specially the second image. But I guess this technique works better with photographic style.

[Rybags]

I got the original image from http://www.dan-dare.org/Dan%20Simpsons/The...llpaper1024.jpg

 

Reduced in Photoshop to 160x200, resulting in:

 

SimpW.bmp

 

Of course, the aspect ratio is out if you view that on the PC, since 160 mode pixels on Atari are rectangular.

 

To create the actual picture in RGBi on Atari:

 

Create 3 copies of the BMP. Then, on each image adjust the R,G,B levels:

- for the target component, just leave it alone.

- for the other two components, I found that limiting the output levels from 0 to 32 instead of just reducing them to 0 helps reduce flicker somewhat.

But, the flicker reduction will come at the price of the picture appearing a little whitewashed.

 

Set the Image mode to grayscale.

 

Save as BMP, flip row order (BMPs are normally stored "upside down").

 

Open the BMPs in a quick/dirty program I wrote in the emulator, and construct the needed screen data.

[MEtalGuy66]

Ok, I did this one using the method you described in photoshop, and then loaded the three greyscale images into APACVIEW 2.4 using the GR.9 greyscale mode, and saved them as .R,.G, and .B files.

 

Heres what it looks like being displayed by COLRVIEW:

 

 

Seems to have better color levels than if you just save the image as a 256color gif and then let APACVIEW "split it" into the three .R,.G, and .B images...

 

Heres the latest versions of COLRVIEW and APACVIEW by Jeff Potter:

 

RGBPROGS.zip

Edited April 30, 2008 by MEtalGuy66

[Rybags]

Do you have an .XEX of that one?

 

I think this mode suffers in that any picture with a weak component will get the blank line/flickering look.

If you compensate by giving some bias towards the weak component, then the picture does a white shift.

 

Actually, my pictures could probably do with a little tweak - I think I used Colour 8 for Blue - might be better off using Colour 7.

[carmel_andrews]

Are these 'tricks' just to get more colour saturation (i.e 256+) or Just to get more resolution (i.e More then 320/200)

 

 

Can we have both please

[+CharlieChaplin]

Are these 'tricks' just to get more colour saturation (i.e 256+) or Just to get more resolution (i.e More then 320/200)

 

 

Can we have both please

 

 

Well,

if you read some replies in this thread carefully you would already know that these RGB tricks give you more colors, while the resolution (standard Gr.8, Gr. 9 or Gr. 15 resolution) stays the same...

 

Think one can also do 640x200 pixels with 3 or 4 greys and some flickering, at least I have some demo screens for that. There is also an Atari ST Degas converter for the 130XE by Antic magazine that shows 640x400 greyscale on the 128k XE with high flickering...

 

[sidenote: In the early nineties Martin Reitershan (from Reitershan Computertechnik, Turbo-Dos XL/XE) demonstrated a 1280x800 screen on a 320k Atari, but I only read about this and have never seen it (should have been at a german Atari fair, maybe Abbuc JHV, maybe Hobbytronic), so I do not know how he achieved this (use of a graphic card maybe or some additional gfx chip or by scrolling several Gr.8 screens or whatever)...]

 

To gain even more colors and higher resolution (higher than HIP,RIP, etc.) one would need additional hardware, might it be a) an extra GTIA and/or Antic or b) an extra graphic card / graphic chip or c) the VBXE board. Something like 320x200 x 16 colors, 320x200 x 256 colors or 640x200 x 4 colors or 640x400 x 4 colors is not possible with an A8 (at least not yet)...

 

-Andreas Koch.

Edited May 2, 2008 by CharlieChaplin

[MEtalGuy66]

Do you have an .XEX of that one?

 

OK, I got the executables out of the .ATR images and zipped them up. here it is again.

 

COLRVIEW 2.6 by Jeff Potter

APACVIEW 2.4 by Jeff Potter

RGB_Executables.zip

 

If you use COLRVIEW to view your images, you can adjust the intensity of the R,G,and B pages while viewing the image by pressing R,G or B to increase. Press SHIFT-R, SHIFT-G, or SHIFT-B to decrease.

 

H and SHIFT-H cycle through the "hue" settings for the entire image..

 

This might help you "fine tune" your images..

Edited May 2, 2008 by MEtalGuy66

[MEtalGuy66]

Are these 'tricks' just to get more colour saturation (i.e 256+) or Just to get more resolution (i.e More then 320/200)

 

 

Can we have both please

 

Ok.. Umm Sure.. I'll give it my best shot..

 

 

Oh SHIT! I think I blew out my monitor!

 

oh well...

[carmel_andrews]

...Not bad...was that from an A8 from from a PC (not running an A8 emu)

 

 

As i said on someone else's blog, i recall that someone (i beleive from poland) managed to hack a SID chip into an A8...

 

Seeming as though the VIC II came from the same computer, it should be a PoP (piece of piss) to hack a VIC II into an A8 (Just so we can see the sort of performance that 64 users have already been enjoying)

[Mathy]

Hello guys and gals

 

If you want to connect a video chip from a C= to the Atari, why not try the one from the C128? It'll do 640x480 and can handle 64kB of it's own RAM. I tried it some years ago, but couldn't get it to do more then change the background color. Using TurboBASIC.

 

Greetings

 

Mathy

[DamageX]

Putting a VIC II into the A8 would be darn near impossible because of the timing issues. Also, blasphemy

 

Something like the VDC, which has its own memory bus and communicates with the CPU through memory-mapped registers would at least be more practical. The NES video chip would work, and the TurboGrafx-16 which has an interesting (and very capable for the time) setup. It is actually two chips, the VDP and the VCE. The VCE holds 482 color registers and also controls the pixel clock used by the VDP. The TurboGrafx has a 21.5MHz clock which can be divided by 2,3, or 4 for different resolutions. The size and position of the display is programmable on the VDP. It reads a sprite attributes table into an internal buffer and then fetches display data from 16-bit bus RAM on a line-by-line basis, sending a 9bpp stream to the VCE. These chips were reused in the SuperGrafx console, with two VDPs for twice as many sprites and two independent background layers. Then they were reused again in the 32-bit PC-FX, this time with 128KB RAM each, and a new substitute for the VCE which allowed for more available colors.