Mode 15 PAL Blending?

[flashjazzcat]

I would be astounded if this hasn't been done before, and perhaps to better effect, but today I was toying with the idea of a sixteen colour 160x96 mode. Altirra outputs this from my rather crudely fashioned colour table:

 

 

The program just alternates between two colours sets: four grey shades and four hues. Unfortunately this looks better in emulation than it does on a real machine. While APAC tends to look quite vibrant, this looks washed out and indistinct on my 1084S.

 

Shame - becase sixteen colours at this resolution, without DLI constraints, GTIA mode involvement or heavy CPU usage, might have been quite useful.

Edited May 3, 2012 by flashjazzcat

[+Stephen]

You PAL people get to have all the fun

[Synthpopalooza]

It's a tradeoff, they get the pal blending, we get the faster refresh rate

[NRV]

I would be astounded if this hasn't been done before, and perhaps to better effect, but today I was toying with the idea of a sixteen colour 160x96 mode. Altirra outputs this from my rather crudely fashioned colour table:

 

 

The program just alternates between two colours sets: four grey shades and four hues. Unfortunately this looks better in emulation than it does on a real machine. While APAC tends to look quite vibrant, this looks washed out and indistinct on my 1084S.

 

Shame - becase sixteen colours at this resolution, without DLI constraints, GTIA mode involvement or heavy CPU usage, might have been quite useful.

 

Technically I suppose you can do that with all the "scanline" modes (I suppose that in gr.7 the pal "bleeding" also works, but only affects one scanline of the below pixel? (the top half).. too lazy to test x) )

Strange that it worked different in Altirra than Apac.. maybe if you select higher lumas?

 

What do you mean with "without DLI constraints"?.. this should be worse than Apac because you need to change the 4 color registers every line.. not just PRIOR..

 

What happens if you alternate a "yellow" (top line) with a "red" (bottom line)? .. you get a yellow and an orange??.. and that orange "bleeds" over another line?? ..so many questions

 

Regards.

[Rybags]

Try using Luma 2 on the colour lines Jon, it might look better.

 

On the luma lines it's a tradeoff - low lumas don't show up well but have OK saturation, high lumas show up well but are washed out.

[Irgendwer]

You PAL people get to have all the fun

 

No really. These images:

 

http://www.atariage.com/forums/topic/134852-atari-v-commodore/page__st__5475#entry1737525

http://www.atariage.com/forums/topic/124933-new-true-color-mode/#entry1510330

 

work much better on NTSC than PAL. Since PAL averages the colours, they look grey on such devices.

[flashjazzcat]

What do you mean with "without DLI constraints"?.. this should be worse than Apac because you need to change the 4 color registers every line.. not just PRIOR..

 

I didn't mean in comparison to APAC, but against more involved techniques such as raster colour changes mid-line and multiplexed PM overlays, etc. The object here is to get a "cheap" sixteen colour mode with absolute freedom of colour placement. Of course additional DLIs could be employed to broaden the palette.

 

What happens if you alternate a "yellow" (top line) with a "red" (bottom line)? .. you get a yellow and an orange??.. and that orange "bleeds" over another line?? ..so many questions

 

Dunno - I'll have to try this! Really I just threw this together in a few minutes, so I need to spend time on it (when I have the time to spend).

 

Try using Luma 2 on the colour lines Jon, it might look better.

 

Thanks Gary - I'll try that.

 

You PAL people get to have all the fun

 

No really. These images:

 

http://www.atariage....75#entry1737525

http://www.atariage....e/#entry1510330

 

work much better on NTSC than PAL. Since PAL averages the colours, they look grey on such devices.

 

I'm not a fan of NTSC artifacting (or artifacting at all, in fact) - I prefer something a little more "predictable". I made great efforts to completely eradicate artifacting on all my machines. The images look good, though.

 

On the other hand, I suppose PAL blending is a quirk too and I have to use the legacy video output on both my VBXE machines just to see it.

Edited May 4, 2012 by flashjazzcat

[Lazarus]

On the other hand, I suppose PAL blending is a quirk too and I have to use the legacy video output on both my VBXE machines just to see it.

PAL blending happens when the PAL signal is decoded. It basically mixes the chrominance of a rasterline 50:50 with the chrominance of the previous rasterline. The C64 emulator Vice emulates this for a long time already.

[31336haxx0r]

I had a similar idea when looking at how the 256 color images were generated. One screen is luma only, the other is chroma only. The display changes between modes and images each VBI.

My idea was to use mode 15 with 4 lumas (black, dark grey, light grey, white) and 4 chromas (like i. e. red yellow, green blue) to generate a theoretical 16 color image. Practically usable are more like 13 colors, I think.

 

I never tried it, though.

[flashjazzcat]

I had a similar idea when looking at how the 256 color images were generated. One screen is luma only, the other is chroma only. The display changes between modes and images each VBI.

My idea was to use mode 15 with 4 lumas (black, dark grey, light grey, white) and 4 chromas (like i. e. red yellow, green blue) to generate a theoretical 16 color image. Practically usable are more like 13 colors, I think.

 

I never tried it, though.

 

I tried something like this last year using two alternating GTIA screens, the idea being to get 256 colours with 192 line resolution. The interlace was very hard on the eyes, though, depending on the monitor in use. It actually made one of my TFTs whine.

 

An interlaced 160x192 display would probably be more use than a PAL blended 160x96 display, although the RAM requirement is twice as high. At least interlace isn't dependant on PAL, and would actually look better at 60Hz.

Edited May 5, 2012 by flashjazzcat

[potatohead]

What about Rybags interlace?

 

Using it would be a bit more complex, but one could get 4 scanlines per pixel, assuming the 96 pixel vertical display. Actually could get 192 or 200 pixels too.

 

The benefit would be "normal" vertical resolution, with two scan lines per pixel used. Color on the even frame, luma on the odd one. If "lego" mode is acceptable (96 - 100 pixels), then 4 scan lines are available. Color and luma on even scans on the even frame, luma and color on the odd scans on the odd frame, or something like that...

 

Using more scan lines may help with the perception of flicker, and or increase vertical resolution potential.

 

Edit: Just reread your post... Yep. Agreed.

Edited May 5, 2012 by potatohead

[Rybags]

Doing colour/luma mix per frame isn't really any good. Even worse than the RGB technique that does it over 3 frames.

TVs don't really do blending per field, you're relying on tricks to the eye which aren't so reliable when there's big luma differences.

Also, some LCD TVs will blend fields giving an effective 25 FPS so you might end up using an effect that won't work the same on CRTs.

 

I tried the APAC type modes in 480i, no advantage gain really.

 

What can improve an APAC display is alternating the hue/luma order per frame. Easiest way is to have a blank line at the top that alternates between e.g. 1 and 2 scanlines, and use a single screen image.

 

The full-blown way is to use 2 fullscreen images with odd/even vertical interleave which creates an improvement in perceived vertical resolution but will cost around 16K.

 

An intermediate way is to use 12K - share one colour image at effective 80x96 resolution between both screens and have 2 luma frames.

Edited May 6, 2012 by Rybags

[Lazarus]

Doing colour/luma mix per frame isn't really any good. Even worse than the RGB technique that does it over 3 frames.

TVs don't really do blending per field, you're relying on tricks to the eye which aren't so reliable when there's big luma differences.

 

That's the big advantage of PAL chroma mixing: The colors are really mixed, it's not just an eye trick.

Edited May 6, 2012 by Lazarus

[31336haxx0r]

Hm. It isn't possible to trick a PAL ANTIC/GTIA into running PAL-60?

[Rybags]

Proper Pal60, although it's not even an official standard is ~ 60 FPS with 312/313 line fields.

An NTSC Antic can be used but the result is 262 lines at just under 60 FPS, with Pal colour encoding.

 

But if a monitor or TV shows colour on such a system, then the colour blending should work too.

 

The refresh rate isn't really important for Pal blending, but 60 FPS would look better when using the interleaved mode I described earlier where the colour/luma lines swap places.

[ac.tomo]

I once tried getting more colours in graphics 15, and also in graphics 8, and I ended up with two options. The 1st I wanted a graphics mode with a resolution greater than that of mode 15, and more colours that are available in mode 8, therefor, what I tried was to build a display list where every scan-line was alternate gr.15 and gr.8, my hope in being the colour of the gr.15 pixel would bleed into the gr.8 pixel, and the resolution would be increased, thus, gaining colour AND resolution, but unfortuneatly this never happened. It's basically trying to get the same technique as you would with alternate gr.9 and gr.10 (or gr.11, I forget) to get 256 shades, but it was one big failure, although to be honest I never fully experimented with this technique. Anyway, the other option was to try to get more than 4 colours in gr.15, and the obvious way is to use gr.12, which gives you one extra colour, but it is possible to get approx. 12 - 15 different colours at this resolution (gr.12/gr.15). All you have to do is give your colour registers completely contrasting colours, for example: yellow, blue, red and plot the colours into co-ordinates above and below each other, for example: draw a yellow line on one scan-line and plot a blue one directly beneath that, the result would lead to a completely different colour, if you use graphics 12, then the 5 registers give you more combinations, thus, giving you more colours. There is also another way to increase on this, by putting the same colour combinations on odd numbered scan-lines as apposed to even ones, for example: by putting a yellow pixel on s/line 0 and a blue one directly below this one, you will get one colour, but if you stick the yellow pixel on s/line 1 and the blue beneath that then you'll get a different colour again. Hope you found this information useful.

[Synthpopalooza]

One other method of doing this, is a modification of the PCIN mode ...

 

In this case, you alternate each scanline between mode 10 and mode 15. You will need to alternate COLBK (712) every scanline, on the mode 15 lines it needs to be the same color as PM0 (704) which is the BG color for mode 10. On the mode 10 lines, set COLBK to whatever you want, to gain an extra color. The pixel layout is like CIN (12+11) in that two mode 15 pixels get the same color data from the mode 10 line.

 

No other color register changes are necessary, you should be able to get 30 colors onscreen at 159x96 resolution. One caution: This mode suffers from the HIP bug (mode 10 pixels are shifted to the right one color clock). So in this case, pixels 1 and 2 (instead of zero and one) would correspond to pixel 0 on the mode 10 line. Also, on the right side of the display will be some overhang from the mode 10 lines, since that column will only contain one mode 15 pixel. This effectively reduces your horizontal resolution to 159 pixels.

 

.

Edited July 9, 2012 by Synthpopalooza

[ac.tomo]

One other method of doing this, is a modification of the PCIN mode ...

 

In this case, you alternate each scanline between mode 10 and mode 15. You will need to alternate COLBK (712) every scanline, on the mode 15 lines it needs to be the same color as PM0 (704) which is the BG color for mode 10. On the mode 10 lines, set COLBK to whatever you want, to gain an extra color. The pixel layout is like CIN (12+11) in that two mode 15 pixels get the same color data from the mode 10 line.

 

No other color register changes are necessary, you should be able to get 30 colors onscreen at 159x96 resolution. One caution: This mode suffers from the HIP bug (mode 10 pixels are shifted to the right one color clock). So in this case, pixels 1 and 2 (instead of zero and one) would correspond to pixel 0 on the mode 10 line. Also, on the right side of the display will be some overhang from the mode 10 lines, since that column will only contain one mode 15 pixel. This effectively reduces your horizontal resolution to 159 pixels.

 

.

 

It's been a while since I programmed my old faithful 800xl, but wouldn't you need to alternate the value in GPRIOR (loc. 623) (or rather the hardware equivalent location) every scan-line as well as the COLBK, so as to take the graphics mode between mode 15 and GTIA mode 9, 10 or 11? or between a GTIA affected mode 15. I know that if you don't change GPRIOR using graphics 0, then you get a kind of different mode, similar to graphics 12 but with worse resolution, and regarding other modes, I can't remember what the affects were.

Edited July 10, 2012 by ac.tomo

[Synthpopalooza]

Yes, you do need to alter GPRIOR every scanline,, as well as the display list. On the lines where you have GPRIOR set to 128 (which is mode 10) the display list should be Antic mode F (Graphics 8.). This insures that all 9 colors in mode 10 are available. You then use Antic mode E on the lines where GPRIOR is 0, these will be your mode 15 lines.

 

Using GPRIOR in Graphics 0 basically gives you the text mode equivalent of Graphics 9-11. In this case it's a 2x8 character grid where each pixel value (0-15) is the corresponding GTIA mode color. In Graphics 12, using GPRIOR gives you a differing color layout. You get all 9 colors for mode 10, tho only 7 of these are usable in the char grid at once, the extra two colors (PF3 and PM3) are used for inverse chars in place of PF2 and PM2. In modes 9 and 11 you only get 14 colors (not 16), and 9 of these can be used in the char grid at once, the other 5 are used in inverse chars.

Edited July 10, 2012 by Synthpopalooza

[snicklin]

Is this SuperIRG in a graphics mode?

[Synthpopalooza]

It is slightly different ...

 

What ac.tomo is describing seems to be a cross between Super IRG and APAC ... you're using text mode (Antic 4) and changing PF0-PF3 on each scanline, right?

 

The only problems I see would be: You can't mix PF2-PF3, so only 14 colors (which is not a real issue, 14 colors instead of 15). Also, I am not sure that you can use DLI's to change your character font down the screen, if you use PF0-PF3 scanline changes ... if this is the case your graphics would need to fit within the confines of a 1K character font.

 

My suggestion, was like the ICE mode PCIN, except in bitmap mode, which is also slightly different.

 

For one thing, due to the lack of PF3 in Graphics 15, you get only 30 colors (not 35).

 

it's probably more analogous to APAC, except you're changing between mode 10 and mode 15 on each scanline, rather then between mode 9 and mode 11 ... so there's no flicker involved, it's a static display. The resolution would be 159x96 with about 30 colors. You could also do it like the classic bitmap 64-color CIN mode, which would scroll the scanlines, the resolution would be 159x192 but the memory required would be about 16k.

 

Also, unlike the ICE PCIN mode, using identical color pairs for the first three playfield registers (for example, PF2 (15) -PF1 (10) and PF1 (15) -PF2(10) ) will give slightly differing results due to the split scanlines.

Edited July 11, 2012 by Synthpopalooza

[ac.tomo]

It is slightly different ...

 

What ac.tomo is describing seems to be a cross between Super IRG and APAC ... you're using text mode (Antic 4) and changing PF0-PF3 on each scanline, right?

 

The only problems I see would be: You can't mix PF2-PF3, so only 14 colors (which is not a real issue, 14 colors instead of 15). Also, I am not sure that you can use DLI's to change your character font down the screen, if you use PF0-PF3 scanline changes ... if this is the case your graphics would need to fit within the confines of a 1K character font.

 

My suggestion, was like the ICE mode PCIN, except in bitmap mode, which is also slightly different.

 

For one thing, due to the lack of PF3 in Graphics 15, you get only 30 colors (not 35).

 

it's probably more analogous to APAC, except you're changing between mode 10 and mode 15 on each scanline, rather then between mode 9 and mode 11 ... so there's no flicker involved, it's a static display. The resolution would be 159x96 with about 30 colors. You could also do it like the classic bitmap 64-color CIN mode, which would scroll the scanlines, the resolution would be 159x192 but the memory required would be about 16k.

 

Also, unlike the ICE PCIN mode, using identical color pairs for the first three playfield registers (for example, PF2 (15) -PF1 (10) and PF1 (15) -PF2(10) ) will give slightly differing results due to the split scanlines.

 

 

 

I really don't know anything about super IRG or APAC, but I'm not changing any mode or colour registers every scan line, there's no DLI's or anything, my method just uses your basic colour registers as they are. You can (what I recently realised) apply any 2 mode DL's, to obtain colours and resolution, if your using mode 15 and a GTIA mode, then you would need DLI's to change the GPRIOR every scan-line, this way you can have loads of colours at a 159*192 resolution, but you can use any 2 modes in any combination, the idea is to use 1 mode for resolution and the other for colour, this way you can have high resolution and many colours. The earlier method of obtaining more colours in mode 15 (described above) simply uses just a simple mode 15 screen, the trick to obtaining more colours is simply due to where you put 'what' colours on the screen. Anyhow, I'm sure there's much experimentation involved here. Sorry if I have made any contradictions, but I really don't understand much of what has been said as I haven't used any of the software described in this feed. Anyway, hope I've given you a few idea's.

[popmilo]

Hello, guys!

Inspired by FlashJazzcat's message I've been working on something over last couple of days.

 

First line 160 pixels in one of 4 hues (black, red, green, blue).

Second line 160 pixels in one of 4 lumas (0, 6, 10,14).

 

As Rybags said it's much better (brighter) if color-line has luma 2 instead of 0.

 

Should be tested with different hues and lumas but overall for an quick'n'dirty weekend job it doesn't look that bad

 

Ps. If anyone has a nice 160x96 colorfull image and would like to see it on A8 just send it to me!

Edited October 1, 2012 by popmilo

[flashjazzcat]

Bloody superb! We have a new graphics mode.

 

Can't download the attachment for some reason, though.

Edited October 1, 2012 by flashjazzcat

[popmilo]

Bloody superb! We have a new graphics mode.

 

Can't download the attachment for some reason, though.

Ufff... Forgot to add executables and than modifying post became messed up

 

Here are executables:

mixcolorsmode.zip