Command & Conquer Atari ST Port Targets 16-Colour Strategy

Command & Conquer, the 1995 real-time strategy game, is being adapted for the Atari ST by developer indyjo. It is an ambitious work-in-progress port of the DOS original: one that aims to retain the game’s familiar base construction, Tiberium harvesting, faction campaigns and battles, while confronting a machine whose graphics and memory realities are markedly different from the PC environment for which the game was made.

The headline technical compromise is clear. The DOS game used 256-colour VGA visuals, whereas the Atari ST version is being built around the system’s native 16-colour presentation. That does not mean simply turning down a colour setting. Terrain, military units and interface-related art have to remain legible when represented with a far smaller palette, particularly in a strategy game where quickly distinguishing a unit from the ground beneath it can matter as much as spectacle.

The project is consequently notable not just as an attempt to put a famous RTS on another vintage computer, but as an exercise in asset conversion and memory management. The current build has demanding hardware requirements, and its developer has been candid that reducing RAM use remains the toughest unfinished task.

The strategic core is still the point

At its heart, this is intended to be Command & Conquer, rather than a stripped-down game merely borrowing its name and setting. Players can lead the UN-backed Global Defense Initiative, or GDI, and the Brotherhood of Nod. The central loop remains building a fortified base, collecting Tiberium as a resource, producing forces and bringing down an opposing stronghold through tactical combat.

That loop explains why the port is a meaningful technical undertaking. Real-time strategy, usually shortened to RTS, is a genre in which players make decisions continuously rather than waiting for separate turns. The game has to present the battlefield, track structures and units, accept player commands, and keep the opposing side functioning while the action is underway. Bringing that framework to Atari ST-compatible hardware calls for more than a visual conversion.

The limited palette gives the project a distinctive identity. A 16-colour version cannot duplicate every shade from a 256-colour image, so the work has focused on precise colour reduction. In practical terms, colour reduction means selecting or converting the original art so that its important visual information survives with fewer available colours. Terrain needs to read as terrain; units need recognizable silhouettes; and the overall battlefield needs enough contrast that the player can parse it at a glance.

There is an obvious retro appeal in that constraint. The port is not trying to disguise the Atari ST’s characteristics. Its 16-colour art is a deliberate technical adaptation, offering a different visual route into a game usually associated with DOS VGA presentation.

Why RAM is the project’s decisive battleground

The port currently needs more than a typical 1990 Atari STe configuration can provide. At present, the practical options are an Atari STe fitted with an accelerator card, an Atari Falcon, or emulation through Hatari. The stated minimum is any Atari ST-compatible computer with at least 4MB of RAM, while the recommended specification is a 68020 or better processor at 32MHz, 4MB or more of RAM, DMA sound and a Blitter.

Those terms describe different pieces of the machine’s capability:

RAM is working memory: the space available for game code, game-state information and data that must be readily accessible while playing.
68020+ indicates a Motorola 68020 processor or a newer member of that processor line. The recommendation of 32MHz points to the level of processing performance expected for a better experience.
DMA sound refers to sound hardware that can move audio data without requiring the processor to handle every transfer itself.
Blitter refers to dedicated graphics hardware used for fast image-data operations, a useful asset when a game must update visuals frequently.

The long-term goal is to make the game playable on an Atari Mega STe with 4MB of RAM, but that is explicitly not the project’s current position. This distinction matters for anyone watching the port and wondering whether an unmodified vintage setup will be enough. The published minimum and recommended requirements should be treated as the present technical target, not a guarantee that every familiar ST-era configuration is already supported in the same way.

For people without the necessary physical hardware, Hatari is named as an emulator option. An emulator is software that recreates the behavior of another system, allowing software designed for that system to run on a different computer. It can be a practical way to follow development of a project like this, particularly while the port’s performance and memory requirements are still evolving.

ST16 and SHPX: formats built around the machine

Several technical changes show how the port is being reshaped for the Atari ST rather than merely carried over intact.

First is ST16, a new iconset format that stores terrain tiles in the Atari ST’s native 16-colour encoding. An iconset is a collection of visual pieces used by a game; in this case, the relevant pieces include terrain tiles. A tile is a small graphic block that can be repeated and arranged to form larger maps. Encoding these tiles in the target machine’s own 16-colour format removes a conversion burden and supports the broader plan to fit the game’s art into the platform’s visual and memory limits.

The project also introduces SHPX, a new format for shapes. SHPX separates an image’s meta-information from its pixel data. Meta-information is descriptive data about an image rather than the visible dots that form it. By keeping only that descriptive portion in RAM and reading the actual pixel data from disk when needed, the port frees almost 2MB of memory.

That is a particularly substantial saving against a 4MB baseline. It also illustrates a central trade-off in software design for constrained hardware: keep more data immediately available in memory, or store less in RAM and retrieve it when required. The latter frees scarce working memory, though it makes disk access part of the design. The important confirmed point here is the RAM benefit: nearly 2MB is released through the SHPX approach.

Other changes are similarly focused on overhead. A 256KB interpolation table has been removed. The terrain-tile cache has also been eliminated, a change made possible by the ST16 iconsets. A cache is a reserved area that keeps data handy so it can be reused quickly. Removing one can save memory, but it requires the rest of the asset pipeline to work effectively without that stored copy. Finally, a new C library called libcmini is being used to reduce overhead, meaning less memory or processing cost is consumed by supporting software functionality around the game itself.

AI use is confined to software-porting work and asset tools

The developer has also specified the role of AI in the project. AI was used to help port the software and to create tools for working with the game’s assets. It was not used to generate artwork.

That is an important boundary in a project whose visual identity depends on translating existing detailed game imagery into 16 colours. The art adaptation is being presented as a purposeful palette-reduction effort, not as newly AI-generated visual material. Meanwhile, the stated AI-assisted work concerns engineering support: porting software and developing tools that handle assets.

The distinction is useful because “AI used in development” can describe very different processes. Here, the disclosed uses concern the software conversion workflow and tooling, while the artwork itself is excluded from AI generation. It is a narrower claim than saying every part of development was untouched by AI, but a clearer one about where it was and was not used.

What to watch as the port develops

The immediate practical question is not whether Command & Conquer can appear on an Atari ST-compatible system at all; the project already has a technical direction and stated current requirements. The more revealing milestone will be the continuing effort to lower RAM demands, especially the stated aim of Mega STe playability with 4MB.

The work already completed points to the kind of optimisation that effort requires: target-native terrain storage, splitting image descriptions from pixel data, discarding a large interpolation table, removing a terrain cache and cutting library overhead. These are not flashy changes in the way a new faction or map might be, but they are the behind-the-scenes decisions that determine whether a large strategy game can fit comfortably on aging hardware.

It is also a reminder that platform ports are not always defined by processor speed alone. Graphics format, memory allocation, asset storage and the path data takes from disk to screen all shape the finished result. For more Atari-focused technical background, see our look at Atari Lynx modding history, cartridge headers and homebrew hardware.

For now, the Atari ST Command & Conquer port remains in development, with its core strategy systems, both major factions and its 16-colour visual reinterpretation forming the foundation. Its progress will be measured as much by those unseen memory savings as by the armies and Tiberium fields visible on screen.