144 x 100 x 256 Color mode

[R0ger]

I've been fiddling with this for some time, unable to solve the problems it has. So I will leave it here, at least we can talk about it.

 

First, the idea is not mine. It's based on C64 demo AlgoDream by Algorithm. I got to know him because of his (and mine) works on Bad Apple, and we had some juicy chats since then. So all credits goes to him, I only adapted the idea for the Atari.

 

So what is the idea ? Horizontal interlace ! You mask one half of the low-res pixel in one frame with PMG (which is black) .. and then you mask other half of the low-res pixel in the next frame. That allows you to have two different colors on space of 1 low-res pixel. You can even use checkerboard pattern on the mask to improve the look.

 

On C64 that means you can have 320 pixels resolution with colors of 160 pixels mode. C64 has high-res PMG, and you can cover the whole width of the screen with them.

See here: https://youtu.be/HtRxD5Zkanw?t=9m27s

 

Atari has only 160 low-res PMG. But then it has super-low-res GTIA modes with many colors, and it can work the same. But there is another problem. If you used what we call hi-res PMG (160px), you wouldn't be able to cover the whole screen. But then you can position PMG using 160px coordinates, even if PMG is wider. So you can use low-res PMG (80px), but shift it so left half of PMG pixel masks right half of one underlying pixel, while the right half of the PMG pixel masks left half of next underlying pixel. The masking pattern is a bit different, but as long as you only see one half of the pixel in one frame and another in next frame, it works.

 

With wider PMG, and some tough kernel code, I was able to cover almost whole screen - 144 pixels of the 160. I also combined it with common 9/11 interleaved mode, which gives me 144x100 pixels with 256 colors.

 

Before you hop to the sample .. read about the problems it has, and why it's not the new hot thing:

 

- it's full, independent, color mode. It takes lot of memory, basically twice as much as the usual. 16k.

 

- it needs full screen kernel.

 

- since the masking is done by overlaying the pixel with black PMG, each pixel is black half of the time. On the average, it means half brightness of the resulting apparent image. Pls. note that some better TVs will adjust and expand the brightness automatically, mitigating this problem almost completely.

 

- it flickers. Well, that's the idea, right ?

 

- LCD displays. Do you know how PAL interlace actually use half line offset for odd and even fields ? Well Atari doesn't do that. No 8bit does (AFAIK). They simply generate odd frame again and again. So the lnes overlap exactly in individual frames. That's NEEDED for this method. CRTs and TVs can display it just fine.

Most LCD can't. They are too smart. They have full frame memory, and they process the signal to combine two fields to reconstruct full non-interlaced frame. And these days they don't bother with basically illegal PAL signal. They ASSUME there are odd and even fields, and they will do the half-line shift regardless. So they take my 2 checkerboard fields, shift one of them half line down, then they merge it into one, perfectly static image. It looks terrible. For your own sake, do not try this on LCD. You've been warned.

 

- Emulators. It doesn't work properly even on emulators ! Not that it uses any specific hardware trick, which would be unimplemented. But most of the time, you run emulator on 60Hz monitor, and that doesn't translate well to 50Hz PAL interlace mode. Let's talk Altirra, because that's what I use.

Worst case it will flicker terribly at about 10Hz differential frequency. To avoid flickering completely, use 'Frame blending' in video options. You get super-smooth, stable, godly .. but unrealistic result.

Another simple option is to change video to NTSC. The palette will shift a bit, but the interlace rate will match your PC monitor, and it looks almost as on real CRT. 50Hz flicker and 60Hz flicker look almost the same.

Yet another option is to leave video on PAL, and change overall emulator speed to exactly 120%. And of course, if your monitor can handle 50Hz mode, that's the best.

Also don't forget to turn PAL artifacting to at least low, otherwise modes 9 and 11 won't mix properly and you will get washed out colors !

 

- Visible grid. Another problem, which mostly affects real CRTs, is that there is very thin grid visible over the image. Thing is, the pixels on CRT are not perfectly sharp. They are more like fuzzy balls. If you flicker checkerboard pattern, and average it over time, the pixels will not perfectly connect. It's visible even in emulator, if you do not use frame blending, and if you for example bilinear resize mode. It's hard to catch on screenshot, but if you encounter it, you will know.

 

- I don't have name for it. Algorithm calls it something like sprite-mask-hires .. but on Atari we call sprites PMG, and it's not exactly hires

 

Anyway .. enough stalling .. here it is (picture and xex):

 

Girl.xex

Edited December 29, 2017 by R0ger

[Rybags]

Atari can't position PMGs in the hires pixel increments.

C64 sprites in hires only gives 192 pixels across.

 

Couldn't you just achieve the same effect by having every second pixel as background colour and alternate 2 images? Although that means you have a common background colour per screen where with sprites you could use black, leaving the playfield background colour which could be assigned as something else.

 

I can visualise some benefit on the C64 but not much for Atari.

Also, that video... it's likely doing frame blending so is in no way indicative of the flicker you'd get with a CRT.

 

Re proper interlace - Atari can do it by hardware exploit by software. So can C128 and Plus4. The Vic 20 has the capability built in but I've not seen it in use.

Edited December 29, 2017 by Rybags

[R0ger]

Couldn't you just achieve the same effect by having every second pixel as background colour and alternate 2 images?

 

No. That way you will have 2 half-pixels cover the same area. It would increase color-space, but not resolution. This trick doubles horizontal resolution, while keeping color depth. On both C64 and Atari.

Edited December 29, 2017 by R0ger

[Rybags]

OK, I'd not realised you put an executable to try.

 

It looks pretty good though I've only tried in the emulator and you need to have it as NTSC since PAL becomes a flickering mess.

You're repositioning the PMGs - looks like 4 reuses which at double width gives the 144 pixels.

 

Have to wonder though how this technique would stack up against TIP. I guess the advantage is that you get flicker but it's more static than some other similar modes.

 

 

Whatever the result, well worth further investigation.

Edited December 29, 2017 by Rybags

[phaeron]

I wish I had a good solution for the 50Hz emulation display issue. It is possible to get a modern PC and LCD display into actual 50Hz mode, but it's a pain in the butt. The main problem is monitors reporting a minimum refresh rate above 50Hz in their EDID, which prevents setting that display mode even if you try setting up a custom display mode. Overriding the EDID can allow a true 50Hz mode but it's non-trivial to set up. I've thought about motion interpolation to reduce judder but that wouldn't work for flicker displays like this. Then there's adaptive refresh, where you have the annoying G-Sync vs. FreeSync problem when looking to buy a monitor (and the general lack of it in laptops).

 

[Xuel]

Very nice. Looks like your chroma nybbles might be in the wrong order? Notice the jaggies when you turn up saturation to 100% in Altirra:

 

[emkay]

General rule : Flicker on PAL Systems is almost a no go. There are exceptions, when the closer/overlay pixels don't change the luma value too much.

 

But in PAL we have the PAL mixing. It's not too bad.

To get a 256 color mode without flicker, some Rastaconverter with the ability of reusing missiles per scanline in GTIA Mode 9, could be very useful.

[Xuel]

Yeah, looks like the chroma lines in frame #1 and frame #2 were swapped. Corrected at 54% saturation:

 

 

pmgmask.zip

[Irgendwer]

 

No. That way you will have 2 half-pixels cover the same area. It would increase color-space, but not resolution. This trick doubles horizontal resolution, while keeping color depth. On both C64 and Atari.

 

But you could try GTIA 10 then (only 9 colours but with one colour clock shift), not to cover, but to horizontal interlace.

Beside the flicker I see also the problem that the brightness is not only halved but quartered (every other line is also dark).

 

If you could provide the source image, I would run it through my JAG converter and try to implement an experimental interlace mode for comparison.

Edited December 29, 2017 by Irgendwer

[Rybags]

Sometimes APAC looks better using COLBAK luma 02 on the chroma scalines - can you give that a try? Though it will mean more prominent horizontal bars at the sides.

 

I'm not sure using GTIA 10 would be helpful with this mode, it would achieve the same effect but with half the available luma values.

[R0ger]

Yeah, looks like the chroma lines in frame #1 and frame #2 were swapped. Corrected at 54% saturation:

 

 

That's how you report error ! Thanks man !

 

I will release convertor and source images soon.

[R0ger]

Sometimes APAC looks better using COLBAK luma 02 on the chroma scalines - can you give that a try? Though it will mean more prominent horizontal bars at the sides.

 

I'm not sure using GTIA 10 would be helpful with this mode, it would achieve the same effect but with half the available luma values.

 

I tried .. but I simply can't squeeze another poke in there. The timing is too tight. After the last PMG is moved, I have to load 3 registers so they can be used right after wsync. I'd like try to remake the kernel to be aligned perfectly with CPU so there would be no need for wsync. Then there could be just enough time for it.

[Rybags]

Maybe not worth the bother then. The problem with doing a kernal like that is that you hit the LMS lines and get screwed over by 2 cycles.

[R0ger]

Maybe not worth the bother then. The problem with doing a kernal like that is that you hit the LMS lines and get screwed over by 2 cycles.

 

Actually I did encountered that already, and non-LMS line already have extra CLC.

[Xuel]

I tried grayscale. It looks a bit brighter especially with a gamma setting of 1.73:

 

 

pmgmask-grayscale.zip

 

Too bad 9-color mode can't work since the PMG color registers determine the playfield colors in that mode. I guess you could maybe get a narrow strip where you could use PRIOR conflicts to cause overlaid PMGs to be black.

[Xuel]

Oh, setting the luma of the PMG screen to 8 instead of 0 brightens it up without any need to adjust gamma:

 

 

pmgmask-grayscale-luma8-screen.zip

[_The Doctor__]

omg the woman in this house consider all the demos being girls unfair, she wants a guy.... I told her to make her own... was not a good move on my part... She's not smiling... I've been relegated to the recliner now.... on the other hand they are running the original matrix movie so....

[R0ger]

Oh, setting the luma of the PMG screen to 8 instead of 0 brightens it up without any need to adjust gamma:

 

screenshot-grayscale-luma8-screen.png

 

pmgmask-grayscale-luma8-screen.zip

 

It does brighten it up .. it also kills the colors. The skewed gamma might be from the source image, I pushed it (and saturation) in the source image. There is for sure tons of tweaks you can do on the source.

[Rybags]

Fairly sure in GTIA luma mode, COLBAK gets ORed with the pixel value so there's really no point using nonzero luma portions there other than during transitional effects.

[pirx]

ha! my laptop (shtinkpad t430s) has go 50hz default refresh rate and I found it out when NTSC pic was bad in Altirra and PAL better! who could tell!!!

[Synthpopalooza]

A idea: Try a double Graphics 9. You can alter the BAK register between red and cyan, and also set the missiles so they are all PF3 to mix them with the picture and reduce the flickering.

[Xuel]

Fairly sure in GTIA luma mode, COLBAK gets ORed with the pixel value so there's really no point using nonzero luma portions there other than during transitional effects.

 

What I meant was that I set COLPM0-3 to "8" instead of "0", not COLBAK. That way the PMG "screen" or "mask" is brighter so it raises the average brightness of the picture. But this is just a DC offset so the dynamic range is still halved compared to a static picture.

[R0ger]

A idea: Try a double Graphics 9. You can alter the BAK register between red and cyan, and also set the missiles so they are all PF3 to mix them with the picture and reduce the flickering.

 

Not sure I follow. What do you mean by 'double' ? Alter BAK how ? Per line ? Per frame ?

[Synthpopalooza]

you change BAK between opposite colors on the color wheel each scanline and read from source pictures optimised for each color setting ... ex: blue - yellow, red - cyan, green - magenta. It gives you a 2/3rd complete color picture at 256 colors, and then the PMGS might be able to be used to fill in any extra color data. Maybe switch between Red and Green and set the PMG's to blue. If you also activate 5th player mide, the PF3 color will blend.

[Rybags]

It already uses missiles as PF3.

All objects in use at double size = 80 pixels + 4 player repositions at double size = 64, for a total of 144 pixels of masking.

 

I don't think a technique where single colour pixels are alternated by 1/2 the colour wheel will work.

The problem is that the mode relies on the checkerboard masking which means that any given pixel is only present half the time.

Edited December 31, 2017 by Rybags