Secret colours of the Commodore 64 (2017) | Hacker News Reader

Secret colours of the Commodore 64 (2017)

aaronbell.com

206 points658148 comments

Great article, I love "digital archeology"!

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

Answering my own question by disabling [1] "CRT emulation" in Vice. My demos were using "CRT bleed".

[1] https://twitter.com/hackteck/status/1634813587846844418

Cool, Hacktec from legendary 1001. :)

Sodan vs 1001 - of course veterans will remember. Also the story about how Cardcruncher got stolen and then released.

ESCOS is still highly regarded today as it should be.

Indeed, that’s me! Were you active in the demo scene too?

Yes, on C64 I've been with Beastie Boys, X-Rated and again with Remember later on.

Now working on a contribution to the Amiga competition for Revision 2023.

ESCOS blew my mind back then.

1001 Crew sparked the whole C64 demoscene, IMO.

I stand in awe.

Indeed the most insane effects were always created by the dutch :)

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

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 :)

Top and bottom border sprites were trivial. A single poke turned off those borders.

Side border sprites were trickier as you had to catch the raster and, to prevent flickering, time your code with a few “nop” instructions.

Then there’s the full screen scrolling trick. Not the 8 pixel shift. I mean full screen scrolling. It used a “bug” in the VIC.

Mayhem In Monsterland been an actual real world use: https://youtu.be/ldo2ewLBt3Y

Yeah VSP. Although you could scroll the entire screen with $d016 by splitting up the fullscreen byte shift in the 7 frames before the shift :)

Doesn't it support scrolling officially?

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.

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.

Also cool with a reply from the original creator of the game…

Previously discussed:

https://news.ycombinator.com/item?id=13935590 - March 2017 (96 comments)

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.

> not sure about Brazil.

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 observed an interesting effect.

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.

Can anybody reproduce the same?

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.

What you describe is regular burn-in, but this is not just burn-in.

Leaving a static image for >30m has no visible effect on this panel.

In this case it's the flicker itself which persists on _top_ of a slight color shift, and requires only a few minutes of exposure.

I tried this on another older dell IPS panel and I observed the same. Quite interesting!

>but mostly flickering

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/

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.

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.

A bit like a dlp projector.

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'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.

https://youtu.be/3BJU2drrtCM?t=2m20s

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.

https://forums.atariage.com/blogs/entry/6693-color-computer-...

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.

I am noticing a lot of videos and images from this period are now gone...

The upside is people could redo the effects for a new crowd who may have heard about them without seeing them.

> It would be cool to see this on a 144Hz refresh monitor

While I can see the flickering on my 60 Hz monitor, it looks like a solid color on my 120 Hz laptop screen.

I'm on 144Hz and it just looks like a solid purple.

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.

The BBC computers unfortunately had only 8 colours. With 16 colour choices, 8 of them were slow “flashing” versions of the first 8.

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.

There's a modern upgrade that lets you get 16 colours from a palette of 4096.

https://github.com/bitshifters/bbc-nula

It's hard to believe those images come from a BBC Micro.

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 tried this on VIC20 but could not get it to work back then. Probably due to the luminosity of the colours being out too much.

The 16-colors palette:

#000000 Black

#FFFFFF White

#880000 Red

#AAFFEE Cyan

#CC44CC Violet / Purple

#00CC55 Green

#0000AA Blue

#EEEE77 Yellow

#DD8855 Orange

#664400 Brown

#FF7777 Light red

#333333 Dark grey / Grey 1

#777777 Grey 2

#AAFF66 Light green

#0088FF Light blue

#BBBBBB Light grey / Grey 3

ON the MSX you could create your own palette..

> ON the MSX you could create your own palette..

On MSX2 you mean? I don't think it's possible to alter the palette on MSX1.

Ah yes you're right, but still an 8 bit machine :)

Missing (2017)

Reply on news.ycombinator.com