Extending the Cartridge on Programming the Atari VCS in Assembly

Extra RAM

Mon, 01 Jan 0001 00:00:00 +0000

Extra RAM#

The console gives you 128 bytes of RAM, and that pool is shared with the stack. It is brutally little — a few sprite positions, a score, some counters, and it’s gone. The way past it is the same as for ROM: put more memory on the cartridge.

Cartridge RAM, and the two-port trick#

The best-known add-on is Atari’s “Superchip” — 128 extra bytes (some carts more) of RAM riding on the cartridge, mapped into the bottom of the cart window. Atari shipped it in a run of mid-1980s titles — Dig Dug, Crystal Castles, Off the Wall, Secret Quest — most of which bankswitch as well. But cartridge RAM has a wrinkle the console RAM doesn’t: the cartridge connector has no clean read/write signal the chip can use to tell a load from a store in time. So cartridge RAM is split across two address ranges — a write port and a read port:

The DPC: A Coprocessor in the Cartridge

Mon, 01 Jan 0001 00:00:00 +0000

The DPC: A Coprocessor in the Cartridge#

Bankswitching adds ROM and the Superchip adds RAM, but both are still just memory — passive storage the CPU does all the work against. Pitfall II: Lost Caverns (1984) took the idea to its conclusion: David Crane designed a custom chip, the DPC — officially the Display Processor Chip, though the initials are also his own (David Patrick Crane) — and built it into the cartridge. It was the first — and in the commercial 2600 era, essentially the only — game cartridge with a coprocessor of its own. The console did nothing new; the cart did the new thing.

ARM Cartridges

Mon, 01 Jan 0001 00:00:00 +0000

ARM Cartridges#

The DPC put one small custom chip on the cartridge and let it do a few jobs the 6507 couldn’t spare cycles for. Modern homebrew takes that exact idea and pushes it as far as it will go.

Today’s Harmony and Melody cartridges, together with the DPC+ and CDF programming models, take exactly the same idea to its conclusion. Hidden behind the cartridge edge connector is a modern ARM microcontroller running at hundreds of megahertz. To the Atari, it still appears to be an ordinary ROM with a handful of special registers. Behind the scenes, however, the ARM is decompressing graphics, streaming music, copying data, calculating game logic, and emulating the original DPC hardware — all while the humble 1.19 MHz 6507 remains blissfully unaware.

Should You Extend at All?

Mon, 01 Jan 0001 00:00:00 +0000

Should You Extend at All?#

This chapter has watched a cartridge grow from a slab of read-only memory into a machine carrying its own ARM computer. Which leaves an honest question hanging over all of it: just because you can put a supercomputer in the slot, should you?

The clearest way to think about it is to follow one game through three lives.

Three Pac-Mans#

1982 — the original. Atari handed Pac-Man to Tod Frye — a capable programmer who’d actually wanted Defender and got Pac-Man by default — under enormous corporate pressure: ship the most-wanted arcade game of the year in time for the holidays, on the cheapest cartridge the company would pay for (a single 4 KB chip), against a deadline that left no room to refine it. The result became the best-selling game on the entire system and a byword for disappointment — the ghosts flickered relentlessly, the colors looked nothing like the arcade, the whole thing played like a rough sketch of the real game. Atari pressed something like twelve million copies — more carts than there were consoles to play them — and it turns up in nearly every story told about the 1983 crash. The lesson everyone drew at the time was simple, and wrong: the 2600 just can’t do Pac-Man. The fault was never the programmer’s talent; it was the calendar and the boardroom — the very same pressure that, that same year, gave Howard Scott Warshaw about five weeks to make E.T. and turned the designer of the brilliant Yars’ Revenge into the other name blamed for the 1983 crash.