A recent feature proposal for Stella has made me think once again about Gopher2600 playback files and the underlying ideas of compression and time. This blog entry very briefly explains how Gopher2600 currently records gameplay for future playback. It also briefly touches on the closely related topic of the rewind system.

I’ve recently conducted experiments with a coding agent working on the Gopher2600 code. I did not use one of those agents that require a subscription (I’ve never used one of those). I used instead an agent that uses an LLM running on my own hardware.

This definitely should not be taken as a signal that I am embracing agentic coding. I am only exploring the possibilities and trying to understand how these tools might benefit me.

Gopher2600 has supported the Atari2600 Supercharger for several years. However, in recent weeks some longstanding flaws and some newly identified ones, have been addressed.

The improvements relate to the way in which both tapes and binary AR files are loaded. The latter in particular being now being accessible to people without access to the real Supercharger BIOS.

It’s a new year and this year, that comes with a new PC.

The development of Gopher2600 has thus far has been conducted entirely on a very old machine. For the sake of posterity I will reveal that it consisted of a Sandy Bridge i3, 16GB of RAM and a GTX 650.

It’s decent enough and likely more powerful than the computers used by many of the people who are interested in Atari 2600 emulation. But none-the-less the time had come for a new computer.

This article is a continuation of the series discussing the Atari 2600 colour generation model. In the first article I described how each colour in the 2600 palette can be thought of as a position on a colour wheel. In particular, I focused on how each hue in the palette is positioned at a fixed location relative to the colourburst and according to a phase. I described how the phase can be adjusted by the colour delay potentiometer and there was a discussion about what the “correct” phase value should be.

In that first article I also described how using a preset palette of RGB values was unsatisfactory because the phase of the palette could not be altered. I now realise that this is a false conclusion and the phase of a preset palette can be altered and indeed, can produce superior results. This article describes a new model that makes use of a standard RGB palette while maintaining the ability to adjust the palette’s phase.

Before looking at how phase adjustment of an RGB palette is possible, let us first examine the problems created by what I will refer to in this article as the mathematical model.

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.