This article begins with a direct rebuttal of my own conclusions in the previous article. After much reflection and feedback I no longer believe it would be wise to have:

• a hue/phase setting in a hypothetical container format

• a similar mechanism provided by a properties file.

The reason for this was expressed in the previous article, which highlighted the possibility of “palette abuse”.

In fact, it’s worse than mere abuse. It would effectively create a new pseudo-console that allowed a cartridge to indirectly control the palette. This is obviously not desirable behaviour to be introduced by an emulator.

In the previous article while discussing the NTSC colour problem I said that examining vintage 2600 ROMs would be an informative exercise. That is the purpose of today’s article.

While selecting ROMs to examine for this exercise, I looked for games with colour for which there are secondary reference points. For example, an image in a manual or on a game box to make comparisons with.

Games based on other items/products in popular culture might also be useful. For example a movie or a TV show.

During the recent development work on v0.40.0 of Gopher2600 I decided to do work on the NTSC palette and in particular, how the colour values are derived. This work has been on my personal TODO list for many years but I never found a reason to take a closer look.

When I finally did look I was a little surprised. I was aware that there were differing opinions on what the NTSC palette should be but what I didn’t realise was how fundamental to the 2600 this disagreement is.

The immediate prompt for this work was this thread on AtariAge. It’s a long thread with lots of confusion (some of it my own) but it’s worth reading through.

The purpose of this article is to provide a background to what the NTSC colour problem is, what the causes are, how to resolve it and how it affects 2600 emulators.

There is less controversy over the PAL and SECAM palettes (as far as I can tell) so they won’t be discussed at all in this article.

I’ve decided to start a new blog with the intention of keeping track of Gopher2600 development and to log thoughts, interesting design decisions and future plans.

The first two articles have been taken from the “Current Status” page of Gopher2600 Wiki. I created that page in the summer of 2024 in order to explain the current development status of the project. I added to the page in November (2024) explaining what had happened since. I enjoyed the process of writing about the project but realised that I couldn’t keep adding to the page indefinitely and that the wiki is not a suitable medium for this type of writing.

This article originally appeared in the “Current Status” page of the Gopher2600 Wiki

In the previous post I stated that I was putting Gopher2600 into maintenance mode. Some things have changed since then . My original intention was to only fix bugs reported by anybody who uses the emulator. I have in fact made three releases since that time, containing bug fixes and some smaller features.

This article originally appeared in the “Current Status” page of the Gopher2600 Wiki

The current status of Gopher2600 is maintenance. I’m happy to fix specific bugs people may have but I won’t be adding anything substantial. This may change in years to come but I have other projects that I want to focus on. Too many years have been wasted on this and I need to look at something else.