This was freaky. When you owned any 8-bit computer, you became intimately familiar with its colour scheme. This simple photograph blew my mind. That blue colour just wasn’t possible.
According to the caption, by presenting two colours to the eye and alternating them quickly enough, a whole new colour emerged. What would this new, secret colour look like on your crappy early-90s CRT television? The screenshot was only a hint. Would it glow? Would it flicker?
Twenty-six years later, I found out the answer.
This article is all about colour switching on the Commodore 64. There are interactive examples to play with below. I haven’t found anything else on the topic, so it’s possible this is the only resource on the subject.
It’s amazing what talented programmers can eke out of old 8bit machines.
On the Atari 8-bits (400/800/XL/XE) you could do 256 or even 4,096 colors using a software-defined graphics mode. One way of achieving this was to flip between a 16-grayscale mode and a 16-color mode quickly. The ANTIC/GTIA combo was more versatile than VIC II.
I still have a great fondness for my 800XL, even though I now have a 800, 130XE, XEGS, 600XL…
On Atari ST, using the Blitter, they scaled this up to… 29k colors on screen out of 16.
http://www.pouet.net/prod.php?which=65921
Atari STe, the ST doesn’t have a blitter. The ST also have a base palette of 512 colors while the STe have 4096 base colors. But yes, only 16 colors are available at any time.
Impressive demo (not my favorite though) as showing many colors aren’t too hard, doing it animated is much harder.
Maybe not that but…
Atari ST had (and still has) good gif viewer program, called SPOFLT, Speed Of Light. You can still find and download it with Google. And that worked at least with STfm and television display. (Later I used that viewer also with Atari Falcon)
edit:
What I meant so say that it flickered 256 gif with 16 color computer. Image on ST television display was almost as good as my Atari Falcon had on monitor (and using real 256 colors).
Edited 2017-03-24 20:11 UTC
Indeed, and (at least on NTSC machines), there were also techniques for producing extra colours through artifacting – drawing lines “between” pixels that gave the fringe colours on a CRT. It didn’t work so well on my PAL 800XL, but you could see the potential.
I remember this at the time. I tried to recreate the effect myself but just got flashing. Now this article has shown me where I failed all those years ago
I was using colours that where too far separated in brightness.
Like most others I resorted to cross hatching for a simpler life.
As was touched upon in the article, if you look at the equations for how PAL forms the video signal it has (AFAICT) a minor feedback from the previous line which means that you can get a dither/artifact effect from line to line. (Can’t remember if that is a consequence of the CRT phosphor.)
In addition, if you play around with colour contrasts you can fool the eye to see things that aren’t there, like those popular images that asks “are these two fields the same colour” (which they are, but your eye is rather certain they aren’t because of the colours around it).
Phosphor in CRTs also has a certain decay (ever seen a Commodore 2080 monitor that was designed for use with interlace modes? Welcome to Ghost Town) which modern displays do not display. Turn off the lights in the room and play a shooter with a black background and see if you don’t notice it on a CRT when you move around.
All this results in some wildly varying visual expressions between images(i.e. games) on the same machine; some look flat/dull and cartoon like, while others are high on both contrast and primary colours. It takes a technically skilled artist to take advantage of this.
You know how if you see a quick flash of light you see different colours as an after-image?
I use that method to get a limited amount (3 colours) out of a Commodore Pet 2001 which had a white screen.
However, while you could see some colours the continuous flashing was too hard to look at for long.
Check out: https://www.youtube.com/watch?v=dftGzC45jXA
Edited 2017-03-24 17:31 UTC
Earl C Pottinger,
I watched that but didn’t see any color at all. I suppose it depends on your equipment. But I do know what your talking about.
I never programmed for commodore, and even on the PC I never used 1/2/4bit graphics. I preferred programming 8bit MCGA due to the exact byte addressing, which makes things easier in every way. 320×200 left something to be desired, although there were non-standard ways to achieve 320×400 (or something like it). Obviously the 64k aperture was always a source of frustration.
Eventually 32bit addressing and linear frame buffers made all of those problems go away!
I have to wonder, if they had seen a glimpse of the future back in the 70s and 80s, would have changed the design of technology at that time?
On intel’s x86, far pointers were 32bits from the start, but then they wasted a whole 12bits on segmentation, which in retrospect seems like a huge needless mistake and limited the x86 to 20bit addressing (1MB).
I guess they hadn’t conceived of >1MB, if they had I doubt they’d have designed x86 segmentation like they did. They probably didn’t even think it would become a mainstream processor decades into in the future.
Thinking about the 68000 that has a linear 24 bits addressing (16 MB) from the start, and was released in 1979 *sigh*
Kochise,
Yeah it is what it is. Once it became the defacto standard for PCs, change became futile, not by motorola, ibm, apple, sun, microsoft, not even intel. Instead we kept hacking x86 to give it new life but at the expense of more complexity and caveats. What’s worse is that this complexity extends to supporting software such as GCC needing to support a wide range of processor features and primitives like MMX/SSE[1-4]/8087/etc. It took a completely new product category with no legacy dependencies in order for ARM to make major inroads.
And there are problems with the instruction set that affect the semantics of higher level languages, like “x>>y” not equaling 0 when y >= sizeof(x)*8. Any mathematician would call that a bug, except that intel defined it as undefined (on page 1734 in the latest architecture manual) so that any unexpected values are intentional. This matters for algorithms where the value of y is dynamic and might legitimately equal all bits. I think AMD does the right thing, but it sucks that you can’t count on that.
If we added up all our gripes about x86, we might end up with a book larger than intel’s 4700 page developer manual, haha.
I even started an alternative reality timeline where the 68000 would have evolved and predated all other companies with right technological choices :
https://github.com/Kochise/m68140
Will provide more files, datasheets, schemas, source code, perhaps even a modified qemu
Later…
I did the same in the 80’s on SHARP LCD pocket computers.
By quickly switching between two images (in assembly), I could get one or two gray levels in addition to black and white.
Michael Stiehl discusses this trick (and other VIC hacks) in his Ultimate Commodore 64 Talk from 25c3:
https://www.youtube.com/watch?v=ZsRRCnque2E
TRS-80 Color Computer programmers did this, too. This computer had a horrific lack of colors in higher resolutions. The flicker technique was used for GIF viewers for many colors on the palette. Unlike the C64, the CoCo could render the color blue (what a weird oversight on the part of Commodore).
Also, since the highest resolution only had two colors (white and black), the artifacting was used in almost every game and drawing program. These programs started with a blue or red screen and you had to press the RESET button over and over until the desired color appeared since on CoCos the NTSC timing was random. Later programs were smarter and you just pressed a key if the colors were inverted.