Non-Standard Colors on PAL & NTSC Commodore 64s (with Downloadable Utility)

Introduction

NOTE: In its original form, this article first appeared in my abortive Newsletter in June 2021.

As readers of my blog will already know, I have been a huge fan of the liberal use of non-standard colours on the Commodore 64 ever since I first laid eyes on that new shade of olive green in Mayhem in Monsterland back in the early 1990s:

However, it was a PAL-only effect, visible on CRT displays; HDMI / “Fisher-price” output kills the colour bleeding at the root of the effect and exposes the methodology, as you can see in the image below:

Without any C64 scene backing whatsoever, I rather arbitrarily call this kind of PAL-based non-standard colour generation Alternate Line Method (ALM) and use it a lot in Parallaxian, but as stated earlier, ALM will not work on NTSC, even with CRT output; instead, you'll just see the alternating lines because NTSC does not have PAL's kind of colour bleeding.

However, unlike the case with Mayhem in Monsterland, there is another type of non-standard colour generation deployed in Parallaxian, which I call the Dynamic Chequerboard Method (DCM), based on what some might described as half tones or hi-res dithering, but with the image inverted every other frame in a continuous dynamic fashion.

(For a fuller explanation of DCM, see my article on Luma-Driven Graphics).

A prime example of this is shown below:

(That's actually a very old image of Level 1, which is scheduled for a massive graphical overhaul to reduce blockiness on the background and elevate it to the same standard as the desertscape of Level 2, but I digress...)

Just before anyone makes any false accusations here, I never invented that technique; I believe it has been used - in one variation or another - in the Commodore 64 demo scene on occasion throughout the years, but I am very convinced of the suitability of method for use in games, where I can think of no examples of its deployment to date.

Note the smooth shade of dark purple used in the airspace indicator in that image of Parallaxian above.

It consists of red (#$02) + blue (#$06) generated via DCM (using Extended Colour Mode) and is not, as some have erroneously claimed in online forums, just a plain old ALM mix of brown (#$09) + blue (#$06).

So 2 questions immediately arise:

1. Will it work on real hardware and not just on emulator output?
2. Can the same idea be applied to NTSC?

To answer that, I made a little utility to test it out...

The DCM-ALM Colour-Mixing Utility

The features of the utility are as follows:

• It is designed to work on both PAL and NTSC, for easy comparison tests.
• DCM should, with the right colour combinations, produce smooth new colours on both emulated and real PAL + NTSC devices in CRT mode.
• With its superior refresh rate compared to PAL, NTSC should theoretically produce even better DCM results than PAL.
• As a little extra boost, the utility should detect a C128 running in C64 mode and increase the CPU frequency to 2MHz in the upper and lower border zones for an even smoother result due to the ca. 30% boost to frame rate.
• Because there is a pixel-to-clock-width disparity (which I discuss later in this article), there is a risk of unsightly vertical banding on real CRT displays, so a lower resolution DCM at 2px wide per chequerboard square is also included as a “better fit” countermeasure, since 14:16 is almost 1:1 whereas 7:16 (the NTSC ratio) is less than 1:2 (Note: I read some unverified commentary saying that PAL's ratio is 9:16, so if anyone reading this can confirm or contradict it, kindly let me know).

In the utility, DCM = “Dynamic Chequerboard Method” and ALM = Alternate Line Method” (obviously enough!)

So now let's take a first look at the utility in emulation, so that we can get an idea of the fundamental concepts.

Above is the PAL output in CRT mode on VICE, with same-luminosity inputs in the form of RED + DARK GREY (#$02 + #$0B).

Note the following interesting features:

• ALM produces 2 different non-standard colours in CRT mode (this would not work in non-CRT output, but remember, ALM is a legacy era method designed for real hardware using real CRTs).
• ALM is affected by the arrangement of the two 2 constituent colours; the “odd bias” has red up top on an odd numbered raster line (with dark grey on odd lines), whereas the “even bias” has red on even numbered raster lines (and dark grey on odd lines). For a more technical explanation, see this article.
• The top left quarter of the screen is red + dark grey in DCM with a 1x1 px resolution, whereas the top right quarter is DCM in 2x1 px resolution.

The image below shows the same thing as the previous example, but this time running on NTSC with CRT output on VICE.

Immediately we can see that:

• ALM doesn't work on emulated NTSC (predictably enough), even with colours of the same luminosity (which red and dark grey are).
• Conversely - and happily - red and dark grey produce a distinctive new shade in both 1x1 px DCM and 2x1 px DCM, as predicted by the theory.
• Emulated CRT output on NTSC shows no obvious vertical banding / phase shift artefacts for colours of the same luma.

Next, with the image below, we're back to emulated PAL with CRT output, but this time BLUE #$06 replaces DARK GREY #$0B and as such, we can assess the effects of slight luma-divergence on the emulator.

• Even though the above is PAL-based CRT output, ALM doesn't quite work because we're using colours of different luminosity, hence the visible horizontal stripes.
• DCM works well with the 1x1 px format, generating that smooth purple used in Parallaxian's airspace indicator, but looks very slightly less convincing with the 2x1 px arrangement (however... note that since it's a dynamic effect, screenshots can't really convey how it works “in the wild”, so you should see for yourself if you try it out on the utility).

Back to NTSC again with the image above, and the 1x1 px DCM is holding up well for the slight luma-divergence lumas, and largely resembles the PAL results but with one significant difference:

The 1x1 px DCM (on the dynamically moving emulated output) is indistinguishable from the 2x1 px DCM output; it's not until you pause the frames / take a snapshot that any discernible difference emerges - but you have to look very closely to notice.

The following are some other generic findings on the emulated output:

• NTSC is better than PAL at DCM for combinations of black + other hues, producing smoother results than possible with PAL output; I am - so far - uncertain as to the reason why, but suspect it's due to the superior frame rate on NTSC.
• Both NTSC and PAL work well with white + lighter hues in DCM.
• 1x1 px DCM on NTSC emulated output definitely shows signs of an inclination to vertical banding on certain colour mixes (e.g. anything with black) whereas the 2x1 px DCM on NTSC seems to work better for such combinations.

The Colour-Mixing Utility on Real PAL Hardware

So much fore running tests on emulator; what about real hardware with real CRT output?

Starting with PAL, I enlisted the help of my very good friend, Mr John Henderson (the creative genius behind The Wild Wood); the first example is the RED + DK GREY combo:

As you can see, even factoring in the sync issues between camera and screen refresh, there is discernible vertical banding with DCM, a disappointing artefact given that red and dark grey are of the same luminosity and work well in ALM on PAL.

However, having visited John earlier this year and sat down in front of that very monitor myself, I should point out that it exhibits a degree of vertical "jail bar" banding even with normal C64 colours... Back in the day, when I was endlessly tinkering with real hardware I had as a kid, I encountered such issues when the video output connection was loose (if I am remembering my mid 1980s life correctly!) so that might be the reason, but I would invite anyone reading this to correct me if I am wrong about that being the explanation.

Anyway, let's try mixing RED + BLUE:

Now, while the screenshot seems to show vertical banding on the 1x1 px DCM on the top LHS, John reliably tells me in real life, it's a flawless, smooth dark purple. The 2x1 px DCM was less effective, however.

He provided many more screenshots but, for the sake of keeping this article from becoming unnecessarily long, I'll summarise his favourite smooth hue results:

• ORANGE + LT BLUE
• ORANGE + PURPLE
• ORANGE + MID GREY
• PINK + SKY BLUE
• RED + BLUE

The Colour-Mixing Utility on Real NTSC Hardware

Now let's test the utility on real NTSC hardware

But before we do that, let's first consider some commentary from CBM itself in an old, obscure article from a US magazine in the 1980s, which mentioned the possibility of non-standard colours on NTSC C64s without explicitly describing how to make that happen; the scan below shows the words I am referring to (highlighted in yellow-orange):

(If you would like to read the entire article, you can download it here.)

The two most significant points in that are:

• “When you alternate pixels of two different colors, instead of getting the two colors that you think you're getting, you get a whole new phase interpretation”.
• “...because the pixels are 7/16th the width of color clock, the colours produced shift cyclically across the screen, making them difficult to utilize”.

So there's the promise of something special on the one hand and the threat of it being taken away on the other, just when you were getting excited.

But then, if we go back to the DCM principle, there should be some leeway in that method - a metaphorical sweet spot, if you will - between the grounding principle of DCM and the risk of undesirable phase shift side-effects (i.e. vertical banding).

So, to get the answer for NTSC, I had to enlist the support of someone living in North America, and the following was my list of suitable candidates:

Greg Nacu

(He's the developer of the highly acclaimed newly released C64OS, which I would recommend you check out for yourself).

Narrowing that list of candidates down then (ahem!), I asked Greg if he would kindly oblige and happily he agreed to.

He tested the utility on a C128 (NTSC) with output to a 1084S monitor, and assuming my 2MHz CPU speed booster code worked as designed in the borders, the frame rate would have been slightly enhanced compared to what it would have been on a real C64 - not that a high speed snapshot would be able to reveal any difference:

The above is with RED #$02 + same luma DARK GREY #$0B. Greg commented thus:

“I would say that the 2x1 DCM improves matters a lot. With certain color combinations the banding is hardly noticeable. But with other combinations, the banding is different but still distinctly visible.

The photos show the banding, but they don't do a good job of replicating what your eye sees, because the photo is taken fast enough that it only catches a single frame. In other words, the photos make the checkerboard standout in a way that they do not stand out when I actually look at the screen.”

Obviously, ignoring the ALM (which can't work on NTSC anyway), the first thing we can confirm is the predicted vertical banding on the 1x1 px DCM and its radical reduction with the 2x1 px DCM.

Here's another NTSC example with BLUE #$06 + same luma BROWN #$09, and again, the vertical banding artefact is very visible:

For me, given the phase shift between blue-end and red-end signals in the NTSC sine-wave colour carrier (as described in the old article referenced earlier), the result of the 2x1 px DCM is as good as hoped for, even for a static / non-dynamic snapshot.

In both of those examples shown in the real life images, the colours are of the same luminosity; but what happens when we mix colours from different lumas?

The above is BROWN #$09 + LIGHT GREEN #$0D, yielding what looks like a triple / RGB vertical banding effect on the 1x1 px DCM and a more uniform result with 2x1 px DCM.

Clearly that colour combination isn't even going to work well with NTSC on emulator (or on PAL in any form), given the gulf between luminosities of the constituent colours, but it does showcase the fundamental issue with the vertical banding: it's a serious problem for NTSC on 1x1 px DCM but far less so on 2x1 px DCM.

• To reiterate, the old CBM article says the NTSC pixel-width-to-sine-wave-colour-cycle ratio is 7:16, which causes very obvious vertical banding on 1x1 px DCM, presumably because we're starting a new colour in each pixel before the old colour of the previous pixel on its left hand side has finished its sine wave cycle.
• We can substantially and sometimes apparently eliminate that effect by using 2x1 px DCM, which gives a pixel-to-wave ratio of 14:16, thereby giving close to a 1:1 ratio between the two and allowing (almost) the colour wave the full time it needs to complete its cycle before switching to a different colour.

At this point, I will leave it to you, the reader, to perform your own experiments on emulator and, if you have one, a real machine with a real CRT display, to see what works and what doesn't work.

And of course, kindly let me know how you get on as this remains something of a work in progress!

Download the Colour-Mixing Utility!

Here you can download the Colour-Mixing Utility (prg file).

The user controls are as follows:

Key A = Pan through all 16 native colours for baseline colour A
Key B = Pan through all 16 native colours for baseline colour B

(all resultant non-standard colours are made by mixing these baselines)

Key U = Pan through all 16 native colours just to provide a helpful unrelated comparison colour U

The idea behind the U block is just to provide a benchmarking / reference point for comparing the new hues with standard hues.

Watch me Talk Through the Utility in Action

As a belated afterthought, I also decided to record and upload to YouTube a video of me demonstrating the utility in action:

A Special Trick on the C128

For the sake of completeness, I can't write an article on non-standard colours on the Commodore 64 without mentioning a very limited trick possible on the Commodore 128, albeit only functional on certain monitors.

This trick entails the colour signal being de-sync'ed from the expected phase and has so far, to the best of my knowledge, only been used in Crest's Risen From Oblivion demo (screenshot below) - that link also contains some comments attempting to explain it (warning: some foul language appears in the comments).

The new colours appear at the bottom of the screen with the green frog and Crest logo.

Further Reading

My tech article on Luma-Driven Graphics on the C64

My blog article on Next Generation Graphics on the C64

External article on Colour Blending on Old PAL C64s

External article on Colour Blending on PAL C64s

External article on Calculating the Color Palette of the VIC II

External article on Accurately Reproducing the Video Output of a Commodore C64

(The picture below is "Orbital Impaler" by Ilkka Sjöstedt, which you can download as a .prg to try out for yourself - it is an ALM-based image showcasing non-standard colours on the PAL Commodore 64).

As an extra "PS", check out this adorable but oddly named one file demo for PAL C64s, featuring a 4x1 px variant of the DCM colour generation method (presumably as a moirée countermeasure), which works very well in CRT mode: