I created two demos in 1986 that also show additional colors to the basic palette of the C64. I don't recall whether these demos used a pattern of pixels that caused "CRT bleed" [1] or whether colors were quickly alternated in the way described by the article.
I just ran the demos in Vice and took screenshots [2]. As an aside, notice that the sprites extend outside the regular border which was long considered impossible on the C64. A whole arms race started between demo groups to beat each other by taking border sprites to the next level. I contributed to a number of those demos too [3].
[1] Of course, I just ran the emulator on a non-CRT display on MBP but I don't know how well the C64 emulator also emulates the bad video quality of 80s TVs/monitors. I seem to notice some bleed artifacts in the screenshots.
It supports scrolling up to 7 pixels but after that you have to actually move the memory backing the screen, and the cpu is slow enough that it’s pretty hard to do.
Those were the times :) I remember Sodan releasing his borderscroll back then. I guess 1001 released their demo first. 1001 was always held in the highest regard by us scandinavians :)
Same here. I will never forget my "first contact" with it. I saw ESCOS at a friend's house (Brandis/Success). At first I thought he manipulated the monitor, which was able to zoom in so that it shows only the text/graphics area. :D
I love that the author was able to find the exact page he'd remembered reading once upon a time. The internet is awesome. Cool article and write-up and appreciated the interactive demos too.
The PAL-M Apple IIs I used in Brazil had an interesting quirk thanks to PAL (I suspect the Europlus has it as well): alternating lines of the same color have different shades - shifted back and forth in the color signal (PAL = phase alternating line). With that, you could get a lot of different color shades on a TV - magenta and cyan were the easier ones, but there were plenty others.
NTSC IIs can also do that trick, but the nature of NTSC makes it more limited.
OTOH, a PAL Apple II has issues drawing vertical straight lines, something the NTSC ones don’t.
In fact color games on the Europlus were a pretty limited market for this reason[1]. Apple's artifact colors were difficult enough to manage for one framebuffer style.
To be fair, they were also absolutely groundbreaking. The VIC-II palette being described in the linked article shipped in the middle of 1982, and recapitulated a bunch of ideas from Atari's 1980 CTIA/GTIA chips. But I can boot a copy of Ultima V on my II+, a AAA title produced in 1988, and watch it display on framebuffer hardware that is almost completely unchanged[2] from what shipped in the summer of 1977!
[1] Also just the general delay of arrival to non-US markets and the higher price meant that Apple had a much smaller share. Europe for sure was a Commodore world, not sure about Brazil.
[2] The first few thousand boards shipped lacked a delay latch that allowed the high bit of a framebuffer byte to select the phase of the NTSC color. So extremely early Apple IIs had only four colors available and not six. As you might expect, Woz distributed rework instructions for owners to add this themselves.
We had Apple II clones for a long time - the military dictatorship wanted to develop a local industry and, to do it, they taxed heavily imports of any finished computer, as well as preventing foreign companies to start operations. We also had lots of different developments, but most based on American or European designs. Brazil never developed beyond simple logic and memory chips and there was no, as far as I know, any serious work on cloning or developing CPUs locally (I designed a stack-based CPU, but that was for college).
Personal computers in Brazil was mostly Apple II, then PC (if you had too much money) and MSX. Lots of "alternative imports" that included Macs too (we did a Mac clone, even, but the US Department of Commerce threatened taxing our exports if it were ever released). All my IIs were local clones (some were very good ones, with multiple enhancements).
I left the "palette demo" flickering on the same spot for about 5 minutes while doing other stuff on a dell up2720.
After closing the page, the pattern was still visible on the LCD when showing a grey image (or on top of the same pattern again where ghosting became quite visible). It's visible both as a slight color shift but mostly flickering.
Putting the screen to a fixed color pattern (via LCD conditioning) was still showing the same, again mostly on grey, excluding thus most of the driver/display chain as an issue which I suspected as first (dirty cache).
The effect is gone after about 5 more minutes.
First time I see persistence like this on an LCD. A static flat image can't do this on this panel.
I've had the same thing happen after an extended period of emulating an Amiga in an interlaced screen mode. After exiting the emulator, there was still similar flickering and mild image retention, that also faded after a few minutes.
My guess is that it's down to the relationship between the specific interlacing used by the panel, if any (lagom.nl has inversion/pixelwalk tests to determine which type a monitor uses), compared to the 60Hz flickering. Something about the two together induces image retention far sooner than the average content, albeit image retention that also fades much quicker.
Trivia: static images on LCD can be sometimes seen as flickering because they are not really static, to prevent burn-in and subsequent damage polarity is reversed every frame. Some details here: http://www.techmind.org/lcd/
My digital signage screen that I use as a monitor with an official 18/7 uptime rating has explicit temporary burn in/ghosting issues mentioned for content that is too static/persistent, and says it'll go away after a bit of rest time/waiting for the LCD to normalize.
It even has an anti-burn-in mode that steps the image around+-4 pixels in both directions every few minutes to prevent any hard contrast lines from persisting and their ghosting to be notable to the customers of the facility that operates the digital signage.
I found that with the flickering images I could see the two individual colours if I looked at them through the gaps between my fingers while waving quickly at the screen. This worked even on a 144Hz monitor, where I couldn't otherwise see any flicker at all.
Looking from the side of your eye might work too, as we seem to have higher temporal resolution there. Red and maybe colours might be problematic there, as the cones for those are disproportionately in the fovea?
Cheap TFT monitors often emulate 8-bit color channels with only 6 bits worth of brightness levels by flickering between the two nearest values (temporal dithering). Some nominally 10-bit displays do this as well with 8-bit channels.
I think it's funny that some people like the C64 palette and some don't. I liked my CPC punchy colors much more (wrote some C64 assembly and some CPC games back then, but was a kid).
TBH the C64's colors look a lot more saturated to me in real life than on emulators. I guess it depends on the monitor or TV set you use, but even the Commodore monitor had a knob to turn up saturation, so IMO it doesn't really make all that much sense to claim that "the C64 colors were these exact colors".
The colors have been measured, and the mathematical formulas needed to calculate accurate colors are known. While there aren't a single set of "accurate" RGB mappings, there is a range of accurate RGB mappings that would cover all the hue (where appropriate) and saturation settings. Even the PAL blending is known and able to be simulated.
The article doesn’t say whether this appears to flicker on a CRT. Although pixel response time is quite good on a CRT TV, I remember it taking a while for the brightness of pixels to ramp down, which may dampen the flickering.
It flickers on a 50/60Hz CRT. As a kid, I toyed with "extra colors" quite a lot on C64, Atari, Color Computer 3.
There are three basic methods:
One is discussed here, cycle between two colors. Low contrast changes are best.
Artifact color is what the Apple 2 computers use, and that is basically using high resolution graphics to get colors when the small pixel size results in frequencies the NTSC color circuits see as color info.
The CoCo3 had a 640 pixel mode able to generate one byte per pixel, 256 color mode. A very nice find for a kid! The link is that graphics trick reproduced for others to see today.
This method is all about NTSC.
And the third way to get more color was all about PAL and I have PAL CRT displays now and should get PAL hardware to explore this method. Did not have access to anything PAL as a kid, sadly.
This method involved changing colors on alternating frames and vertical alignment of pixels. I could not find a reference image. This was probably not done much.
It's said later in the article that you'd need two colors with similar brightness to avoid perceivable flicker. CRTs did have some afterglow but it wasn't even for a full frame, let alone two.
The example should have used red and blue at the same brightness, like later with the dragon, then it would already be virtually flicker-free at 60 Hz.
They could be very fast flashing versions with an OS call, so on an average TV they blurred nicely into new colours. You could also change video mode part way down the screen if you were careful, or more commonly switch the palette either for effects or to not show the part of the screen memory that you were using for other purposes.
And if you dont believe the Simple Demo is alternating between two colours then do the peace sign in between you and the monitor and quickly wave your hand left and right and youll see two colours in the trails of motion. Weird. Anyone know why?
I created two demos in 1986 that also show additional colors to the basic palette of the C64. I don't recall whether these demos used a pattern of pixels that caused "CRT bleed" [1] or whether colors were quickly alternated in the way described by the article.
I just ran the demos in Vice and took screenshots [2]. As an aside, notice that the sprites extend outside the regular border which was long considered impossible on the C64. A whole arms race started between demo groups to beat each other by taking border sprites to the next level. I contributed to a number of those demos too [3].
[1] Of course, I just ran the emulator on a non-CRT display on MBP but I don't know how well the C64 emulator also emulates the bad video quality of 80s TVs/monitors. I seem to notice some bleed artifacts in the screenshots.
[2] https://twitter.com/hackteck/status/1634807467056963585
[3] https://csdb.dk/group/?id=81